寄售庫存的數據庫架構

Question

我正在為醫院開發寄售清單，

基礎結構是這樣的：

Multiple Suppliers
Multiple Warehouses
Multiple Hospitals

我一直在決定是為每個hospitals和warehouses制作單獨的stock tables ，還是將它們全部存儲在one stock table 。

我當前的計划是這樣的：

他們將僅在單個item table上閱讀以獲取常規項目信息，然后每個醫院/倉庫的庫存，庫存移動，寄售訂單，員工，患者將有單獨的表。

例：

分隔表

tbl_items //centralized item information
tbl_suppliers //centralized supplier information
tbl_warehouse1id_stocks
tbl_warehouse1id_stockmovements
tbl_warehouse2id_stocks
tbl_warehouse2id_stockmovements
tbl_hospital1id_stocks
tbl_hospital1id_stockmovements
tbl_hospital1id_employee
tbl_hospital1id_patients
tbl_hospital2id_stocks
tbl_hospital2id_stockmovements
tbl_hospital2id_employee
tbl_hospital2id_patients

合並表

tbl_items //centralized item information
tbl_suppliers //centralized supplier information
tbl_warehouse_stocks //where warehouse_ids are primary keys
tbl_warehouse_stockmovements //where warehouse_ids are primary keys
tbl_hospital_stocks //where hospital_ids are primary keys
tbl_hospital_stockmovements //where hospital_ids are primary keys
tbl_hospital_employee //where hospital_ids are primary keys
tbl_hospital_patients //where hospital_ids are primary keys

哪個更好？ 用於維護，速度優化等？ 我目前的觀點是，分開的方法更好，因為例如（醫院）為什么要從所有醫院的庫存中搜索他們的特定物品庫存？ 這會影響速度嗎？ 如果hospital1試圖查詢其全部庫存記錄，則將影響其他醫院的查詢時間，因為hospital1當前正在搜索其記錄。 當然索引應該有幫助，但仍然可以。

編輯：

該服務器位於單個位置，並且其基於Web的系統。

Answer 1

我強烈建議您采用您提出的合並表格方法。

單獨表的缺點：

• 每次新建一個倉庫/醫院或將其添加到跟蹤系統時，都必須向架構中添加新表
• 現在編寫查詢以計算所有醫院或倉庫中單個項目的庫存，因為查詢要復雜得多（每個表中的聯合/聯接）。 結合將新倉庫添加到系統這一事實（上一點），您現在必須分別更新所有這些查詢
• 您的Web后端層如何知道要查詢的表？ 聽起來您將沿着動態查詢生成的道路前進，並將為您的代碼庫增加更多的復雜性。

除非您有尚未布置的重大約束（擁有數十億行的極大型數據庫或無法擴展的不良硬件），否則索引將專門為這種情況提供幫助。