Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 связь с таблицами связанными многие ко многим  [new]
swaap
Member

Откуда:
Сообщений: 109
Всем привет!

Есть вопрос по проектированию бд. например,
есть две таблицы (Tbl1 и Tbl2) связанные друг с другом многие ко многим через таблицу (Tbl1_Tbl2).
и есть третья таблица (Tbl3) которая должна иметь связь с первыми двумя.

для третьей таблицы правильнее сделать foreigh key на таблицу связи Tbl1_Tbl2 или отдельные foreign key на Tbl1 и Tbl2 ?

я понимаю, что в первом варианте есть поддержка целостности данных, а во втором нет. но все же хотелось бы услышать комментарии.
18 сен 16, 14:20    [19679251]     Ответить | Цитировать Сообщить модератору
 Re: связь с таблицами связанными многие ко многим  [new]
iljy
Member

Откуда:
Сообщений: 8711
swaap,

а че тут комментировать? Есть Т3 привязана к связи Т1_Т2, то первый вариант, если отдельно к Т1 и отдельно к Т2, то второй вариант.
18 сен 16, 16:03    [19679429]     Ответить | Цитировать Сообщить модератору
 Re: связь с таблицами связанными многие ко многим  [new]
job_hunter
Member

Откуда:
Сообщений: 9
iljy,

допустим связи в таблице Tbl1_Tbl2 не постоянные и будут изменяться. соответственно если у нас отдельные ссылки на сами сущности, то все ок, если на таблицу связи, то нам надо как минимум ввести суррогатный ключ в таблице Tbl1_Tbl2 и еще одно поле как признак того что запись удалена/неактивна
18 сен 16, 17:27    [19679651]     Ответить | Цитировать Сообщить модератору
 Re: связь с таблицами связанными многие ко многим  [new]
iljy
Member

Откуда:
Сообщений: 8711
job_hunter
iljy,

допустим связи в таблице Tbl1_Tbl2 не постоянные и будут изменяться. соответственно если у нас отдельные ссылки на сами сущности, то все ок, если на таблицу связи, то нам надо как минимум ввести суррогатный ключ в таблице Tbl1_Tbl2 и еще одно поле как признак того что запись удалена/неактивна


зачем такие извращения? суррогатный ключ не нужен точно (FK может включать несколько полей), а если связи будут меняться, то с привязанными записями тоже надо что-то делать (ровно та же проблема возникает, если могут удаляться объекты в Т1 или Т2).
18 сен 16, 17:40    [19679671]     Ответить | Цитировать Сообщить модератору
 Re: связь с таблицами связанными многие ко многим  [new]
job_hunter
Member

Откуда:
Сообщений: 9
iljy,

суррогатный ключ нужен, т.к. мы уже не можем создать первичный ключ на два поля с foreign key или просто уникальный индекс чтобы не допустить дублирование данных (я про это не говрил, но его не должно быть).

в случае изменения данных с Tbl1_Tbl2 с существующими записями Tbl3 не надо ничего делать. они должны продолжать хранить исторические значения. а вот вновь созданные записи уже должны соответствовать текущей ситуации.
18 сен 16, 17:53    [19679691]     Ответить | Цитировать Сообщить модератору
 Re: связь с таблицами связанными многие ко многим  [new]
iljy
Member

Откуда:
Сообщений: 8711
job_hunter
iljy,

суррогатный ключ нужен, т.к. мы уже не можем создать первичный ключ на два поля с foreign key или просто уникальный индекс чтобы не допустить дублирование данных (я про это не говрил, но его не должно быть).


все мы можем, фигню говорите

+
use tempdb
create table t1 (id1 int primary key, x int)
create table t2 (id2 int primary key, x int)

create table t1_t2 (id1 int foreign key references t1(id1), id2 int foreign key references t2(id2), primary key(id1,id2))

create table t3(id3 int primary key, id1 int, id2 int, foreign key (id1,id2) references t1_t2(id1,id2))

insert t1 values (1, 1),(5,5)
insert t2 values (2, 2),(4,4)
go

insert t1_t2 values (1,2)
go
insert t1_t2 values (2,2) -- нельзя, нет записей в t1
go
insert t3 values(1,1,2)
go
insert t3 values(2,5,4) --нельзя, нет связи, хотя записи есть
go
select * from t1
select * from t2
select * from t1_t2
select * from t3


drop table t3
drop table t1_t2
drop table t1
drop table t2


