Database Schema for Consignment Inventory

Question

I'm developing a consignment inventory for hospitals,

The infrastructure is this:

Multiple Suppliers
Multiple Warehouses
Multiple Hospitals

I'm stuck on deciding whether to make a separated stock tables for EACH hospitals and warehouses or store them all in one stock table .

My current plan is this:

They are all going to read on a single item table for general item information only, then the stocks, stock movements, consign orders, employees, patients will have separate tables per hospital/warehouses.

Example:

Separated Tables

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

Merged Tables

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

which is better? for maintaining, speed optimization etc.? my current opinion is that the separated approach is better because why should (for example) hospital1 search for their certain stock of items to the pool of stocks of all hospitals? does this affect the speed? if hospital1 tries to query their entire stock record, it will affect the query time of other hospital because hospital1 is currently searching for their records. of course indexing should help but still.

EDIT:

The server resides on a single location and its a web-based system.

Answer 1

I would highly recommend taking the MERGED TABLES approach that you've laid out.

Disadvantages of Separate Tables:

• Every time a new warehouse/hospital is built or added to the tracking system, you have to add new tables to your schema
• Writing a query to count the stock of a single item across all hospitals or warehouses now because a much more complex query (unions/joins through every table). Combine this with the fact that a new warehouse may be added to the system (previous point), you now have to update all these queries individually
• How will your web back-end layer know which table to query? This sounds like you would be going down the path of dynamic query generation and will be adding yet more complexity to your code base.

Unless you have significant constraints that you haven't laid out (extremely large db with billions of rows or poor hardware that you can't scale up), indexes are designed to exactly help with this scenario.