Дизайн базы данных: упрощение для многих

Question

Скажите, у меня есть следующие таблицы:

• персона (person_id, имя)
• Этническая принадлежность
• person_ethnicity (person_id, ethity_id)

Это позволило бы мне определить person для 0 или более ethnicity И ethnicity для 0 или более person в таблице person_ethnicity.

Теперь, допустим, у меня есть МНОЖЕСТВО этих таблиц типа "этническая принадлежность", где я должен установить такое же соотношение "многие ко многим" с таблицей person. Число моих столов будет расти довольно быстро.

Будет ли хорошей идеей иметь такую ​​таблицу вместо этого:

• foo (person_id, other_table_name, other_table_pk)

Пример:

=================================================
| person_id | other_table_name | other_table_pk |
=================================================
| 1         | ethnicity        | 1              |
-------------------------------------------------

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

(Кроме того, есть ли подходящее название для подхода, который я описал выше?)

Answer 1

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

Ваша ситуация очень похожа на систему тегов.И, к счастью для вас, MySQL Community предлагает отличную вики-статью о TagSchema через Forge .

Также вы должны рассмотреть вопрос о поиске подобных вопросов, так как он был задан и спросил и спросил .Некоторые из них на самом деле обеспечивают интересное понимание этого вопроса.Особенно Какие схемы тегов являются наиболее эффективными / эффективными? и ответ на Collection Tags, который содержит Tag Sets.

Answer 2

не вижу необходимости.Много таблиц - не проблема, и вы нарушаете множество «правил», делая это так.Просто используйте многие ко многим, если они вам нужны.

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

Только не мой совет: D

Answer 3

Ваше решение довольно быстро взорвет ваш стол "foo".

представьте, что у вас 1000 человек. тогда каждый человек имеет минимум 2 национальности.

тогда у вас есть таблица национальности, и у каждого человека есть по крайней мере 1,5 национальности.

затем пол, где каждый человек имеет минимум 1 пол, что уже составляет до 4500 записей.

Теперь предположим, что ваш личный стол увеличивается до 50000 человек.

это сделает уже 225000 записей в вашей таблице "foo".

теперь, когда у вас есть заполненные таблицы, вы делаете запрос, объединяющий людей с foo и только этнической принадлежностью, чтобы получить этнические группы всех людей, и ваш сервер будет работать очень долго, потому что вы присоединяетесь к таблице 50000 с таблицей 225000 и конец присоединиться к маленькому столу.

так что я надеюсь, я ясно дал понять, почему не стоит создавать такой макет

Answer 4

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

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

получить лопату; принимайтесь за работу. Смоделируйте вашу проблему так, как она существует, используя реляционную идиому или найдите что-то еще. Возможно, решение NoSQL, такое как база данных объектов или графов, в вашем случае является лучшей идеей.