1

我有一个关于 SQL 的问题。我有以下 SQL 表（为便于理解而简化）：

客户端（clientId INT PRIMARY KEY）

产品（productId 主键）

订单（orderId PRIMARY，clientId 是 Client 的外键，productId 是 Product 的外键）

我还有一个名为 Inventory 的表，它应该包含每种产品的库存商品数量。Inventory 的主键称为 productId（主键），它引用 Order 中的外键。不幸的是，当我尝试添加到 Inventory 表时，它给了我以下错误：

"The INSERT statement conflicted with the FOREIGN KEY constraint "FK_Order_Iventory1". The conflict occurred in database "GestionInventaire", table "dbo.Inventory", column 'productId'."

我希望 Inventory 表的主 ID (productId) 是 Order (productId) 中的外键，它来自 Product 表。

任何帮助表示赞赏！如果需要任何进一步的解释，我将尝试进一步详细说明。

4

3 回答 3

1

基于上面列出的 SQL 示例（SQL Server）：

create table client (
  clientid int not null primary key
)
create table product (
  productid int not null primary key
)
create table [order] (
  orderid int not null primary key,
  clientid int not null foreign key references client (clientid),
  productid int not null foreign key references product (productid)
)

insert into client values (1)
insert into product values (1)

insert into [order] values (1,1,1)  -- should work
insert into [order] values (2,1,2)  -- should fail


create table inventory (
    productid int not null foreign key references product (productid),
    stock int not null default 0
)

insert into inventory values (1,10)  -- worked with no problems

外键引用检查它们的值是否存在于父表中 - 当您看到外键约束错误时，这意味着您尝试插入具有外键约束的列中的值在它引用的父表中不存在。

于 2012-11-19T23:59:56.467 回答
1

Inventory 的主键称为 productId（主键），它引用 Order 中的外键。

为什么？Inventory对我来说，如果主键 in引用主键 in会更有意义Product。

于 2012-11-20T00:10:02.683 回答
1

这取决于每种产品的库存信息有多复杂：

仅存储每个产品的最新库存编号集

If you are simply storing the current stock number(s) for each product (e.g. a one-to-one mapping of Product to Inventory), then there's no need for Inventory to have it's own table, it would make more sense to store the number in stock directly in the Product table.

Whilst there may be a logical division in your code model between the product information and the inventory data, that doesnt necessarily mean its a good idea to store the data in multiple tables unless you're handling huge amounts of data and performance is becoming an issue. Even if it's stored in a single table, you can still seperate the data into multiple objects as and when you query it and build your model objects.

(That's not to say there aren't legitimate situations where it might be a good idea to do this, but I wouldn't consider it unless there were no better alternatives)

Storing multiple sets of stock numbers for each product

If on the other hand you're wanting to store a history of the stock levels (a one-to-many mapping from Product to Inventory) then it would make sense to have an Inventory table, but I'd suggest giving it it's own primary key and having a foreign key from productID to the Product table.

e.g. Inventory table containing "InventoryID" (primary key), "ProductID" (foreign key to Product.ProductID) and whatever columns you need to store the stock numbers.

Why Foreign key to Order table?

Either way it doesn't really make any sense for Inventory.productID to be a foreign key to Order.productID, since the stock is related to a product, not an order (unless you're doing live calculations based on the quantities in and out in which case the structure would be a bit more complex).

于 2012-11-20T00:32:50.267 回答