job_hunter
в случае изменения данных с Tbl1_Tbl2 с существующими записями Tbl3 не надо ничего делать. они должны продолжать хранить исторические значения. а вот вновь созданные записи уже должны соответствовать текущей ситуации.


эээ....че?? какие исторические записи, вы о чем вообще?? FK поддерживает актуальные связи, а ни историю. Ну и у тс ни о какой истории ни словечка.
18 сен 16, 18:10    [19679707]     Ответить | Цитировать Сообщить модератору
 Re: связь с таблицами связанными многие ко многим  [new]
job_hunter
Member

Откуда:
Сообщений: 9
iljy,

если что то тс я. просто другой акк

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

use tempdb
create table t1 (id1 int primary key, x int)
create table t2 (id2 int primary key, x int)

create table t1_t2 (id1 int foreign key references t1(id1), id2 int foreign key references t2(id2), deleted bit default(0), primary key(id1,id2))

create table t3(id3 int primary key, id1 int, id2 int, foreign key (id1,id2) references t1_t2(id1,id2))

insert t1 values (1, 1),(5,5)
insert t2 values (2, 2),(4,4)
go

insert t1_t2 values (1,2)
go
update t1_t2 set deleted = 1 where id1 = 1 and id2 = 2 -- заархивировали типа
go
insert t1_t2 values (1,2) - через какое-то время появилась новая связь (тут будет ошибка)
go


drop table t3
drop table t1_t2
drop table t1
drop table t2


возможно пример немного надуманный но все же.
18 сен 16, 18:21    [19679726]     Ответить | Цитировать Сообщить модератору
 Re: связь с таблицами связанными многие ко многим  [new]
iljy
Member

Откуда:
Сообщений: 8711
job_hunter,

это не я из контекста вырвал, это вы задачу невнятно излагаете. В начальной постановке ни полсловечка про исторические данные не было, а был довольно абстрактный вопрос про "какой FK лучше". А сферические задачи лучше всего реализуются сферическими запросами. Хотите четкого ответа - напишите четко, что у вас с чем связано, какие ограничения целостности, какие действия допустимы, какие- нет и т.д.
18 сен 16, 19:11    [19679834]     Ответить | Цитировать Сообщить модератору
 Re: связь с таблицами связанными многие ко многим  [new]
job_hunter
Member

Откуда:
Сообщений: 9
iljy,

просто задача действительно немного сферическая. мне интересно возможны ли вобще какие-нибудь условия при которых второй вариант из первого сообщения в топике будет предпочтительнее. возможно кто-то сталкивался с такими ситуациями.
18 сен 16, 19:30    [19679865]     Ответить | Цитировать Сообщить модератору
 Re: связь с таблицами связанными многие ко многим  [new]
iljy
Member

Откуда:
Сообщений: 8711
job_hunter,

именно в случае со связью создавать ВК на отдельные объекты? Может быть, если не интересуют никакие другие свойства этой связи (хотя бы когда была создана, когда удалена и т.п.), достаточно только проверки, что в момент создания ссылки она существует. Тогда ее потом можно просто из таблицы связей выкинуть и забыть. Но придумывать такую предметную область лень.
18 сен 16, 20:15    [19680003]     Ответить | Цитировать Сообщить модератору
 Re: связь с таблицами связанными многие ко многим  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31984
swaap
есть две таблицы (Tbl1 и Tbl2) связанные друг с другом многие ко многим через таблицу (Tbl1_Tbl2).
и есть третья таблица (Tbl3) которая должна иметь связь с первыми двумя.

для третьей таблицы правильнее сделать foreigh key на таблицу связи Tbl1_Tbl2 или отдельные foreign key на Tbl1 и Tbl2 ?
...
мне интересно возможны ли вобще какие-нибудь условия при которых второй вариант из первого сообщения в топике будет предпочтительнее. возможно кто-то сталкивался с такими ситуациями.

Эээ, таблица Tbl1_Tbl2 содержит связи Tbl1 и Tbl2
Таблица Tbl3 тоже содержит связи Tbl1 и Tbl2
Это разные связи, и естественно, они должны быть в разных таблицах.

Если Tbl3 содержит не связь Tbl1 и Tbl2, а ссылается на сущность Tbl1_Tbl2 (т.е. на эту связь, как на бизнес-понятие), то естественно должна быть ссылка на Tbl1_Tbl2 (а в Tbl1_Tbl2 соответственно должен быть соотв. суррогатный ключ).
18 сен 16, 23:07    [19680770]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить