我一直在设计一个在线商店系统的数据库.通过阅读本网站的一些帖子我遇到的问题是,虽然我可以使用复合主键,下面我将要解释一下,这是否真的是一个不好的做法(根据我在这方面阅读的帖子)很多人说这是一个糟糕的做法,这就是为什么我问).
我想在单独的表格中存储订单的付款.原因是,一个订单可以有许多项目以多对多关系的形式在单独的表中处理.现在,如果我不使用复合主键作为我的付款表,我将失去我唯一的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的概念有关.如果定义是因为存在订单而存在的付款,则将订单作为主键的一部分.
