Web應用程序的基本數據庫體系結構

Question

我試圖構建一個基於Web的任務管理系統。我希望不同的組織能夠訪問不同的任務列表。有兩種方法，我可以想像去有關設置數據庫架構：

1. 所有被存儲在一個表中的所有組織的任務。與組織X關聯的任務記錄爲X的ID號碼存儲外鍵。
2. 每個組織都會收到自己的任務表。該表具有前綴以將其標識爲屬於該組織。單獨的表存儲組織和表前綴之間的關聯。

什麼是1對2的優點和缺點？哪一個更好？另外，我正在考慮允許用戶關閉某些任務的屬性，例如跟蹤您在任務中工作了多少時間。我想象我可以通過添加或刪除任務表中的字段來做到這一點。由於不同的組織會有不同的配置設置，但是，2.會更適合於此目的？

Answer 1

這聽起來不是一個好主意，讓每個組織自己的任務表。這需要在新組織出現時對物理數據庫進行更改，並且可能會更改代碼以從新表中讀取數據（儘管您可以動態更改前綴）。如果你想改變未來的結構，你也有更多的開銷，例如增加新的領域。這會限制你隨着時間的推移重新設計和改進的能力。同時將負載分散到多個表中意味着您需要保持索引和其他類似的東西同步。由於涉及多個表，因此備份會變得更加繁瑣。

我還以爲最好的解決辦法就是讓這種數據驅動的，具有結構類似於如下：

**OrganisationTable** 
ORGANISATION_ID 

**TaskTable** 
TASK_TYPE 

**TasksOrganisationStatusTable** 
TASK_TYPE 
STATUS (Boolean) 
ORGANISATION_ID 

**TasksTable** 
ORGANISATION_ID 
TASK_TYPE 
DUE_DATE 
etc. 

這樣你就可以動態地改變活動任務，建立新的組織，等等。在您的應用中使用緩存來提高性能。

Answer 2

這個搜索詞是「多租戶數據庫」或「多租戶架構」。

有一個簡要概述，並從this StackOverflow question到一個有用的文章的鏈接。

Answer 3

我做這件事情，我給每個「組織」自己的表，你描述。當新組首先訪問表所支持的功能時，該表即時創建爲基表的空副本。因此，只有基礎需要被「維護」，如果它被改變了，唯一的開銷是（記得）刪除嬰兒表，以便可以根據改變後的乳房表重新創建它們。

它工作得很好，在這種情況下。