书店数据库设计答案

【问题标题】：Book Store Database Design书店数据库设计
【发布时间】：2009-04-11 14:37:05
【问题描述】：

我要建立一个书店，其中我们有 3 个实体（类）：Seller、Buyer、Book。我将数据库设计为以下详细信息：
- 买家和卖家都可以分别购买/出售一本或多本书籍。
- 如果买家想要出售一本书，他/她需要一个卖家账户。
- 买家将提供他们的价格，卖家想卖给最好的买家，我必须保存其中的所有信息。

在此模型中，process 类将是其他三个类的连接器：卖家书买家 -------- ------ -------- sID* bID* 按ID* 名称 --> sID

这是我的第一个想法，然后我发现这个模式在这个过程中会失败，因为买家可以同时购买多本书，还有其他原因。所以我改变了它：

在此模型中，process 类将是其他三个类的连接器： ______ ______ ________ _______ |卖家| |书 | |工艺 | |买家 | -------- -------- ---------- --------- |身份证* | |出价* | |身份证* | |按ID* | |姓名 | | XXX | --> |标识 | |日期&..| ---------- (*) 表示主键

我认为这会更好，但是如何使用价格优惠？
是的，我可以在 process 类中添加一个报价，所以我改变了主意，这个模型就出现了：（对不起，描述太长了）

*Offer* 字段将被添加到 *process* 类中： ______ ______ _________ _______ |卖家| |书 | |工艺 | |买家 | -------- -------- ------------ --------- |身份证* | |出价* | |身份证* | |按ID* | |姓名 | | XXX | --> |标识 | |报价 | |日期&..| ------------ (*) 表示主键

我对数据库设计感到非常困惑，因为这是我的第一次。这会满足系统需求吗？如果没有，我怎样才能让它工作？如果有，有没有更好的设计？

感谢任何建议，在此先感谢:)

更新 - 我真的无法在这里选择最佳答案，一切都有帮助。很多很多谢谢你们。希望你最好^o^

【问题讨论】：

嗨，artarad - 你能解释一下“多重优惠”是什么意思吗？
hihi :) 买家可以提供他们的价格来购买这本书，因此一本书可以只有一个买家但有 N 个报价者。

标签： mysql database database-design modeling

【解决方案1】：

如果买方可以是卖方（反之亦然），为什么不使用一个带有一组帐户类型标志的客户表？

如果书籍是唯一的（即，Moby Dick 的一份副本与另一份副本分开查看......更像 eBay 而不是亚马逊），那么您的 book 表可能有一个买家和卖家外键。您的商店最简单的设计现在只剩下两张桌子。例如：

Cust table
cust_id
name
is_buyer
is_seller

Book table
book_id
description
seller_cust_id
buyer_cust_id

编辑：我认为这个解决方案不会改变，即使一个买家/卖家必须有两个帐户。您只需在您的应用程序中添加客户不能既是买家又是卖家的限制。一张桌子的好处是您不需要复制安全/登录/等。逻辑...

编辑 2：另外，如果买家可以购买多本书，那么有一个购物车表来存储买家购买的每本书不是更有意义吗？

【讨论】：

哦，不！他们不可能。如果买家想卖东西，他/她需要创建一个卖家账户。
我也不同意。根据规范，您必须有一个额外的帐户 - 我会假设一个帐户是原子的，不应该与其他帐户共享任何数据。
Lantis 先生，您能否详细说明“帐户是原子的”的含义？我在 Wikipedia 上查找了“原子性（数据库系统）”，但他们对原子性的定义是关于事务（“全部发生”或“不发生”）。
感谢两位的回复。 @LucktLindy：这些书是独一无二的。如果一本书有多个报价怎么办？你的模型好用吗？
同意卡尔文的观点。我也不知道。

【解决方案2】：

我认为您需要一个类似于以下的域模型：

