MySQL Database Layout / Моделирование / Проектный подход / Отношения - PullRequest
Новая
       7

MySQL Database Layout / Моделирование / Проектный подход / Отношения

0 голосов
/ 16 мая 2018

Сценарий: несколько типов для одного типа; один ко многим. Так, например:

родительский множественный тип: таблица учеников, таблица поставщиков, таблица клиентов, таблица отелей

дочерний тип: банковские реквизиты

Таким образом, у студента может быть несколько банковских реквизитов, как у поставщика и т. Д. И т. Д.

Вариант макета 1 таблица учеников (id) + таблица Students_banking_details (student_id) с соответствующим отношением идентификаторов, повторите для каждого типа родителей.

Вариант макета 2 таблица учеников (+ другие) + таблица banking_details. banking_details будет иметь столбец parent_id для ссылки и поле parent_type для определения того, кто является родителем (студент / поставщик / клиенты и т. д.).

Вариант макета 3 таблица учеников (+ другие) + таблица banking_details. Затем я бы создал другую таблицу ассоциации для родительского типа (например: Students_banking_details) для связывания идентификатора student_id и banking_details_id.

Вариант макета 4 таблица учеников (+ другие) + таблица banking_details. banking_details будет иметь столбец для каждого родительского типа, то есть: student_id, supplier_id, Customers_id и т. д.

Другое? Ваш ввод ...

Мои мысли по каждому из них:

  1. Несколько таблиц с одинаковым типом информации кажутся неправильными. Если я хочу изменить то, что хранится в банковских реквизитах, это также несколько таблиц, которые я должен изменить, а не одну.
  2. Похоже, самый жизнеспособный вариант. Очевидно, это не поддерживает «ссылочную целостность». Я не знаю, насколько это важно для меня, если я собираюсь чистить детей программно, когда я удаляю родителей?
  3. То же, что (2), но с дополнительной таблицей для каждого типа, поэтому моя логика подсказывает, что это будет медленнее, чем (2) с большим количеством таблиц и с тем же результатом.
  4. Мне кажется грязным с кучей пустых полей в таблице banking_details.

1 Ответ

0 голосов
/ 17 мая 2018

Прежде чем идти дальше: если вы определитесь с дизайном для хранения банковских реквизитов, в котором отсутствует ссылочная целостность, пожалуйста, скажите мне, кто будет его использовать, чтобы я никогда не мог иметь с ними дело.Это так важно.Ограничения в логике вашего приложения могут соблюдаться ;случаются события, исключения, прерывания, несоответствия, которые впоследствии отражаются в данных, потому что нет значимых гарантий.Ограничения в вашей схеме должны соблюдаться .Гораздо безопаснее, и банковские данные - это то, с чем можно быть максимально безопасным.

Вы правы в определении # 1 как неоптимального;учетная запись - это учетная запись, независимо от того, кому она принадлежит.№ 2 отсутствует, потому что ссылочная целостность не подлежит обсуждению.№ 3, строго говоря, самый жизнеспособный подход, хотя, если вы знаете , вам никогда не придется беспокоиться о расширении числа организаций, которые могут иметь банковские реквизиты, вы можете обойтись без # 4и ограничение CHECK, чтобы каждая строка имела значение только для один из четырех внешних ключей - но вы используете MySQL, который игнорирует ограничения CHECK, поэтому перейдите к # 3.

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

...