我有一个数据库存储客户对产品的查询。
查询参考（文本）、产品编号（int）和修订号（int）一起唯一标识销售和客户之间的单个讨论。
因此，有许多表格，每个表格都包含有关单个查询的特定详细信息，由 enq、pdt 和 rev 值组合而成。
CREATE TABLE 不会对任何字段使用任何 AUTO INCREMENT UNIQUE PRIMARY KEY。
我的问题是，这种数据库设计是否可以接受？ 是否应该始终对表进行规范化？
感谢您的建议。
【问题讨论】：
标签： database database-design normalization
拥有PRIMARY KEY（或UNIQUE 约束）首先将确保这些值确实是唯一的，其次将大大改善对给定查询的搜索。
PRIMARY KEY 意味着在(enq, pdt, rev) 上创建索引，并且此查询：
SELECT *
FROM enquiries
WHERE enq = 'enquiry'
AND pdt = 'product'
AND rev = 'revision'
将在一次索引查找中完成。
如果没有索引，此查询将需要扫描整个表，并且不能保证您最终不会得到重复。
除非非常、非常、非常特殊的情况（例如大量插入的日志表），否则您的表上应该始终有一个 PRIMARY KEY。
【讨论】：
这是两个问题。 (1) 不需要总是有一个自动增量键。但它很实用，因为您可以使用它来轻松操作数据。没有重复也不是必须的。 (2) 当你为学校做作业时，规范化是必须的，但如果事情变得困难，你可以打破它，以便在不危及数据完整性的情况下让你的生活更轻松。
【讨论】：
没有必要使用 AUTOINCREMENT，但每个表都应该有某种 PRIMARY KEY。主键可以是多个字段的组合，它们共同唯一地标识记录。
根据您告诉我们的情况，是的，如果您明确声明查询参考（文本）、产品编号（int）和修订号（int）的组合作为主键，则该设计是可以接受的唯一标识单个讨论。
人们有时出于性能原因对数据库进行非规范化。如果选择查询比插入和更新频繁得多，并且感兴趣的选择查询由于要连接的表的数量而返回缓慢，则考虑非规范化。
如果您提供运行缓慢的特定查询，您将获得很多具体建议。
【讨论】：
就我个人而言，我总是在所有表上都有某种主键，即使它是一个自动递增的数字，没有其他用途
关于规范化，我认为应该争取规范化的表，但实际上有很多很好的理由，当表设计好但没有规范化时。这就是 DB 设计的“理论”与现实相遇的地方——但最好知道什么是规范化，争取它，并在你偏离规则时有充分的理由（而不是仅仅不了解规则或更糟糕的是忽略良好的设计规则）。
【讨论】：
我在这一个上从群中分裂。不要将您的查询参考（文本）、产品编号（int）和修订号（int）作为主键。您表示查询参考是文本类型，您的意思是它的宽度为 25 或 50 或 500 个字符？如果主键是由这些字段组成的，那么在我看来它将太宽，因为它将附加到为该表创建的每个索引中，从而将每个索引行的大小增加三个字段的大小和任何需要使用的表返回此表的外键也需要这三个字段。
使这三个字段成为唯一索引。放置一个自增值作为主键并使其成为聚集索引。将链接回此主表的表在内存中的占用空间很小，以便将表一的数据链接到表二。
就规范化而言，无论是否规范化，如果您的数据只有几千行，甚至 50,000 或 500,000 行，都无关紧要。当数据开始变得大于可用的 RAM 缓存时，这是一个问题。
设计一个视图以将数据呈现给应用程序以实现业务规则。设计存储过程以接受要存储的数据。设计表结构以满足 SLA 中的响应时间。如果您必须规范化或非规范化或分区或索引或获得更大的服务器来满足 SLA，应用永远不会知道，因为您始终通过符合业务规则的视图提供数据。
【讨论】：
规范化理论中没有任何内容涉及表应该具有简单主键还是复合主键。信不信由你，“主键”的概念不是数据关系模型的组成部分。
话虽如此，表几乎总是应该使用主键来定义。主键不必是单列，也不必由自动增量填充。在您的情况下，它可能是三列一起唯一标识一个查询。
如果一个表没有声明的主键，它可能会出现重复的行。具有重复行的表表示一袋元组，而不是一组元组。一旦你处理的是袋子而不是集合，关系模型预测的结果就不需要应用了。这就是防止重复行如此重要的原因。
【讨论】：