Database design 创建一个简单的（但不适合我）db

我正试图建立一个数据库来跟踪craigslist的一个小型销售业务

基本上，这些家伙是怎么运作的

有人买3本书，每本10美元

他们把它贴在CL上

他们卖20美元

购买者每卖出一本书就可以得到10美元，外加1/3的利润

问题是，他们每次几乎都买同一本书，但价格却在变化。有时，他们花12美元买这本书，另花15美元。如果市场对他们有利，他们会买其他的书

我想做的是建立一个目录表，根据书名和购买价格跟踪这些书

所以如果我们有10本“绿鸡蛋和火腿”的书，每本10美元，而我们有5本“绿鸡蛋和火腿”的书，每本15美元。库存清单应反映两个单独的项目。这是为了让投资者获得适当的投资报酬

我很难用这种方式设计db。我有以下表格：

产品

• IDPK
• 名字
• 描述

库存

SELECT ID, ProductName, 
       (SELECT Sum(Quantity) FROM Purchase WHERE ProductID=Product.ID) -
       (SELECT Sum(Quantity) FROM Sale WHERE ProductID=Product.ID) AS NumInStock
FROM Product

• 身份证
• 购买日期
• 产品IDPK
• 购买价格PK
• 数量

采购

• IDPK
• 产品标识
• 产品质量
• 购买价格

到目前为止，我的理由是我应该在产品表中记录他们销售的产品类型。还要跟踪他们何时购买一件物品，以及在给定时间购买该物品的数量；因此，采购表。然后，我想建立一个清单，列出我在库存中拥有的东西，但每个记录都需要根据物品及其成本进行唯一化。所以我决定使用购买价格和产品Id的复合键来实现这一点

如果字段不是主键，是否可以使用将采购价格和产品ID从采购表关联到我的库存表？到目前为止，我的方法是否适合我正在努力实现的目标？有没有更好的方法来做我想做的事

我还没有提到db中的其他元素，但如果有必要的话，我会提到

---

感谢所有能帮助我的人。

那么，在产品进入库存之前，应该先购买，对吗？只需将PurchasingID用作库存表中的外键-这将消除在两个表中使用采购价格的需要。
编辑：
它将是这样的：
产品
ID PK
名称
描述

库存
ID PK
购买日期
数量
采购标识FK

采购
ID PK
产品标识FK
产品质量
购买价格

---

根据您的需求，您可能需要在采购和库存之间增加一张表格

产品

• IDPK
• 产品名称
• 描述

购买

• IDPK
• ProductIDFK
• PurchDate
• 数量
• 买价

销售

• IDPK
• ProductIDFK
• 销售日期
• 数量
• 销售价格

库存

SELECT ID, ProductName, 
       (SELECT Sum(Quantity) FROM Purchase WHERE ProductID=Product.ID) -
       (SELECT Sum(Quantity) FROM Sale WHERE ProductID=Product.ID) AS NumInStock
FROM Product

上面的查询所做的是从Product表返回ID和ProductName，并计算该商品的库存数量。第一个子查询

（从采购中选择Sum（Quantity），其中ProductID=Product.ID）

返回已采购的所有匹配项目的总和。然后，它从该总数中减去已售出的所有匹配项目的总和

（选择sum（Quantity）from Sale，其中ProductID=Product.ID）

，得出库存量

要获得以100美元购买的iPad数量，您可以使用如下查询：

SELECT Sum(Quantity) AS NumiPadsFor100
FROM Purchase WHERE PurchPrice = 100

---

为了获得某一特定项目的利润，在查询中执行所有操作会有点麻烦，但在代码中执行起来会很简单。

1个表用于产品，1个表用于移动（销售和购买）。这样，您的库存将非常容易。如果有大量（比如说每年超过50000次移动），您可能需要查看。

所以我不需要库存关系？只是一个库存视图，这就是你说的吗？没错。如果你跟踪你的购买和销售，那么区别在于你的现有库存。你能解释一下这个sql语句吗，我对这个很熟悉。问题是我需要根据每件商品的成本来盘点。我需要能够拿出我以100美元的价格购买的“iPad”，你不需要库存，因为它是从移动中衍生出来的。购买和销售也不需要单独的表格。一张桌子的移动就足够了，数量的符号会起作用：+表示输入，-表示输出。只需将按Ref分组的移动相加，您就有了库存。是的，但我不确定如何设计另一个表，以及它应该如何与DB的其余部分交互。