Как лучше всего определить, подходит ли таблица полиморфного соединения? - PullRequest
3 голосов
/ 25 февраля 2012

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

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

Есть ли хорошие правила для принятия решения?

1 Ответ

3 голосов
/ 28 февраля 2012

Традиционный дизайн базы данных учит, что отношения Много: Многие должны быть переданы двум 1: Многие отношения с промежуточной таблицей.

М: М = 1: М, М: 1

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

Тем не менее, метод проектирования хранилища данных Kimball иногда применяет схему типа «звезда» или «снежинка», где данные «отбрасываются» в тип мини-базы данных. Это тот тип вещей, который архитектор баз данных разработал бы для системы OLAP (бизнес-аналитика). Я знаю, что почти каждая крупномасштабная бизнес-система, с которой я работал, работает по схеме «снежинка» или «звезда». Что касается масштаба, мы говорим о 1 ГБ плюс - поэтому он не должен быть огромным, но за пределами размера Microsoft Access.

Быстрые ссылки: Нормализация базы данных: http://en.wikipedia.org/wiki/Database_normalization

Нормализация базы данных (About.com): http://databases.about.com/od/specificproducts/a/normalization.htm

Архив хранилища данных Kimball Group: http://www.kimballgroup.com/html/articles.html

В архиве Kimball есть несколько полезных руководств о том, как и когда создавать склад.

Редактировать: чтобы определить, когда вам нужно использовать таблицу для объединения двух таблиц в базе данных, вы можете разработать схему базы данных. Это типичный способ выложить дизайн перед началом кодирования. Разработка схемы базы данных может быть большой работой - в моей программе она преподавалась как часть курсовой работы по разработке базы данных. Я добавил несколько ссылок для вас, и вы можете посмотреть на дизайн базы данных здесь, в Stack Overflow, чтобы получить лучшее представление. Особого внимания заслуживает руководство Microsoft, которое довольно приятно. Даже если вы не используете Microsoft SQL Server, руководство может быть полезным.

Схема базы данных: http://en.wikipedia.org/wiki/Database_schema

Руководство по схеме базы данных Microsoft: http://msdn.microsoft.com/en-gb/express/bb403186.aspx

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...