Question

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

In this model the process class will be the other three classes connector:
    seller       book      buyer 
   -------      ------    -------
     sID*        bID*       byID* 
     name  -->   sID     

This was my first thought & then I found out that this schema will fail in the process due to a buyer could buy multiple books at same time and there were other reasons, too. so I changed it:

In this model the process class will be the other three classes connector:
     ______       ______       ________       _______
    |seller|     | book |     |process |     | buyer |
    --------     --------     ----------     ---------
    | sID* |     | bID* |     | pID*   |     | byID* |
    | name |     | XXX  | --> | sID    |  |date &..|
                              ----------
(*) indicates a primary key  


this will work better I think, but how to get into work with Price offers?

yes, I can add a offer to the process class, so I've changed my mind & this model came into the place: (sorry for long description)


The *Offer* field will be added to the *process* class: 
     ______       ______       _________       _______  
    |seller|     | book |     |process  |     | buyer | 
    --------     --------     -----------     ---------  
    | sID* |     | bID* |     |  pID*   |     | byID* |   
    | name |     | XXX  | --> |  sID    |  |  offer  |
                              | date &..|
                              -----------       
(*) indicates a primary key

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

任何建议都表示赞赏，提前谢谢：）

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

Answer 1

如果买家可以成为卖家（反之亦然），为什么不为一个客户表提供一组帐户类型的标志？

如果书籍是独一无二的（即Moby Dick的一个副本被视为与另一个副本分开...更像是eBay而不是亚马逊），那么您的书籍表可能有买家和卖家的外键。您商店最简单的设计现在可以分为两个表格。例如：

Cust table
cust_id
name
is_buyer
is_seller

Book table
book_id
description
seller_cust_id
buyer_cust_id

修改：即使单个买家/卖家必须拥有两个帐户，我也不认为此解决方案会发生变化。您只需在应用中添加限制，即客户既不是买方也不是卖方。一个表的好处是你不需要复制安全性/登录/等。逻辑......

编辑2 ：此外，如果买家可以购买多本图书，那么购买购物车的桌子是否会更有意义？

Answer 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课程，我认为他们的好处是自我解释的。但如果您想进一步解释，请随时发表评论，我会回复。到期字段不是必需的，但很可能每个买入和卖出都有时间限制，在这种情况下您将需要它们。

我增加了课程/表格的数量，但我认为你会发现你的系统变得更容易管理和扩展。

Answer 3

如果我理解正确，买家会在卖家做任何事之前提出要约。然后卖家可以接受其中一个待处理的优惠。我会在流程中添加买方ID（事实上，当买家提出要约时会创建流程），以及书籍ID和提供的价格。一旦卖方关闭了交易，该过程就可以通过sID字段链接到卖家。通过这种方式，买家可以在不同的书籍上同时举行多个优惠。

Answer 4

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

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。

Answer 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关系。

Answer 6

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

书店数据库设计

6 个答案: