Irf*_*gwb 2 mysql database erp rdbms database-design
我正在为ERP等销售和购买应用程序设计DATABASE，并使用MYSQL作为RDBMS，我对创建销售和购买实体表与每个模块的单个表（销售/购买）或每个实体多个表（销售）存有疑问订单，销售发票，销售退货，采购订单，购买发票，购买退货）在更长的时间内运行。以下是我的用例。
我的应用程序还将具有“销售订单”，“销售交货”，“销售发票”，“销售退货”和“贷方通知单”以及“采购”模块的同一实体，所有这些实体都可以在该模块中输入链接。像销售订单可以转换成销售交货或销售订单，销售交货可以转换成销售发票。因此，需要维护参考b / w模块的每个实体。
现在，对于将具有实体类型的每个模块都说“ sale_entity”和“ purchase_entity”的所有模块都保留在一个表中，还是应该为每个实体类型创建单独的表，例如sale_order，sale_invoice，sale_return，purchase_order，purchase_invoice，purchase_return等。
以下是我在两种情况下想到的内容：
单个表：我确实想将每个模块的单个表都保留在单个表中，但是我担心长时间运行会降低性能，它将迅速增加表的大小并可能降低性能。
多表：难以同时管理，维护关系和获取报表中所有实体类型的记录中的数据，这需要并集所有。
我的理解是，大表的性能比小表的性能慢，如果我错了，请纠正。
请对此进行一些说明，并建议我应该如何进行。
谢谢
Rule of thumb: If two table have identical (or nearly identical) columns, make it one table, not two. You may need to add a column to distinguish the two types of data. You may need to have a column be NULL if it applies to one use but not the other. Too many NULLable columns --> don't combine the tables.
Rule of thumb: One-to-many and many-to-many relationships require having two or three tables. (The third is for many-to-many.)
"Orders" usually involved "Order Items". That is one row in Orders maps to one or more OrderItems. Those should be separate tables.
“购买”与“退货”？ 也许它们可以在同一张桌子上，并用符号区分amount？
使用单独的表。
我同意这样的观点，即您在两个表中都将具有相似的数据，但是销售订单标题和销售订单行不仅仅包含表的设计。
从逻辑上说，销售订单的概念与采购订单的概念有很大不同。
在最基本的层次上，一个直接与债务人帐户相关，一个与债权人帐户相关。
两者在库存移动方面也有非常不同的程序。例如，一个是内部货物，它具有诸如成本相关的一整套概念。而另一种是向外交货的货物，具有相关的交货信息，例如快递，交货成本等。
我假设如果您要复制ERP，那么您还必须具有某种制造工作订单表，将其与销售订单和采购订单一起考虑时，它们与库存交易和库存位置的交互作用非常不同。考虑以下因素之间的区别：1.上架期间将货物接收到某个位置； 2.消耗已接收的原材料并在不同的库存位置生成新的输出项目； 3.从工作订单而非零件中生成的项目的销售订单在进货过程中，您开始发现尝试将所有逻辑转储到单个表中完全是疯狂的。
您还需要考虑在可编程性方面拥有单个表的影响。当您需要为事务锁定表时会发生什么？现在，您已将所有用户从与订单（包括订单）相关的所有数据中锁定。销售订单，采购订单和工程订单。
因此，简而言之，您需要将数据与逻辑分开。
我从未见过一个ERP数据库，该数据库具有用于所有订单类型，所有库存交易或所有借方交易等的单个表。
任何说不同的人都是巨大的挑战。
如有疑问，请记住，RELATIONAL数据库系统的设计旨在使您可以跨多个表分离数据，从而减少与单个表设计相关的问题，例如性能，表锁定，逻辑分离（存储过程，触发器等）。使用销售订单抬头编号（或等号）作为关系关键字。它的设计原则更为简洁。