#mysql #database #database-design #relational-database
Вопрос:
Я работаю над дизайном базы данных, где у меня есть таблица с поставщиками, и у каждого поставщика могут быть люди, которые их просматривают.
Вот мои таблицы (я упрощаю их для целей этого вопроса):
таблица поставщиков
vendor_id | vendor_name | vendor_location | vendor_email | vendor_phone
1 | User One | LocationOne | emailOne@test.com | 000000001
2 | User Two | LocationTwo | emailTwo@test.com | 000000002
reviews_table
review_id | customer_name | rating | review_text | vendor_id
1 | Customer One | 5 | mediumtext | 2
2 | Customer Two | 2 | mediumtext | 1
3 | Customer 3 | 5 | mediumtext | 2
4 | Customer 4 | 5 | mediumtext | 2
Мой вопрос: имеет ли это смысл? Было бы лучше создать таблицу ссылок, называемую vendor_reviews review_id внешними ключами и vendor_id в качестве внешних ключей? Если да, то почему он должен быть лучше, чем нынешний дизайн?
Ответ №1:
Да, было бы разумно построить сводную таблицу, чтобы представить отношения n-к-m, чтобы рецензент мог просматривать одного и того же поставщика для каждой продажи. но вам нужно немного перестроить свои таблицы.
Обзорная таблица
review_id | customer_id | rating | review_text | vendor_id
И столик для клиентов
customer_id | customer_name .....
С другой стороны, если у вас нет таблицы клиентов, у вас не может быть связи n:m.
Вместо этого сохраните свой дизайн, поскольку это всего лишь отношения 1 к 1 между поставщиком и проверкой
Комментарии:
1. У меня проблемы с тем, чтобы разобраться в отношениях с н-м. В моей ситуации рецензенты будут похожи на раздел общественного обсуждения в блоге. Таким образом, любой желающий может оставить отзыв. Я думал о том, что каждый рецензент (поскольку у них на самом деле нет учетной записи) просто опубликует отзыв и будет иметь идентификатор поставщика в одной строке. Но я, похоже, не могу понять, как будет иметь смысл использовать bridge-таблицу vendor_reviews (хотя я знаю, что у одного поставщика может быть несколько обзоров). О чем вы думаете?
2. если у вас нет таблицы клиентов, у вас не может быть соотношения n:m между отзывом и поставщиком, потому что у вас есть соотношение 1:1 между отзывом и поставщиком
3. В этом есть прекрасный смысл. Спасибо!
Ответ №2:
Не 1:1-Есть «много» отзывов для каждого поставщика «1». Таким образом, это 2 таблицы, с которых начинался @nTuply.
Если вы не идентифицируете «клиентов», то для них нет необходимости в таблице. То есть любой желающий может написать отзыв, придумать имя и т.д. Это делает его не многим:многим.
Если бы это было 1:1, вы могли бы также объединить таблицы.
1:много (или много:1) — Обратите внимание, что из каждой строки в «многих» ( reviews.vendor_id ) есть ссылка на «1» (таблица vendors ). У вас есть указатель на vendor_id in vendors , а именно на PRIMARY KEY . Вам нужен INDEX reviews вход, если вы хотите перечислить все отзывы для поставщика. A FOREIGN KEY является необязательным.
1:1 будет использовать общий первичный ключ.
Многие:для многих требуется дополнительная таблица, которая обычно состоит не более чем из двух столбцов-идентификаторов, ссылающихся на две таблицы. Два FOREIGN KEYs — это необязательно. Подробнее о многих:многих … http://mysql.rjweb.org/doc.php/index_cookbook_mysql#many_to_many_mapping_table