为类似类型的数据保留一个表或多个表，哪一个是最好的，同时考虑高性能

Question

我正在为 ERP 等销售和采购应用程序设计 DATABASE，并使用 MYSQL 作为 RDBMS，我怀疑为销售和采购实体创建表以使用每个模块（销售/采购）的单个表或每个模块的多个表实体（销售订单、销售发票、销售退货、采购订单、采购发票、采购退货）。下面是我的用例。

我的应用程序将包含销售订单、销售交货、销售发票、销售退货和信用票据以及购买模块的相同实体，所有这些实体都可以在该模块中输入链接。像销售订单可以转换为销售交付或销售订单和销售交付可以转换为销售发票。所以需要维护模块的每个实体的引用。

现在，我有点困惑将所有这些都保存在一个表中，每个模块说“sale_entity”和“purchase_entity”具有实体类型或者我应该为每个实体类型创建单独的表，比如 sale_order、sale_invoice、sale_return、purchase_order、purchase_invoice , purchase_return 等。

以下是我对这两种情况的想法：

单表：我真的很想为每个模块保留这个单表，但我担心长期运行的性能，它会迅速增加表大小并可能降低性能。

多表：很难同时管理、维护所有实体类型记录的报表中的关系和获取数据，需要联合和全部。

我的理解是大尺寸的表格比小尺寸的表格执行得慢，如果我错了，请纠正。

请稍微说明一下，并建议我应该如何进行。

谢谢

Answer 1

经验法则：如果两个表具有相同（或几乎相同）的列，则将其设为一个表，而不是两个。您可能需要添加一列来区分这两种类型的数据。您可能需要有一列是NULL，如果它适用于一个用户但不适用于另一个用户。 NULLable 列太多 --> 不要合并表格。

经验法则：一对多和多对多关系要求有两个或三个表。 （第三个是多对多。）

“订单”通常涉及“订单项目”。这是Orders 中的一行映射到一个或多个OrderItems。这些应该是单独的表。

“购买”与“退货”？ 也许它们可以在同一个表中，并通过amount的符号来区分？

Answer 2

较大的 ERP 平台倾向于将所有事务数据存储在一个表中。示例包括 NetSuite 和 Odoo。

这些系统往往具有交易的通用概念，并允许用户通过定制引擎创建新的交易类型。

较小的 ERP 系统，尤其是针对特定垂直市场的系统，通常针对每种交易类型都有单独的表格。

因此，这两种方法可能都有一个论据。作为一般规则，如果您有非常明确的要求，例如需要为单一业务实施系统，您可以使用单独的表格。

此外，如果您正在为特定的垂直市场或交易活动类型实施系统，您可以使用单独的表，例如，OS Commerce、Magento、Linnwork（小型电子商务订单管理）等系统为每个系统提供单独的表交易类型。

Answer 3

使用单独的表格。

我同意您将在两个表中拥有相似数据的观点，但销售订单标题和销售订单行不仅仅是表格的设计。

销售订单的概念在逻辑上与采购订单的概念大不相同。

在最基本的层面上，一个与债务人帐户直接相关，另一个与债权人帐户直接相关。

在库存变动方面，两者的程序也大不相同。例如。一个是向内的货物，它具有一整套相关的概念，如成本核算。而另一种是外向的货物，具有相关的送货信息，如快递员、送货费用等。

我假设如果您尝试复制 ERP，那么您还必须有某种制造工作订单表，当与销售订单和采购订单一起考虑时，它们与库存交易和库存位置的交互非常不同.当您考虑 1. 在上架期间将货物接收到某个位置时，与 2. 消耗收到的原材料并生成新的输出项目到不同的库存位置，与 3. 从工作订单而非零件生成的项目的销售订单之间的差异时收货流程，然后你开始发现试图将所有逻辑转储到一个表中是完全疯狂的。

您还需要考虑在可编程性方面使用单个表的影响。当您需要为事务锁定表时会发生什么？您现在已将所有用户锁定在与订单相关的所有数据中，包括。销售订单、采购订单和工程订单。

所以，简而言之，你需要把数据和逻辑分开。

我从未见过一个 ERP 数据库有一个表用于所有订单类型、所有股票交易或所有借方交易等。

任何说不同的人都是巨大比例的虚张声势。

如果有疑问，请记住 RELATIONAL 数据库系统的设计目的是让您可以跨多个表分离数据，从而减少与单表设计相关的问题，例如性能、表锁定、逻辑分离（存储过程、触发器等）。使用销售订单抬头编号（或等价物）作为关系键。这是一个更整洁的设计原则。