В SQL Server мне нужно изменить структуру данных отношений (FK)

Question

Хорошо, я не был полностью уверен, что назвать этот вопрос, так вот ситуация.

Я большой по целостности данных ... Имея в виду столько ограничений и правил, которые я могу использовать, я хочу использовать в SQL Server и не полагаться на приложение.

У меня есть веб-сайт с бизнес-справочником, и эти предприятия могут создать сообщение.

Поэтому у меня есть две таблицы, как это:

tbl_Business (BusinessID, Title, etc.) 
tbl_Business_Post (PostID, BusinessID, PostTitle, etc.) 

Там есть отношения FK для BusinessID столбцов между двумя таблицами. Сообщение не может существовать в таблице tbl_Business_Post без идентификатора BusinessID, существующего в таблице tbl_Business.

Так довольно стандартно ...

Я недавно добавил объявления на сайте. Так что теперь у меня есть еще две таблицы:

tbl_Classified (ClassifiedID, SellerID, ClassifiedTitle, etc.) 
tbl_Classified_Seller (SellerID, SellerName, etc.) 

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

Здесь я должен руководствоваться.

У меня возникло соблазн удалить отношения FK на tbl_Business_Posts ... Я думал о создании другой отдельной таблицы сообщений, в которой хранятся объявления.

Есть ли способ сделать условные отношения FK на основе столбца? Например, если это бизнес-сообщение BusinessID должно существовать в таблице Business или, если оно должно быть опубликовано, идентификатор продавца должен существовать в таблице продавца?

Или мне нужно создать отдельную таблицу для размещения объявлений и UNION обеих таблиц в запросе?

Вы можете задать вопрос, почему у меня есть стол «Сообщений», и это трудно объяснить ... но мне это нужно для того, как организован сайт и как работает фид.

Это просто, что стол сообщений идеально подходит, и я хотел объединить все сообщения и упорядочить их по типу (Ie: «business», «классифицирован» и т. Д.), Поскольку может быть и более позднее.

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

Благодарим за руководство.

======== EDIT =========

Полное объяснение tbl_Business_Post

PostID PK 
Post_Type int <-- 1-21 is business types, 22 for classified type 
BusinessID INT <-- This is the FK currently for the tbl_Business 
SiblingID INT <-- This is the ID of the related item they're posting on. So for example, if they post a story about one of their products, this is the ProductID, if it's a service, this is the ServiceID. 
Post_Title <-- Depending on the post, this could be a Product title, a service title, etc. 

Так что, если я изменил структуру, так это выглядит следующим образом:

PostID PK 
Post_Type int 
BusinessID INT <-- this is populated on insert if it's a business. 
SellerID INT <-- This is populated on insert if it's a classified seller 
SiblingID INT <-- This is either the classifiedID or ProductID, SeviceID, etc. Depending on post type. 

Таким образом, опираясь на первое решение Питера/пример ...заинтересованы в надлежащем способе создания контрольных ограничений или триггеров на этом, так что если тип 1-21, он удостоверяет, что BusinessID существует в таблице Business или если это тип 22, убедитесь, что идентификатор продавца существует в таблице продавца.

Даже идя дальше с этим:

Если Post_Type = 22, я должен убедиться, что не только продавец в продавца таблице, но SiblingID также ClassifiedID в засекреченной таблице.

Answer 1

1) Невозможно сделать такой условный FK, о котором вы думаете. Что вам нужно здесь, это в основном FK из tbl_Business_Post, который логически указывает на одну из двух таблиц, в зависимости от значения в другом столбце tbl_Business_Post. Эта ситуация часто встречается людьми. Но в реляционной БД это не очень оригинальная идея. Итак, это не может быть выполнено с помощью FK. Вместо этого вы, вероятно, можете применить это с помощью триггера или контрольного ограничения на tbl_Business_Post.

2) В качестве альтернативы вы можете сделать следующее.

Создайте таблицу tbl_Basic_Post, поместите туда все столбцы, которые относятся к самому сообщению (например, PostTitle), а не к родительскому объекту, к которому принадлежит эта запись или указывает (Бизнес или Классификация). Затем создайте две другие таблицы, которые указывают через FK в таблицу tbl_Basic_Post, например, например.

tbl_Business_Post.Basic_Post_ID (FK)
tbl_Classified_Post.Basic_Post_ID (FK)

Put в этих двух таблицах столбцы, которые являются Business_Post/Classified_Post конкретных
(вы видите, это в основном наследуемыми в реляционных БД терминов).

Кроме того, чтобы каждая из этих двух таблиц имела FKs к их соответствующим родительским таблицам
tbl_Business и tbl_Classified тоже. Теперь эти FK становятся безусловными (в вашем смысле).

Для получения деловых постов вы присоединяетесь к tbl_Basic_Post и tbl_Business_Post.
Чтобы получить секретные сообщения, вы присоединяетесь к tbl_Basic_Post и tbl_Classified_Post.

Оба подхода имеют свои плюсы и минусы. Подход 1) прост, не приводит к созданию слишком большого количества таблиц; но это не тривиально, чтобы обеспечить целостность данных. Подход 2) не требует ничего специального для обеспечения целостности данных, но приводит к созданию большего количества таблиц.