MySQL дизайн базы данных

Question

У меня есть грубый дизайн базы данных MySQL, который я скоро внедрю, но я не уверен, технически ли это правильно. Я никогда не занимался формальным образованием в области проектирования баз данных, поэтому у меня возникают сомнения:

Entities / Таблицы

1. Товар (P_ID, Имя)
2. Идентификатор пакета (P), Имя)
3. Default_Package (* Commodity_ID, * Package_ID, P_ID)
4. Custom_Package (* Commodity_ID, * Package_ID, Order_ID, P_ID)
5. Заказ (P_ID, Package_ID, Custom_Package = 0)

По сути, так работает система:

1. Администраторы создают набор пакетов по умолчанию, хранящихся в таблице default_package
2. Пользователи должны купить Пакет по умолчанию, на который есть ссылка в поле Package_ID таблицы Order_ID

3. Пользователи могут настроить свой пакет по умолчанию. Если они решат сделать это, поле Custom_Package будет переключено на 1, и информация о пользовательском пакете будет сохранена в таблице Custom_Package.

4. При выполнении поиска проверяется поле custom_package таблицы заказов. Если 0, пакет извлекается из списка default_package, иначе он извлекается из списка Custom_Package путем извлечения всех записей, которые ссылаются на заказ.

Исходя из моего опыта проектирования и реализации баз данных, это должно работать. Однако я не уверен, что это лучший путь.

Я был бы очень признателен, если бы кто-то мог поделиться своим мнением.

:)

Answer 1

Мои мысли, основанные на вашем примере и комментариях:

Похоже, ваши "пакеты" являются комбинациями названия пакета и названия товара?

1. Товар (P_ID, Имя)
2. Идентификатор пакета (P), Имя)

Я бы объединил две таблицы ниже:

 3. Default_Package (* Commodity_ID, * Package_ID, P_ID)
 4. Custom_Package  (* Commodity_ID, * Package_ID, Order_ID, P_ID)

в

 3.  Packages ( P_ID, * Commodity_ID, * Package_ID, P_type=0/1 )

, а затем размещать заказы в

 4. Order  (P_ID, Package_ID)

Я бы не рекомендовал позволять флажку в таблице Order определять, какую таблицу "package" ему нужно получить, потому что ваше предложение JOIN станет излишне сложным, когда вы попытаетесь получить сведения о пакете для всех заказов.

Если вы хотите быть строгими в отношении нормализации , вы также можете разбить p_type в пакетах на отдельную таблицу, хотя я бы принял немного денормализации для одного бита (личное предпочтение). Однако, если есть другие поля, уникальные для пакета, создайте таблицу пакетов с идентификатором и другими полями, а также таблицу packages_details со списком идентификаторов товаров и идентификаторов пакетов. Я бы также не стал использовать какую-либо числовую схему для пользовательских пакетов по сравнению с пакетами по умолчанию (т. Е. Пакеты по умолчанию - 1-100 и после этого начинаются пользовательские), потому что любая подобная схема с большой вероятностью сломается в будущем (компания растет и имеет более 100 пакетов по умолчанию, например)

То, что я хотел бы предложить, - это собрать запрос, чтобы получить все детали пакета для всех заказов, что, вероятно, представляет «самую подробную информацию», которая вам понадобится. Попробуйте написать запрос, используя оба варианта, и посмотрите, какой из них проще ...