資料庫架構

在資料庫方面，由於一套系統需要提供給多家不同的養雞場使用，並且得確保各家的資料互為隔離，因此一開始便需要思考如何設定資料庫的整體架構。

一般而言多租戶架構的資料庫設計有以下三種方式。

[*]切割資料庫 (database)
[*]切割結構描述 (schema)
[*]切割資料表 (table)

切割資料庫

所謂切割資料庫的意思就是讓不同的用戶連線到不同的資料庫。以養雞場的例子來說，可以讓A養雞場連線到A資料庫，B養雞場連線至B資料庫。好處是由於資料庫是完全分開的，隔離性相對是最好的。在實作上也只要需要切換資料庫連線設定就好，不需要太多額外的處理。但由於每個資料庫都會擁有獨立的資源，如檔案和記憶體空間等，所以這方式也會最消耗主機上的資源。在資料庫維護方面，當需要增加一個用戶時，所需要的初始化步驟也為最複雜，得新增一個資料庫，新增所有資料表、預存程序、權限設定等。同樣的，當要變更資料結構時，亦得同時更新數個資料庫。

切割結構描逋

在同一個資料庫內，為每一個用戶都建置一份相同的資料表。舉例來說，假設系統需要使用到User及Role這兩個資料表，則實際上資料庫中會建立的是A_User、A_Role及B_User、B_Role這兩組資料表，每一組都將資料表名稱加上用戶代碼的前置來做為區別，若是A用戶操作系統便使用A_User、A_Role這組資料表，B用戶則用B組的資料表。相較切割資料庫的方式，本方式在新增用戶時，不需要從頭把一個新增資料庫出來，只需增加資料表，但是當用戶增加到一定程度時，便可能會有數百數千個資料表在同一個資料庫內。同樣的，當要變更資料結構時，每一組的相同資料表都需要一起變動。

切割資料表

每一個用戶都使用相同的資料庫，但是每一個資料表中都增加一個欄位，用來區分該筆資料屬於哪一個用戶，以下圖為例，我們在User的資料表中多增加了一個Region的欄位，來區分user1是A養雞場的資料，user2是B養雞場的資料。

這樣的做法好處是資料庫維護較為容易，變更資料結構時只需要修改一個資料表即可，所佔用的資源亦是最少。但由於不同用戶的資料並沒有做到實體隔離，只依靠程式存取資料時的控制，一旦系統對於資料存取處理的架構不完善時，較容易發生A用戶查詢甚至於修改到B用戶資料的風險。

對於我們的雲端雞隻健康追蹤資訊系統來說，就專案的特性分析，養雞場家數並不會兩三天就多生一家出來，最多也是兩三年才會有一家。再考量資料的隔離性及程式開發的便利性，因此在資料庫架構方面將採用切割資料庫的架構規劃。