3

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

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


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



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




我认为这会更好，但是如何开始使用价格优惠？

是的，我可以在流程类中添加一个报价，所以我改变了主意，这个模型就出现了：（对不起，描述太长了）



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

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

任何建议表示赞赏，在此先感谢:)

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

4

6 回答 6

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：另外，如果买家可以购买多本书，那么拥有一个购物车表来存储买家购买的每本书不是更有意义吗？

于 2009-04-11T14:40:43.877 回答
1

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

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 都会有时间限制，在这种情况下您将需要它们。

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

于 2009-04-11T14:59:54.720 回答
0

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

于 2009-05-23T00:53:16.673 回答
0

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

于 2009-04-11T14:54:23.267 回答
0

将 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

这确实是一个基本示例，但它正在形成您的需求可以只使用一个常见的购物车设计。您可以通过 Google 搜索找到很多示例。

于 2009-04-11T14:55:05.120 回答
0

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

  • 买家和卖家需要单独的账户——所以他们必须是原子的并且不能共享数据，因此我们将有两个表。
  • 一本书是一个真实世界的实例。因此，如果卖家想要出售 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关系。

于 2009-04-11T15:09:32.263 回答