寄售库存数据库模式

Question

我在为医院准备一份寄售清单，

基础设施是：

Multiple Suppliers
Multiple Warehouses
Multiple Hospitals

我不得不决定是为每个hospitals和warehouses分别创建一个单独的warehouses，还是将它们全部存储在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试图查询他们的全部股票记录，这将影响其他医院的查询时间，因为hospital1目前正在搜索他们的记录。当然，索引应该是有帮助的，但仍然有帮助。

编辑：

服务器驻留在一个位置上，并且它是一个基于web的系统.

Answer 1

我强烈建议采用您所设计的合并表方法。

单独表格的缺点：

• 每当建立一个新的仓库/医院或将其添加到跟踪系统时，您都必须向模式中添加新的表。
• 现在编写一个查询来计算所有医院或仓库中单个项目的库存，因为这是一个复杂得多的查询(联合/连接通过每个表)。结合这个事实，一个新的仓库可能会添加到系统中(前一点)，现在您必须单独更新所有这些查询。
• 您的web后端层如何知道要查询哪个表？这听起来就像是在进行动态查询生成的过程，并且会给您的代码库增加更多的复杂性。

除非您有很大的约束条件，而这些约束还没有部署(具有数十亿行或无法扩展的硬件的超大数据库)，否则索引的设计正是为了帮助实现这个场景。