Дизайн базы данных книжного магазина

Question

Я собираюсь построить книжный магазин, в котором у нас есть 3 объекта (класса): продавец, покупатель, книга. Я разработал базу данных следующим образом:
- Покупатель и продавец могут купить / продать одну или несколько книг соответственно.
- Покупателю нужен аккаунт продавца, если он хочет продать книгу.
- Покупатели предложат свою цену, а продавец хотел бы продать лучшему покупателю, и я должен сохранить всю информацию среди них.

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

<p>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:</p>

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

это будет работать лучше, я думаю, но как начать работать с Ценовые предложения ?
да, я могу добавить предложение в класс process , поэтому я передумал, и эта модель пришла на место: (простите за длинное описание)

Поле * Предложение * будет добавлено в класс * process *: ______ ______ _________ _______ | Продавец | | книга | | процесс | | покупатель | -------- -------- ----------- --------- | СИД * | | ставка * | | PID * | | byID * | | имя | | XXX | -> | СИД | | предложение | | дата & .. | ----------- (*) обозначает первичный ключ

Я совершенно запутался с дизайном БД, потому что это мой первый раз. Будет ли это удовлетворять потребности системы? Если нет, как я могу заставить это работать? Если да, есть ли лучший дизайн?

Любое предложение приветствуется, спасибо заранее :)

обновление - Я действительно не могу выбрать лучший ответ здесь, все помогли. Много, много, большое спасибо, ребята надеюсь, ты лучше ^ o ^

Answer 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 не обязательны, но, скорее всего, каждая заявка и предложение будут иметь ограничение по времени, и в этом случае они вам понадобятся.

Я увеличил количество классов / таблиц, но я думаю, вы обнаружите, что ваша система становится намного проще в управлении и расширении.

Answer 2

Если покупателем может быть продавец (и наоборот), почему бы не иметь единую таблицу клиентов с набором флагов для типа счета?

Если книги уникальны (т. Е. Одна копия Moby Dick рассматривается отдельно от другой копии ... больше похожа на eBay, чем на Amazon), то в вашем книжном столе может быть внешний ключ покупателя и продавца. Самый простой дизайн вашего магазина теперь сводится к двум столам. Например:

Cust table
cust_id
name
is_buyer
is_seller

Book table
book_id
description
seller_cust_id
buyer_cust_id

Редактировать : Я не думаю, что это решение изменится, даже если у одного покупателя / продавца должно быть два аккаунта. Вы бы просто добавили в свое приложение ограничение, согласно которому клиент не может быть ни покупателем, ни продавцом. Хорошая вещь об одной таблице - вам не нужно дублировать безопасность / логин / и т.д. логика ...

Редактировать 2 : Кроме того, если покупатель может купить несколько книг, не имеет ли больше смысла иметь стол с корзиной покупок, в котором хранятся все книги, купленные покупателем?

Answer 3

Это немного сбивает с толку, модель данных, объектная модель, функциональные и нефункциональные спецификации и требования - части каждого обсуждаются. Держите обозначения и элементы дизайна в чистоте, четкости и разделения.

Answer 4

Ну, в соответствии со спецификацией я бы сделал несколько предположений:

• Покупателям и продавцам нужны отдельные учетные записи - поэтому они должны быть атомарными и не должны обмениваться данными, поэтому у нас будет две таблицы.
• Книга - это пример из реальной жизни. Так, если продавец хочет продать 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, пока покупатель не выберет победителя.

Это очень похоже на (только что замеченный) ответ Анкура, только с добавлением отношения winning_bid_id.

Answer 5

Продолжая комментарии LuckyLindy, используйте одну таблицу Customer, создайте таблицу с именем Order (вероятно, похожую на вашу таблицу Process) и таблицу с именем OrderItem. Все ваши Покупатели и Продавцы - это Клиенты ... если ваши Заказы строго между двумя людьми, то ваша таблица заказов может содержать поля покупателя и продавца. Для каждого элемента в Ордере у вас есть кортеж в OrderItem (с идентификатором, возвращающим Order для связывания группы).

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

Это действительно рудиментарный пример, но он складывается из того, что ваши требования могут просто использовать общий дизайн корзины покупок. Существует множество примеров, которые вы можете найти в Google, .

Answer 6

Если я вас правильно понял, покупатели разместят предложения, прежде чем какой-либо продавец сделает что-либо. Тогда продавец может принять одно из ожидающих предложений. Я бы добавил к процессу идентификатор покупателя (фактически, процесс будет создан, когда покупатель размещает предложение), а также идентификатор книги и предлагаемую цену. Как только продавец затем закрывает сделку, процесс может быть связан с продавцом с помощью поля sID. Таким образом, покупатель может держать несколько одновременных предложений по разным книгам.