需要数据库设计建议

Question

我需要设计一个药品日常销售表。

有数百种类型的产品{名称，代码}。

成千上万的销售人员被雇用来销售这些产品{name，code}。

他们从不同的仓库{名称，代码}收集产品。

他们在不同的领域工作 - ＆gt;区域 - ＆gt;市场 - ＆gt;奥特莱斯等{所有人都有姓名和代码}

每种产品都有各种类型的价格{生产价格，贸易价格，商业价格，折扣价格等}。而且，销售人员可以从这些组合中自由选择以估算销售价格。

问题是，每日销售需要大量的数据输入。在几年内，可能有数十亿字节的数据（如果不是太字节）。如果我需要显示每日，每周，每月，每季度和每年的销售报告，我将需要各种类型的SQL查询。

这是我最初的设计：

Product {ID, Code, Name, IsActive}
ProductXYZPriceHistory {ID, ProductID, Date, EffectDate, Price, IsCurrent}
SalesPerson {ID, Code, Name, JoinDate, and so on..., IsActive}
SalesPersonSalesAraeaHistory {ID, SalesPersonID, SalesAreaID, IsCurrent}
Depot {ID, Code, Name, IsActive}
Outlet {ID, Code, Name, AreaID, IsActive}
AreaHierarchy {ID, Code, Name, PrentID, AreaLevel, IsActive}
DailySales {ID, ProductID, SalesPersonID, OutletID, Date, PriceID, SalesPrice, Discount, etc...}

现在，除了索引之外，我如何将DailySales表格规范化为具有细粒度设计，我将不需要在未来几年内进行更改？

请根据上述信息向我展示仅 DailySales数据输入表（将从中查询所有类型的报告）的样本设计。

我不需要详细的设计建议。我只需要一个关于DailySales表的建议。有没有办法打破这个特定的表来实现粒度？

Answer 1

您正在寻找的是数据仓库（DW）。我建议你看一下Ralph Kimball的“数据仓库工具包” - 它有零售销售数据仓库设计的例子。这是一个非常简化的（初稿）示例，说明它的外观。您会注意到这是一个针对报告和分析进行了优化的非规范化结构。事实表的颗粒通常是收据上的一个项目（行）。希望这能指向您的解决方案。 DW的几兆兆字节是可以的。

Answer 2

为什么不在产品上加上日期和价格，以便您可以从dailysales表中删除价格，因为您可以通过加入来获得它。

除非销售人员可以更改价格，否则数据库中没有任何理由。

在给定日期，销售人员只能在一个商店吗？如果是这样，那么你可以放弃outletid。

您拥有PriceiD，SalesPrice和折扣。如果我知道折扣和出口ID和原始价格，那么我可以确定税收，因此计算SalesPrice，所以你可以放弃它。

但是，这意味着您要按日期存储税务信息，以跟踪销售发生时的情况。

我的观点是，您应该查看另一个表中已存在的内容，然后您可以简化每日销售表。

您希望按日/月/年将信息从日期/月/年提取到临时表中，以帮助按日汇总数据，以便更快地生成报告。

你的问题中有很多未知数，但希望这会有所帮助。

更新：根据评论

我有一个表，其中包含有关何时某人使用资源的使用信息，该表很快就变大了。因此，我们决定只保留2到3年的数据，其余的将被聚合，并将原始数据转储到文件中以便存档。

在查看行数时，您需要确定需要保留多少数据，以及如何存档旧数据，以便在绝对需要时使其可用，但是，您可以生成报告这应该是事先需要的。

通过减少列数会对存储空间产生很大影响，如果需要考虑的话，因为许多列可能不会为空。

Answer 3

如果您要生成大量数据并需要根据过去的数据生成报告，则应考虑使用business intelligence引擎。通常，这些引擎允许您将历史数据存档在单独的数据存储中（这样您不会使日常工作数据库混乱），而是从存档数据中获取统计数据和报告。