Я экспериментировал с DB Design в моем тестовом проекте, и теперь я собираюсь реорганизовать мою DB с новыми знаниями, которые я получил до сих пор о нормализации и ERM и его зависимостях в целом.Для моего маленького тестового проекта дизайн, который я придумал, мне подходит.Это включает в себя такие аспекты, как гибкость для дополнений или изменений в БД в будущем, по крайней мере, в объеме, который я установил для проекта.Однако, поскольку я все еще довольно новичок во всем этом, мне не хватает опыта, который позволил бы мне принять во внимание возможные будущие подводные камни или желательный дизайн.
Итак, во-первых, позвольте мне изложить свои сущности и отношениядля вас:
Моя БД до сих пор вращается вокруг 2 сущностей: пользователей и продуктов.
Пользователи представлены в одном отношении:
users_tbl:
user_id(Primary Key), user_forename, user_surname, user_mail(Unique), user_password
Продукты также представлены в одном отношении:
products_tbl:
product_name(Primary Key), product_manufacturer, product_category
И здесь у меня уже есть первая неопределенность: выбрал быНазвание продукта как (естественный) первичный ключ будет считаться хорошей / лучшей практикой в продуктивной коммерческой среде?Мне кажется, это хорошая идея, потому что не имеет смысла иметь в магазине разные продукты с одинаковым названием.Так что, по крайней мере, с точки зрения пользователей, неясности не возможны / разумны.Но, возможно, техническое решение отличается от того, что мы видим.Здесь я всегда пытаюсь думать о том, как огромный интернет-магазин, такой как amazon, мог бы справиться с этим.Может быть, в таких масштабах, особенно с таким большим количеством продуктов, которые меняются или входят в каталоги и выходят из него, вероятно, ежедневно, может быть, там более разумно просто добавлять новые данные вместо обновления старых, а затем, возможно, еженедельно ».сборщик мусора "устаревшие данные?В таком случае наличие имени в качестве первичного ключа, вероятно, не сработает, и вместо этого потребуется искусственный ключ (id).
Следующая неопределенность связана с необходимостью поддержания целостности в БД.в products_tbl атрибуты product_manufacturer и product_category полностью зависят от PK, product_name.С чисто логической точки зрения это кажется почти тривиальным, и поэтому не должно быть проблем, если, скажем, производитель Siemens полностью исчезнет из моей БД, потому что у нас просто не осталось продуктов из них в нашем магазине.Но может быть несколько причин, почему я не хотел бы, чтобы этот производитель полностью исчез из моей БД, верно?Например, отсутствие продуктов просто связано с временным отключением, возможно, потому что продукты, которые мы обычно предлагаем, не доступны в течение следующего года, пока их следующее поколение не появится в следующем году.Поэтому мы все еще хотим оставить этого производителя в нашей базе данных, поскольку это также напоминает нам о том, что Siemens является официальным партнером, у которого мы получаем нашу продукцию.
Когда вы смотрите на product_category, это становится еще более очевидным, потому что может случиться так, что, например, вся зимняя одежда исчезнет, потому что сезон для ее продажи закончился.Мы все еще хотим сохранить эту категорию, потому что соответствующие продукты обязательно вернутся в следующем сезоне.
Чтобы достичь этого, я подумал о добавлении избыточности.Поэтому я создаю
manufacturers_tbl:
manufacturer_name(Primary Key)
categories_tbl:
category_name(Primary Key)
и затем ссылаюсь на них с помощью ограничений FK от product_manufacturer и product_category.Однако, как и раньше, я не уверен, что такая стратегия будет сочтена полезной в продуктивной среде, особенно в тех, которые несут огромную нагрузку, как в случае с Amazon.Каково ваше предположение на этот счет?
Чтобы оценить, оправдывает ли ценность этой избыточности стоимость, особенно важно добавить дополнительные отношения в будущем.Например, моя БД уже состоит из еще двух таблиц, одна из которых уже содержит эту информацию:
product_attributes_tbl:
product_attribute(Primary Key)
recommendations_tbl:
recommendation_id(Primary Key), user_id(FK to users_tbl: user_id), user_recommendation(FK to product_attributes_tbl: product_attribute)
user_recommendation содержит информацию о категориях продуктов в более широком смысле, то есть она может содержать информацию о производителе, категории (например, спорт, книги, компьютер), целевой группе (бизнес, частный сектор) и т. Д.
product_attributes_tbl - это надстройка, помогающая мне понять полиморфную связь между атрибутом user_recommendation и любым количеством атрибутов продукта (см. здесь: MySQL - Условные ограничения внешнего ключа ).
Теперь я, конечно, могупросто положитесь на этот supertable, чтобы хранить всю информацию об атрибутах продукта.Единственным недостатком этого является то, что информация не может быть указана дальше.Разделение его на отдельные столбцы, определяющие информацию как производителя, категории и т. Д., Подорвало бы его назначение в качестве супертаблицы.Поэтому, хотя это определенно сохранит данные живыми, данные потеряют точность / разрешение.
Кроме того, на случай, если я останусь с решением предоставить атрибутам продукта дополнительные, отдельные таблицы (Manufacture_tbl и т. Д.):С точки зрения правил разработки БД (насколько они существуют), было бы более разумным позволить атрибутам в products_tbl ссылаться на отдельные таблицы (Manufactureuers_tbl и т. Д.) Или на супертаблицу (product_attributes_tbl)?Поскольку отдельные таблицы являются более точными, было бы более разумно ссылаться на них.Тем не менее, ссылка на supertable сделает вещи более централизованными со структурной точки зрения, что, я думаю, имеет свои плюсы в отношении удобства обслуживания.