问帮助理解MySQL中二手书店项目的数据库设计逻辑

EN

是的，您可以使用一个表来跟踪已售出和未售出的物品。它类似于OLTP中的事务表，区别是事务一直处于打开状态，直到销售结束。从理论上讲，这是一个好主意，因为这将是3NF (假设上市和销售是1-1)，但它的实践，它更常见的做法是从实际销售交易中去美化待售清单。有几个实际的原因，我可以详细说明，如果你需要证明这一决定。

如果决定将它们合并到一个表中，那么它将是一个sale_transactions表，它与用户有着多到多的关系。在该项目出售之前，buyer_user_id将为空，它还应包括product_id、listing_price、listing_date、sale_date和税收等内容。

如果您愿意分离这些表，那么您将有一个for_sale表和一个sales_history表(或者仅仅是sales或类似的)表。您可能希望将sales_history与orders表结合起来，这取决于您计划如何填充它们。

• for_sale表中有listing_id、listing_user_id、product_id、list_price、listing_date和units_available。这表示要出售的项目，其优点是只有一行要出售多个单元(而上面的组合sale_transaction表只适用于单个单元)。当单位出售，available_units下降，直到它达到零。此时，您可以将行保留为历史记录，或者删除它。(虽然多个单位可能不适用于这种情况，但如果卖家通常只有一本书。)
• sales_history表中有listing_id、buyer_user_id、sale_date，可能还有order_id (取决于您希望如何将订单与销售相关联)。

因此，买入/卖出的情形如下：

1. 用户列出了一本出售的书。for_sale表中与产品、卖方等有关的新条目。
2. 用户搜索出售的书籍。查询连接到产品和类别表的for_sale表，以获得要出售的所有产品及其详细信息的列表。
3. 用户买一本书。sales_history表中的新条目与清单、买方等一起更新。for_sale表中的条目被更新，使units_available减少1。(或者删除该行，用一个标志标记它，或者以其他方式表示它不可用)。

1. 你不卖给用户，你卖给各方(公司或个人)。有些人可能会扮演用户的角色。
2. 在销售/购买订单中有许多参与方：
   • 卖主(如果你卖的话)
   • 买家(如果你买的话)
   • 以寄售方式出售某物的聚会
   • 销售人员收取佣金
   • 下订单的一方
   • 接受点菜的人(办事员)
   • 支付定单的一方
   • 应向其运送订单项目的当事人

帮你自己一个忙，得到一本数据模型模式书，不要重新发明轮子:)

现成数据库模型示例