Проблема с дизайном базы данных - попытка избежать циркулярной ссылки

Question

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

• многие (внешний) Bakers производят много Products
• BakersProducts обновляется каждые две недели на некоторых сотрудников, которые либо называют пекари для их цен на продукцию, или пекари факс через прейскуранте себя, которую после чего обновляется через интерфейсный интерфейс.
• Менеджер должен быть в состоянии произвести заказ, основываясь на тех продуктах, которые она ожидает having.

Таким образом, интерфейс интерфейса должен иметь возможность разрешить руководителю выбирать товары, которые она хотела бы заказать, а затем представить ей список пекарей на выбор для каждого продукта в заказе.

Иными словами, Orders_has_Products также должен содержать ссылку на BakersProducts.bpID. Я уверен, что если я сделаю это, тогда я создам круговую ссылку (сортировку) на Products.

Я уверен, что я пошел об этом неправильном пути, и был бы очень признателен ничьими советы о том, как я могу перестроить свой дизайн acccommodate выбранной Цены продукта - то есть. включить BakersProducts.bpID.

Спасибо!

Answer 1

Я думаю, что путаница происходит из бизнес-процесса точки зрения: вы получаете поборы вперемешку с заказов.

В реквизиции есть список необходимых продуктов, не обязательно указывая поставщика каждого, тогда как заказ направлен на конкретного поставщика, для конкретных кодов цен на цены (что, по-видимому, представляет bpID). Одна реквизиция может порождать несколько заказов, если она разделена между несколькими поставщиками, и даже один продукт может иметь свой порядок, разделенный на нескольких поставщиков, возможно, из-за ограничений объема или локализации поставки.

Возможно, вы захотите предоставить вид заявки, в которой указаны позиции заказа, созданные из каждой позиции заявки, но это относится к интерфейсу пользователя.

Answer 2

Одним из способов решения этой проблемы является просто исключить таблицу Products и переместить productName в таблицу BakersProducts.

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

Если вы ожидаете, что пекари несут один и тот же продукт, вы можете оставить отдельную таблицу продуктов, но вместо того, чтобы иметь Order_has_Products.Products_productID, я бы изменил ее на Order_has_Products.bpID. Если/когда вам нужно получить доступ к имени продукта (или другим метаданным, связанным с другими продуктами, которые могут появиться в этой таблице), вы можете просто присоединиться к BakersProducts и продуктам.

Answer 3

Это не циклическая ссылка, так как

• Order_has_products ссылка Продукты
• Order_has_products ссылка BakersProducts
• BakersProducts ссылка Продукты

циклическая ссылка будет, если, например,

• Order_has_products ссылки Продукты
• Продукты ссылки BakersProducts
• BakersProducts ссылки Order_has_products

Помимо этого, циклические ссылки являются относительно нормально в базе данных (т.е. Таблица сотрудников с полем менеджера, где менеджер сам является сотрудником, является одной таблицей с круговой ссылкой)

Что такое ваш дизайн - это простое резервирование, поскольку один продукт упоминается дважды в таблице Order_has_products - один раз прямо из продуктов таблицу и один раз через соответствующую запись BakersProducts. Существует вероятность выхода из синхронизации, но, поскольку вы заявили, что бизнес-правило заключается в том, что продукт выбран до пекаря, все в порядке.

Я бы включил идентификатор продукта, даже если это было наоборот, потому что небольшая денормализация может пройти долгий путь при ускорении запросов, поскольку в противном случае вам придется сканировать таблицу BakersProducts, даже для простых вопросов, например, «У нас были какие-то рогалики в среду?»