若要使列上唯一的组合或添加数字rowID

我在那里我存储有关零售产品的详细信息的表格：

Name Barcode BarcodeFormat etc... 
----------------------------------------

(Name, Barcode, BarcodeFormat)三列将唯一标识表（候选键）的记录。但是，我还有其他需要FK的桌子。于是我介绍了auto_increment列itemId并提出了PK。

我的问题是 - 我应该有PK为(itemId, Name, Barcode, BarcodeFormat)或者是否应该有PK(itemId)和UNIQUE(Name, Barcode, BarcodeFormat)。

我最关心的是INSERT和SELECT操作方面，而且在尺寸评论也欢迎表演。

我使用的是mysql

来源

2012-01-19 Code Poet

绝对的innodb表：PK（的itemId）和UNIQUE（名称，条形码，BarcodeFormat）。

你不想使用多部分键的麻烦您所有的连接等
您也许有一天有了行没有它本身就不是唯一条形码值，所以你不要并不希望你的模型具有硬连线的独特性（你可以在不破坏任何关系的情况下轻松地删除它）
对唯一性的约束是一个业务级问题，而不是数据库实体之一：你总是需要一个密钥，但您并不总是需要唯一性的业务规则

来源

2012-01-19 06:17:20 Bohemian

喜欢它...... –

-1'主键'的选择是任意的。最后一点特别令人困惑：完整性约束应该是业务规则数据库中的逻辑表示;如果他们不是那么你是在做一些严重错误的事情！ – onedaywhen

@onedaywhen你完全错过了我的观点。独特的组合是*商业*为中心的概念，因此随着业务需求的变化，随时可能随时发生变化（如我的完全合理的产品示例*没有条形码，这将打破独特的约束）。但是，对主键的需求是*永久性的，因此可能会超过对唯一约束的需求。通过分离这两者，您可以提高灵活性和可维护性。通过合并两者，您将数据库要求锁定到*当前*业务需求（您最好希望业务不会发生变化） – Bohemian

除非您拥有数百万种产品或非常高的吞吐量要求，否则在性能方面不会有太大的差别。

我的首选是有一个代理PK（即自动增量列，您的第二个选项PK(itemId)和UNIQUE(Name, Barcode, BarcodeFormat)），因为如果业务密钥更改更易于管理。

来源

2012-01-19 06:17:27

如果你已经添加了一个itemId，那么你应该使用它作为PK，并有其他三列与一个UNIQUE。

如果你没有itemId，那么你可以使用其他列作为PK，但它可能会变得很难在任何地方。在这种情况下，它并不是很好，因为产品应该有一个id，因为它是一个实体，但是如果它只是一个关系，那么就不会有id列。

来源

2012-01-19 06:19:07 Luis

您有两个候选键。我们将三列复合键称为'自然键'和auto_increment列（在这种情况下）是'代理键'。在数据库级别都需要唯一约束（小写字母表示“唯一”以表示逻辑）。

可选地，一个候选键可以被指定为“主要”。选择哪个键（如果有的话）应该是这个名称是任意的。谨防任何人在这件事上给你明确的建议！

来源

2012-01-19 08:30:09 onedaywhen

若要使列上唯一的组合或添加数字rowID

回答

相关问题