sql – 复合主键：是好还是坏

我一直在设计一个在线商店系统的数据库.通过阅读本网站的一些帖子我遇到的问题是,虽然我可以使用复合主键,下面我将要解释一下,这是否真的是一个不好的做法(根据我在这方面阅读的帖子)很多人说这是一个糟糕的做法,这就是为什么我问).

我想在单独的表格中存储订单的付款.原因是,一个订单可以有许多项目以多对多关系的形式在单独的表中处理.现在,如果我不使用复合主键作为我的付款表,我将失去我唯一的PaymentID：

[PaymentId] INT IDENTITY(1,1) NOT NULL PRIMARY KEY,[OrderId] INT NOT NULL PRIMARY KEY --Also a Foreign Key--

现在,如果我只是删除了OrderId的主键,我将丢失一对一的关系,所以很多OrderIds可以关联到很多PaymentIds,我不想这样.

这就是为什么以前提到的问题已经得出结论(主要是)复合关键是一个坏主意.所以我想为自己澄清一下如果不好,那么最好的做法是什么？

解决方法

没有结论是复合主键是坏的.

最好的做法是让一些列或列唯一标识一行.但是在某些表中,单个列本身不足以唯一地标识一行.

sql(和关系模型)允许复合主键.这是一个很好的做法是有些情况.或者,另一种看待它的方式是,在所有情况下这不是一个糟糕的做法.

有些人认为,每个表都应该有一个自动生成唯一值的整数列,它应该作为主键.有些人也声称这个主键列应该始终被称为id.但这些是公约,不一定是最佳做法.公约有一些好处,因为它简化了某些决定.但公约也是限制性的.

您可能会有多笔付款的订单,因为有些人购买了on layaway,否则他们有多个付款来源(例如两张信用卡),或两个不同的人想要支付一份订单(我经常去餐厅与朋友,我们每个人都为自己的餐饮,所以工作人员处理我们每个信用卡的一半订单).

我将设计您描述的系统如下：

Products  : product_id (PK)

Orders    : order_id (PK)

LineItems : product_id is (FK) to Products
            order_id is (FK) to Orders
            (product_id,order_id) is (PK)

Payments  : order_id (FK)
            payment_id - ordinal for each order_id
            (order_id,payment_id) is (PK)

这也与identifying relationship的概念有关.如果定义是因为存在订单而存在的付款,则将订单作为主键的一部分.

注意LineItems表还缺少自己的自动增量单列主键.多对多表是一个很好的使用复合主键的典型例子.

原文地址：https://www.jb51.cc/mssql/75776.html

sql – 复合主键：是好还是坏

解决方法

相关推荐