Buyer(BuyerId, ... buyer details ... )
Seller(SellerId, ... seller details ... )
Book(BookId, ... book details ... )
Bid(BidId, BuyerId, BookId, Price, Expiry)
Offer(OfferId, SellerId, BookId, Price, Expiry

它的工作原理是用户（买方或卖方）可以根据需要创建出价或出价。因此，如果您是买家，您可以从搜索可用的优惠开始。如果你喜欢一个，你可以选择接受它并继续结帐。也许您不太喜欢任何优惠，但价格接近您想要的。您可以创建出价并将其发送给要约的创建者以供考虑。

或者，如果没有什么符合您作为买家的要求，您可以创建一个出价并将其留在系统中，供潜在卖家浏览/搜索并考虑直到您选择的到期时间。

我添加了 Bid 和 Offer 类，我认为它们的好处是不言自明的。但是，如果您想进一步解释，请随时发表评论，我会回复。 Expiry 字段不是必需的，但很可能每个 Bid 和 Offer 都会有时间限制，在这种情况下您将需要它们。

我增加了类/表的数量，但我想您会发现您的系统变得更易于管理和扩展。

【讨论】：

我看的越多，我就越意识到它可以改进。正如 LuckLindy 所建议的那样，您确实应该有一个 User 类和 isBuyer/isSeller 字段，因为许多买家将成为卖家（正如已经指出的那样），并且您不想复制数据。

【解决方案3】：

如果我对您的理解正确，买家会在任何卖家做任何事情之前发出报价。然后卖家可以接受其中一个待处理的报价。我会在流程中添加一个买家 ID（实际上，当买家提出报价时会创建一个流程），以及图书 ID 和报价。一旦卖家完成交易，该过程可以通过 sID 字段链接到卖家。这样一来，买家就可以同时在不同书籍上持有多个报价。

【讨论】：

就是这样，你理解正确莫里斯。所以我的最新型号可以工作吗？
正如我所说，我会将报价移动到流程表中，并且我还将为其添加一个 bID 和一个 byID
感谢 Maurice，这个 SO 编辑器很烂，这不是你看到的我的最新模型。非常感谢。
您是否打算向买家提供目录（包含有关图书可用性的信息）？
我还是不知道，如果没有副本，我的想法是删除这本书，因为该应用程序将是旧书而不是新书的商店。

【解决方案4】：

让 LuckyLindy 的评论更进一步，使用单个 Customer 表，创建一个名为 Order 的表（可能类似于您的 Process 表）和一个名为 OrderItem 的表。您的买家和卖家都是客户......如果您的订单严格在两个人之间，那么您的订单表可以包含买家和卖家字段。对于 Order 中的每个项目，您在 OrderItem 中有一个元组（带有返回 Order 的 ID 以绑定组）。

Customer    Order         OrderItem
--------    -----------   ---------
id          id (pk)       id
name        date          order_id (fk)
            buyer (fk)    book
            seller (fk)   price
            total

这确实是一个基本示例，但它正在形成您的要求可以只使用一个常见的购物车设计。有很多examples you can find by Googling。

【讨论】：

【解决方案5】：

好吧，根据规范，我会做出一些假设：

买家和卖家需要单独的帐户 - 所以他们必须是原子的并且不能共享数据，因此我们将有两个表。
一本书是一个真实世界的实例。因此，如果卖家想出售 3 本书的《霍比特人》，则将产生 3 个表格行。
因此本书可能会涉及属性：seller（只读）和buyer。但这不适用于等待买家收到报价的“过程”。
由于可能存在“批量”购书，因此创建AuctionProcess 实体是有意义的。另外我会添加另一个Bid 实体。这导致了以下方案。
```
Seller(id*)
Buyer(id*)
Book(id*, seller_id)
AuctionProcess(id*, book_id, winning_bid_id, end_date, start_date?)
Bid(id*, process_id, buyer_id, price)
```
winning_bid_id 当然会是NULL，直到买家选出获胜者。

这与（刚刚注意到）Ankur 的响应非常相似，只是添加了winning_bid_id 关系。

【讨论】：

再次感谢您。我真的无法在这里选择最佳答案，所有帮助。

【解决方案6】：

这似乎有点令人困惑，数据模型、对象模型、功能性和非功能性规范和要求——每个部分都在讨论中。保持符号和设计元素干净、清晰和分开。

【讨论】：