拥有两个具有相同结构的SQL表是否有效？

在库存/生产系统中，我通常实现与以下描述类似的表结构

--- Raw Item ---
id INT(10) UNSIGNED AUTO_INCREMENT,
name VARCHAR(32) NOT NULL,
description VARCHAR(128) NOT NULL,
ideal INT(10) UNSIGNED,
PRIMARY KEY(id)

和另一个表，其中处理的项目具有相同的字段

具有类似结构的客户端和提供者的下一个表

然后是具有类似结构的收入订单和结果订单的表格

最后，一个表格建立了某个加工项目与生产批次所需的原始项目类型（含数量）之间的关系

---

它表现得很好。。。但是我想知道是否合并类似的表并添加一个字段（如“type”）会更好，我想请您提供一些建议。

我想这将稍微取决于您选择的数据库模式。有关更多信息，请参阅此链接

每一个都会为您提供不同程度的性能改进，并在某些方面缺乏功能。我想真正的问题是你想处理多个表，还是处理一个表更容易

一个简单的解决方案是在表中添加一些简单的内容，比如状态。然后，只需更改查询以根据状态运行检查。将两个表保存为一个非常简单且节省空间的方法

--- Raw Item ---
id INT(10) UNSIGNED AUTO_INCREMENT,
name VARCHAR(32) NOT NULL,
description VARCHAR(128) NOT NULL,
ideal INT(10) UNSIGNED,
status VARCHAR(9) NOT NULL,
PRIMARY KEY(id)

SELECT * from items WHERE status="PROCESSED";

---

我个人更喜欢这种方法。它只剩下一个库存表，而不是让多个表把数据库模式弄得乱七八糟。更不用说它是否会进一步扩展（比如，您有新的、已处理的和已存档的）。

在我看来，添加一个人工类型来组合类似的数据不是3NF。使用单独的表，除非您需要同一表中的数据

客户端和提供者有相似的字段，但它们是两个不同的东西

---

如果订单从采购订单迁移到已处理订单，则是同一件事，并且应该有一个状态标志。如果要将数据从一个表移动到另一个表，则首选使用标志合并

这是一个好问题，很多好问题的答案都是“视情况而定”

IMHO可以为不同的工件（具有相似属性）创建类似的（内部结构化表）。 看看你能得到什么：

Owner
Id, Name

Pet
Id, Name

列相同但含义不同的表。 当然，您可以在同一个表中获得Items和RawItens，并且只使用一个标志列来区分两者。您甚至可以使用自引用FK将项目与Ramitem关联，但这会如何影响性能

随着表的增长，引擎将需要更多的时间（资源、内存、cpu）来检索行/数据。如果你把行数加倍。。。对于大多数DBMS，对表进行加倍会影响性能，更不用说对表行进行加倍了

它还影响进化维护。如果您现在需要为您的原始项目添加一列，而不是为您的项目添加一列，则可能会浪费空间

---

“合并”类似的表会增加理解模式的难度，而不是简化模式。

随着时间的推移，您将如何使用数据？如果您需要将所有这些表组合在一起进行报告，那么如果一个表非常大，则最好使用分区。如果在流程移动时需要将记录从一个表移动到另一个表，那么如果一个流程的所有记录都在一个表中，则更容易检查该流程的状态

此外，如果事物是非常不同的实体，那么它们可能有不同的相关表，然后将它们组合在一起只会弄乱情况，使数据库更难理解，并降低PK/FK关系的有效性。在这种情况下，单独的表最有意义。如果您认为随着当前计划功能的添加，数据会随着时间的推移而发生变化，那么这也是最有意义的

例如，一个客户和一个销售代表。他们可能有许多相同的字段，但他们的相关内容将非常不同，您不希望客户能够被放入代表的子表中。因此，现在您必须与多个FK建立关系。此外，如果您有足够多的子表，则删除记录会变得很困难。db必须检查所有表，即使其中只有一半可能适用于特定记录

---

在我所看到的一个数据库中，原始设计器将两个不同的东西组合在一起，但在父级具有相同的字段，最终在该表上有100多个FK。从那张表中删除而从不快速是一场噩梦。偶尔也会出现数据完整性问题，其中一种类型的记录出现在错误的子表中。

最好有一个带有标志的表，例如某个项是否已被处理。如果要在某个查询中合并表，则使用单个表也有好处。对于单个表，您可以使用更具包容性的WHERE子句而不是UNION。