0

我需要为药品的日常销售设计一张表格。

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

成千上万的销售人员被雇用来销售这些产品{名称，代码}。

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

他们在不同的区域 -> 区域 -> 市场 -> 奥特莱斯等工作。{都有名称和代码}

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

问题是，日常销售需要大量的数据输入。几年内可能会有千兆字节的数据（如果不是太字节）。如果我需要显示每日、每周、每月、每季度和每年的销售报告，我将需要各种类型的 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桌子的建议。有没有办法打破这个特定的表来实现粒度？

4

3 回答 3

2

您正在寻找的东西称为数据仓库 (DW)。我建议您看一下 Ralph Kimball 的“The Data Warehouse Toolkit”——它提供了用于零售的数据仓库设计示例。这是一个非常简化的（初稿）示例，说明它的外观。您会注意到这是针对报告和分析优化的非规范化结构。事实表的粒度通常是收据上的一项（行）。希望这可以为您指明解决方案。几 TB 的 DW 就可以了。


存储的w_model_01

于 2009-11-16T15:10:13.660 回答
1

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

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

在给定的日期，推销员只能在一个网点吗？如果是这样，那么您可以删除outletid。

你有 PriceiD、SalesPrice 和 Discount。如果我知道折扣和商店 ID 以及原始价格，那么我可以确定税金并计算 SalesPrice，这样您就可以放弃它。

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

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

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

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

更新：基于评论

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

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

通过减少列数，您将对存储空间产生很大影响，以防万一，因为许多列可能不会为空。

于 2009-11-16T08:27:36.687 回答
1

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

于 2009-11-16T08:28:31.637 回答