我正在为ERP等销售和购买应用程序设计DATABASE并使用MYSQL作为RDBMS，我怀疑为每个模块（销售/购买）创建销售和购买实体表以及单个表，或者每个模块都有多个表实体（销售订单，销售发票，销售退货，采购订单，采购发票，采购退货）从长远来看。以下是我的用例。
我的申请还将包含销售订单，销售交货，销售发票，销售退货和信用票据以及购买模块的相同实体，并且所有这些实体可以在该模块中输入链接。如销售订单可以转换为销售交货或销售订单，销售交货可以转换为销售发票。因此需要维护模块中每个实体的参考b / w。
现在，我很少混淆将所有这些保留在一个表中，每个模块说“sale_entity”和“purchase_entity”具有实体类型或者我应该为每个实体类型创建单独的表，例如sale_order，sale_invoice，sale_return，purchase_order，purchase_invoice ，purchase_return等。
以下是我对这两种情况的看法：
单表：我真的希望将它保存在每个模块的单个表中，但我担心长时间运行的性能，它会快速增加表大小并可能降低性能。 / p>
多表：一次性管理，维护关系以及在报告中为所有实体类型的记录提取数据都很困难，需要使用union和all。
我的理解是，大尺寸的表比表的小尺寸执行速度慢，如果我错了，请更正。
请注意一下，并建议我该怎么办。
谢谢
答案 0 :(得分：5)
经验法则：如果两个表具有相同（或几乎相同）的列，则将其设为一个表，而不是两个。您可能需要添加一列来区分这两种类型的数据。您可能需要列NULL，如果它适用于一个用途而不适用于另一个用途。 NULLable列过多 - ＆gt;不要合并表格。
经验法则：一对多和多对多关系要求有两个或三个表。 （第三个是多对多的。）
“订单”通常涉及“订单商品”。这是Orders中的一行映射到一个或多个OrderItems。那些应该是单独的表格。
“购买”与“退货”？ 也许他们可能在同一个表格中，并通过amount的符号进行区分？
答案 1 :(得分：4)
去一张桌子！ 如果不这样做，您将会得到许多重复数据，这些数据将很难维护。
使用UNION AND JOIN等...是最慢的查询方法。尽量避免使用它们。
要使用单个表格将sale_order更新为sale_delivery，需要执行以下查询：UPDATE orders SET orderType = 3 WHERE orderId = 1533
要将sale_order更新为包含多个表的sale_delivery，需要执行以下查询：
INSERT INTO sale_delivery
(orderId, clientId, ....)
SELECT orderId, clientId, ...
FROM sale_order;
你可以看到这种方法会慢很多，你将不得不删除原来的sale_order。希望插入成功。
你将如何处理orderId？我想你要使用自动增量，你打算将它复制到另一个表吗？你怎么知道另一个表中仍然可以使用id？
你打算用order_details做什么？您必须将它们与订单匹配。当您将订单复制到新表时，是否要更新关系？
结论：请坚持一张桌子。一定要创建索引。
然而，您可以做的是按最终用户公司拆分数据库。当您要获得永远不会一起使用的数据时，您可以为新数据创建一个新数据库。
答案 2 :(得分：4)
使用单独的表格。
我同意这样的想法，即两个表中都会有类似的数据，但销售订单表头和销售订单表不仅仅是表格的设计。
销售订单的概念在逻辑上与采购订单的概念非常不同。
最基本的一级与债务人账户直接相关，一个与债权人账户直接相关。
在库存变动方面，两者的程序也各不相同。例如。一个是货物内部，它有一整套概念，如成本相关。而另一种是向外的货物，其具有相关的交货信息，如快递，交货成本等。
我假设如果您正在尝试复制ERP，那么您还必须拥有某种制造工作订单表，当与销售订单和采购订单一起考虑时，与库存交易和库存地点的交互方式会有很大不同。当您考虑1.在上架期间将货物接收到某个地点之间的差异，以及2.消耗原材料并将新的输出项目生成到不同的库存地点之间的差异，以及3.从工作订单生成的项目的销售订单而不是部分货物内部接收过程，然后你开始看到试图将所有逻辑转储到一个表中将是完全疯狂。
您还需要考虑在可编程性方面具有单个表的影响。当您需要为事务锁定表时会发生什么？您现在已将所有用户锁定在与订单相关的所有数据中。销售订单，采购订单和工单。
因此，简而言之，您需要将数据与逻辑分开。
我从未见过ERP数据库对所有订单类型，所有股票交易或所有债务人交易等都有一个表格。
任何说不同的人都是不朽的虚张声势。
如果有疑问，请记住RELATIONAL数据库系统的设计使您可以跨多个表分隔数据，从而减少与单表设计相关的问题，如性能，表锁定，逻辑分离（存储过程，触发器等）。使用销售订单标题编号（或equivelant）作为关系密钥。它的设计原则更为整洁。
答案 3 :(得分：-1)
较大的 ERP 平台倾向于将所有交易数据存储在单个表中。示例包括 NetSuite 和 Odoo。
这些系统往往具有交易的通用概念，并允许用户通过自定义引擎创建新类型的交易。
较小的 ERP 系统，尤其是那些针对特定垂直市场的系统，通常为每种交易类型提供单独的表格。
因此，这两种方法可能存在争议。作为一般规则，如果您有一个非常明确的需求，例如需要为单个业务实施一个系统，您可以使用单独的表。
此外，如果您要为特定的垂直市场或交易活动类型实施系统，则可以使用单独的表格，例如，OS Commerce、Magento、Linnwork（小型电子商务订单管理）等系统为每个表格都有单独的表格交易类型。