Объединение всех отношений в одну таблицу SQL Server - PullRequest
Новая
       16

Объединение всех отношений в одну таблицу SQL Server

0 голосов
/ 06 января 2019

Я пытаюсь спроектировать архитектуру базы данных уровня предприятия. На уровне ERD у меня есть проблема.

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

В последние дни я создал родительскую таблицу с именем Node , и все мои функциональные таблицы имеют отношение один к одному с этой таблицей. (Функциональные таблицы - это те, кто хранит данные реальной жизни, такие как контент, пользователь, папка, роль и т. Д., А не те, кто связан с жизненным циклом приложений) Таким образом, перед добавлением записи в каждую таблицу, мы должны добавить узел в таблицу узел и взять новый идентификатор узла для добавления во вторичную таблицу.

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

enter image description here

Все остальные объекты похожи на Пользователь и связаны с таблицей узлов, как показано выше.

Проблема в том, ускоряет ли этот дизайн мои реляционные запросы на NodeAssoc таблице или лучше хранить отношения отдельно?

1 Ответ

0 голосов
/ 07 января 2019

Вы говорите:

В будущем возможны некоторые изменения, и мой дизайн должен быть гибким и быстро собирать результаты.

Гибкость и производительность - это две разные вещи. У которых есть разные способы приблизиться к ним или решить их. Когда вы разрабатываете базу данных, вы должны учитывать принципы базы данных. Нормализация очень важно иметь в виду. Отношения один-к-одному и многие-ко-многим по своему замыслу не являются общими. В вашем случае вы упоминаете отношения один-к-одному и многие-ко-многим, о которых я беспокоюсь.

  • Совет один -> Денормализовать (объединить) однозначные таблицы в одну таблицу. Это уменьшает количество соединений.
  • Совет два -> Ввести таблицу мостов в таблицу «многие ко многим», потому что может быть несколько совпадений. Исправление нескольких совпадений означает сложные запросы, что приводит к снижению производительности.
  • Совет три -> Используйте правильные индексы для повышения производительности

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

...