寄售库存的数据库架构

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后端层如何知道要查询的表？ 听起来您将沿着动态查询生成的道路前进，并将为您的代码库增加更多的复杂性。

除非您有尚未布置的重大约束（拥有数十亿行的极大型数据库或无法扩展的不良硬件），否则索引将专门为这种情况提供帮助。