我有Stock表。
sku
quantity
quantity_sold
price
seller
我有StockExtra表用于具有日期/时间属性的产品（您可以想到事件票据）
stock # references stock
quantity
quantity_sold
price
date_at
time_at
datetime_rule # foreign key to another table, it is a rule that describes when events occur
对于活动门票，我使用Stock表中的stock and seller，但使用StockExtra表中的数量。因为不同日期的机票可以有不同的数量和价格。
我已将表格分开，但不确定是否是最佳做法。
现在我需要创建另一个表来保存不同市场商店的库存数据 （我正在建立一个卖家可以在多个商店销售产品时管理库存的系统）
例如，可以在amazon.com和ebay.com上销售活动门票。 而每个商店的价格，数量可能会有所不同。
因此，从Stock到StoreStock会有一对多的关系。
Stock将保留所有商店的默认价格和汇总数量/数量_商标。 StoreStock将保存单个商店的数据。
由于同样的原因，我还需要StockExtra到StoreStock之间的一对多关系，即每个事件票据的日期/时间的价格/数量可能不同。
所以我目前的设置，
会有Stock StockExtra和StoreStock。
仅使用Stock和StoreStock会更好吗，即使非机票产品的日期/时间相关字段为空吗？
答案 0 :(得分：0)
您应该考虑通过以一致的方式保持所有内容来降低系统的复杂性。将复杂场景与简单场景保持在同一个表中。
通过在不同的地方保留相同的信息（例如Stock与StockExtra或Stock与StoreStock），您正在创建一种代码必须具有的情境额外分支以根据情况查找数据。
当您处理单个事务的数据时，分支并不是世界末日，尽管需要编写，调试和维护的代码更多。但是，当您追踪数据汇总时，将其分布在多个潜在位置会使您的数据检索更多更复杂。
我建议将所有内容保持在最详细的级别。因此，即使只有一个商店适用于特定情况，所有内容都会进入StoreStock。然后，除非您有明显的性能问题，否则请不要从StockExtra拆分Stock - 只需在Stock中使用可为空的列。
可以将默认价格保留在Stock中，但为了下一个必须维护代码的人，请使用更具描述性的名称。我建议不要在Stock表中跟踪销售数量。请仅在StoreStock中保留此信息。不要保留预先计算的数量。这将不可避免地出现问题。而是跟踪添加的数量（收据）和已移除的数量（销售额）并动态计算现有数量。这样可以避免库存调节问题。