Дополнительные таблицы или неспецифические внешние ключи?

Question

В системе существует несколько типов объектов, каждая из которых имеет собственную таблицу в базе данных. Пользователь должен иметь возможность комментировать любой из них. Как бы вы создавали таблицы комментариев? Я могу думать о нескольких вариантах:

1. Один примечания к таблице, с колонкой FK для каждого типа объекта (ObjectAID, ObjectBID и т.д.)
2. Несколько комментариев таблицы, по одному для каждого типа объекта (ObjectAComments, ObjectBComments, и т.д.)
3. Один общий FK (ParentObjectID) с другой столбец, чтобы указать тип ("Objecta")

Какой бы вы выбрали? Есть ли лучший способ, о котором я не думаю?

Answer 1

@palmsey

Довольно много, но вариация этой модели, которые я видел чаще всего избавляется от ObjectAID и др. ParentID становится как ПК, так и FK до Parents.Это заставляет вас что-то вроде:

• Parents

  • ParentID

• ObjectA

  • ParentID (FK и PK)
  • ColumnFromA NOT NULL

• ObjectB

  • ParentID (ФК и ПК)
  • ColumnFromB NOT NULL

Comments останется тем же. Тогда вам просто нужно ограничить создание идентификационных данных, чтобы вы случайно не закончили строку ObjectA и строку ObjectB, которые указывают на одну и ту же строку Parents; самый простой способ сделать это - использовать ту же последовательность (или что-то другое), которую вы используете для Parents, для ObjectA и ObjectB.

Вы также увидите много схем с чем-то вроде:

• Parents
  • ID
  • SubclassDiscriminator
  • ColumnFromA (nullable)
  • ColumnFromB (nullable)

и Comments останутся без изменений. Но теперь вы не можете принудительно применять все свои бизнес-ограничения (свойства подклассов - все значения NULL) без написания триггеров или выполнения этого на другом уровне.

Answer 2

Возможно ли разработать схему, чтобы таблицы комментариев (из-за отсутствия лучшего слова) соответствовали одному из стандартных шаблонов моделирования наследования? Если это так, вы можете указать FK таблицы комментариев в общую родительскую таблицу.

Answer 3

@Hank Гей

Так что-то вроде:

1. Objecta
   • ObjectAID
   • ParentID
2. ObjectB
   • ObjectBID
   • ParentID
3. Комментарии
   • CommentID
   • ParentID
4. Родители
   • ParentID

Answer 4

Будьте осторожны с общими внешними ключами, которые не указывают ровно на одну таблицу. Производительность запроса сильно страдает, если вам нужно разделить условие where на тип и указать несколько разных таблиц. Если у вас есть только несколько типов, и количество типов не будет расти, нормально иметь отдельные переменные с нулевым внешним ключом для разных таблиц, но если у вас будет больше типов, лучше придумать другую модель данных (например, @ предложение palmsey).

Answer 5

Одна из вещей, которые мне нравятся, - это иметь отдельные таблицы, которые связывают общую/общую таблицу со всеми отдельными таблицами.

Так, для объектов Foo и Bar, а затем комментарии на Foo & Bar, вы бы что-то вроде этого:

• Foo
  • Foo ID (PK)
• Бар
  • Bar ID (PK)
• Комментарий
  • Комментарий ID (ПК)
  • Комментировать Текст
• FooComment
  • Foo ID (ПК ФК)
  • Комментарий ID (ПК ФК)
• BarComment
  • Bar ID (PK FK)
  • Комментарий ID (PK FK)

Эта структура:

1. Позволяет иметь общую Комментарии таблицу
2. Не требует БД с наследованием таблицы
3. D oesn't загрязняют таблицы Foo и Bar с информацией Комментария связанных
4. Позволяет прикрепить комментарий к множественным объектам (которые могут быть желательны)
5. Позволяют прикрепить другие свойства к соединению Foo/бар и комментарий если это необходимо.
6. Сохраняет связи со стандартными (то есть: быстрыми, простыми, надежными) внешними ключами