шаблон проектирования базы данных: связь между многими таблицами? - PullRequest
Новая
       8

шаблон проектирования базы данных: связь между многими таблицами?

1 голос
/ 15 сентября 2010

У меня есть следующие таблицы:

Раздел и Содержимое

И я хочу связать их.


Мой текущий подход - следующая таблица:

relation table

, в которой я буду хранить

  • Раздел до Раздел
  • Раздел до Содержимое
  • Содержимое до Раздел
  • Содержимое до Содержимое


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

Как обычно, спасибо за ввод!<3 </p>

Ответы [ 2 ]

2 голосов
/ 15 сентября 2010

Вот как я бы это сделал: 

CREATE TABLE Pairables (
  PairableID INT IDENTITY PRIMARY KEY,
  ...other columns common to both Section and Content...
);

CREATE TABLE Sections (
  SectionID INT PRIMARY KEY,
  ...other columns specific to sections...
  FOREIGN KEY (SectionID) REFERENCES Pairables(PairableID)
);

CREATE TABLE Contents (
  ContentID INT PRIMARY KEY,
  ...other columns specific to contents...
  FOREIGN KEY (ContentID) REFERENCES Pairables(PairableID)
);

CREATE TABLE Pairs (
  PairID     INT NOT NULL,
  PairableId INT NOT NULL,
  IsSource   BIT NOT NULL,
  PRIMARY KEY (PairID, PairableID),
  FOREIGN KEY (PairableID) REFERENCES Pairables(PairableID)
);

Вы должны вставить две строки в Pairs для каждой пары.

Теперь можно легко найти любой тип объекта, подлежащего оплате, вы можете искать источник или цель в том же столбце, и вам все еще нужна только одна таблица пересечений "многие ко многим".

1 голос
/ 15 сентября 2010

Да, есть намного более чистый способ сделать это:

  • одна таблица отслеживает отношения между Разделом и Разделом и применяет их как ограничения внешнего ключа
  • одна таблица отслеживает отношения между Разделом и Контентом и применяет их как ограничения внешнего ключа
  • одна таблица отслеживает отношения между содержимым и разделом и применяет их как ограничения внешнего ключа
  • одна таблица отслеживает отношения между контентом и контентом и применяет их как ограничения внешнего ключа

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

Наличие четырех различных взаимосвязей, смоделированных в одной таблице, не придает модели элегантности, а только добавляет запутанность. Реляционная модель не C ++: у нее нет наследования, у нее нет полиморфизма, у нее нет перегрузки. Попытка навязать ОО-подход к моделированию данных привела многих изящных разработчиков к путанице с неуправляемой триггерной сеткой битов, похожих на таблицы, которые смутно напоминают «данные».

...