书店的最佳销售数据库结构答案

【问题标题】：The best sale database structure for a book store书店的最佳销售数据库结构
【发布时间】：2018-02-15 22:54:08
【问题描述】：

我有两个数据库结构：

#1：每本书都是一行：

// sale 
+----+---------+-------------+
| id | book_id | customer_id |
+----+---------+-------------+
| 1  | 5       | 123         |
| 2  | 5       | 123         |
| 3  | 9       | 123         |
| 4  | 4       | 456         |
| 5  | 12      | 456         |
+----+---------+-------------+

#2：有数字列：

// sale 
+----+---------+-------------+--------+
| id | book_id | customer_id | number |
+----+---------+-------------+--------+
| 1  | 5       | 123         | 2      |
| 2  | 9       | 123         | 1      |
| 3  | 4       | 456         | 1      |
| 4  | 12      | 456         | 1      |
+----+---------+-------------+--------+

如您所见，第一个对于每本书都有不同的存在（这对将来的一些想法有好处，即退回的书籍需要返回日期，或者对多次采购给予一些折扣）同一本书或其他）。但第二个似乎更理想，因为它的行数更少。

不管怎样，你推荐哪一个？我个人喜欢第一个，我只是担心冗余。第一个结构是否有冗余？

【问题讨论】：

书店的数据库会有很多表——至少有几十个。也就是说，用于存储销售的表格将具有您所说的“冗余”，但这只是野兽的本性，因为该表格正在跟踪“事件”-“在这个日期，此时，在这家商店，这位顾客以这个价格买了这本书，并被这位员工借阅。”看到了吗？

标签： mysql database algorithm performance database-design

【解决方案1】：

在我的想法中，第一个解决方案是正确的。（第二个是错误的）

为什么：
根据您的解释，每笔销售都是一个新的有效对象（或记录），具有自己的数据，并且是自己的存在。

如您所说，每个销售对象（记录）都有 book_id、customer_id、sale_date、seller_id（或employee_id）、sale_price、sale_discount、sale_description、sale_payment_method 等。

只有 book_id 和 customer_id 看起来是相同的（只有当一个客户两次或多次阅读同一本书时），绝对不是冗余。

如果您将它们合并为第二种解决方案，您在设计其余设计和实施时会遇到很多困难。

对您的设计稍作改进：
您可以有两个实体，如 purchase_invoice 和 purchase_invoice_row，然后您可以在 purchase_invoice_row 中进行一些销售。（当时销售的任何书籍的数量）。我的意思是最好用两个实体来管理销售信息。（没有之一）

【讨论】：

【解决方案2】：

我认为您的第二个模型虽然过于简化，但却是一个更好的选择。但是，正如我所写的，它太简单了。以下是我可能会如何设计它：

Orders
    order_Id int auto increment primary key
    order_date datetime
    order_customer_id int (fk to customers)
    order_seller_id int (fk to sellers)
    unique index on order_date, order_customer_id and order_seller_id

OrderDetails
    OD_order_detail_id int auto increment primary key
    OD_order_id int (fk to orders)
    OD_item_id int (fk to books) 
    OD_pricePerUnit decimal (this is to support special discounts)
    OD_quantity int
    unique index on od_order_id, od_item_id

现在，对于退货退货之类的东西，您还有另一张桌子：

Returns
    return_id int auto increment primary key
    return_order_detail_id int (fk to order) 
    return_date datetime
    return_quantity int (the number of items returned)
    return_comment varchar(1000) (you will want to know why it's returned)
    unique index on return_order_detail id, return_date

如果您是 Codd 狂热者并且想要避免使用代理键，您可以放弃自动递增主键，而使用唯一索引。但是，这意味着您必须将唯一索引中指定的列的值传递到所有相关表中：

Orders
    order_Id int auto increment (just to have a numeric reference)
    order_date datetime
    order_customer_id int (fk to customers)
    order_seller_id int (fk to sellers)
    primary key on order_date, order_customer_id and order_seller_id

OrderDetails
    OD_order_detail_id int auto increment (just to have a numeric reference)
    OD_order_date int (fk to orders)
    OD_order_customer_id int (fk to orders)
    OD_order_seller_id int (fk to orders)
    OD_item_id int (fk to books) 
    OD_pricePerUnit decimal (this is to support special discounts)
    OD_quantity int
    primary key on od_order_id, od_item_id

【讨论】：