Foreign KEY

Здравствуйте форумчане. Помогите с проблемой. Впервые настраиваю связи в БД. Ситуация: есть 4 справочника (приведу сокращенные названия)
1. Company - организация. В нем ID_Company первичный ключ.
2. Filial - филиалы организации. Поле ID_Fil - первичный ключ.
3. Rank - категория сотрудников филиала Поле ID_Rank первичный ключ
4. Prof - список профессий. ID_Prof первичный ключ.
Так вот в Prof мне надо ссылаться на ключи первых 3х таблиц с каскадным Update. Строю так Prof.ID_FIL зависит от Filial.id_fil, Prof.id_rank зависит от Rank.ID_rank и prof.id_company зависит от company.id_company. Т.е если меняется ID в головных таблицах, то и в таблице Prof эти айдишники меняются. Так вот 2 связи MS SQL 2008 r2 дает построить, а третье поле выдает ошибку:
Не удалось создать связь "FK_Professions_Spr_Fil".Введение ограничения внешнего ключа (FOREIGN KEY) "FK_Professions_Spr_Fil" для таблицы "Professions" может привести к появлению циклов или множественных каскадных путей. И т.д.
Удаляю одну любую из связей и все ок. Третью не дает поставить... Что делать?

0

Начнём с того, зачем нужен каскадный update id-ов. Вам так важно какой id у профессии в списке профессий? Кто-то потребует изменить id директора, потому что там число 13 просматривается?

0

Конечно важно, какой Id у профессии. В данный момент 10 филиалов у каждого свои профы. База и справочник профессий соответственно один. ID_Prof в данном случае это код профессии и у каждого филиала он будет свой, и уникальный. Зачем, допустим в справочнике сотрудников писать профу, принадлежность к филиалу и категорию сотрудника, если можно указать все это кодами? В справочниках поменял код и связанные поля в других таблицах автоматом изменяют этот код. Или изменился код филиала в справочнике филиалов, тогда и во всех таблицах связанных по коду филиала этот код должен меняться. Зачем мне программно за этим следить и городить кучу строк кода запросов, если этот функционал можно возложить на СУБД? Тут пока ситуация получается, что в таблице не может быть более
двух связей?

0

Сообщение от drvolodko Или изменился код филиала в справочнике филиалов

почему он должен меняться? Тем более, это не Код, а Id?

Добавлено через 6 минут

Сообщение от drvolodko ID_Prof в данном случае это код профессии и у каждого филиала он будет свой, и уникальный

это никто не оспаривает.

Но зачем в таблице Company
Id Name
1 Рога
2 Копыта

делать

2 Копыта
3 Рога

???

0

блооооо.... Я так назвал поле ID_Prof - идентификационный код профессии. Меняться он не просто может,а ДОЛЖЕН. Изменилась политика предприятия, штатное расписание, реструктуризация организации и т.д. Поэтому необходимо предусмотреть не только смену наименования профессии (был аккумуляторщик код профессии 11, а стал мегааккумуляторщик с кодом профы 11), но и кода самой профессии при необходимости. Наменование содержится в 1 справочнике и с его изменением проблем нет, а вот к коду профы может быть привязано много таблиц. Поэтому и необходим автоматический Update всех таблиц, привязанных и содержащих этот код. Эта таблица у меня по разным кодам привязана к 3 головным таблицам. Любые 2 связи работают, но стоит добавить третью летит ошибка. Причем не важно с какой таблицей я строю связь в конце. будет 3 company на нее заорет, будет spr_fil то на нее, а будет rank то значит ее в топку, а другие проглотит.
Рога 1 контрагент
Я тоже Рога - говорит другой контрагент.
Как их различить если не по коду?

Добавлено через 29 минут
Блин... Создаю таблицу сотрудников организации. Там вообще в основном вся инфа связана со справочниками и такая же фигня... Третью связь построить не дает. А если поставить на Update NO ACTION, то я так понимаю смысла от связи не будет и обновляться таблица в зависимости от справочников тоже не будет?

0

Сообщение от drvolodko Создаю таблицу сотрудников организации. Там вообще в основном вся инфа связана со справочниками и такая же фигня.

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

0

Сообщение от YuryK заведи суррогатные ключи у справочников вместо естественных, если их приходится править, и забудь вообще про необходимость править Id-ы, они ничего не должны значить, а только обеспечивать связь между таблицами.

да тут дело не в id, а в данных... Поля можно как угодно назвать. Есть справочники и другие таблицы, которые на данные в этих справочниках ссылаются. Поменялись данные в справочнике - сработал update на все связанные таблицы. У меня вот будет много рабочих таблиц ссылающихся на более чем три справочника, а тут больше 2х ссылок не дает ска... NO ACTION ставишь - глотает но пишешь update table set bla-bla-bla... where bla-bla-bla и ппц... ошибки связей.

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

Юрик, что за суррогатные ключи? И как их строить? О суррогатных матерях слышал, а вот о ключах таких в БД не слыхивал.

0

Сообщение от drvolodko да тут дело не в id, а в данных... Поля можно как угодно назвать. Есть справочники и другие таблицы, которые на данные в этих справочниках ссылаются. Поменялись данные в справочнике - сработал update на все связанные таблицы

в справочниках и меняют все кроме Id-а, т.к. не данные это, это значение присвоилось автоматически при добавлении записи в таблицу и всем абсолютно начхать, какое именно.

вот, например, Company. Пусть это будут российские компании. У всех у них есть ИНН, который можно было бы использовать в качестве естественного ключа. И тогда при смене ИНН (или просто корректировке ошибочно введенного) пришлось бы и впрямь исправлять и Filial.Company (который в этом случае был бы равен ИНН).

Но мы ИНН делаем просто атрибутом, а для ключа используем автоинкрементное поле Id. Это и есть суррогатный ключ. И теперь при смене ИНН изменится только атрибут Company,.INN, но нам ничего НЕ НАДО ДЕЛАТЬ с подчиненными таблицами, т.к. связь по Filial.Company-Company.ID как была, так и осталась.

Только ID-ы корректировать не надо (при автоинкременте это и непросто сделать).

Ну а в простых справочниках типа (Id, NAME) не надо и бездумно править Name, а то все аккумуляторщики враз станут директорами филиалов

0

Да чё ты доеб...ся до этих id-шников?? Я те еще раз говорю что это НЕ ИДЕНТИФИКАТОР. Поле-идентификатор автоинкрементное у меня совершенно другое. А другие поля с ДАННЫМИ (ну типа ИНН как в твоем примере) я как хочу так и называю. Назвал ID_FIL - это значит идентификационный номер филиала организации. Типа ОГРН. Почитай внимательно предыдущий текст. И при чем тут

Ну а в простых справочниках типа (Id, NAME) не надо и бездумно править Name, а то все аккумуляторщики враз станут директорами филиалов

? Изменилась штатка. Профы тому же ООТиЗу править надо? Надо. А если еще и код профы меняется, то и его. Наименование в 1 таблице (в справочнике) а вот код профы в 10-20 таблицах с данными, с которыми работают юзеры. И мне что всю это пое..нь в виде 20 таблиц отслеживать? Поэтому и необходимо каскадное обновление. Поменял в справочнике и вуаля - поменялось везде. У меня не строится связь таблицы с тремя справочниками. С двумя все норм. Все обновляется каскадом. Но добавить третий не получается. Я тебе это и пытаюсь объяснить. А ты мне про автоинкремент все время.....

Добавлено через 5 минут
id - автоинкремент id_prof - идентификатор провессии Name_Prof - наименование профы.
1 152 аккумуляторщик
2 155 мазахист
3 200 биг босс

поменялась штатка

1 10 аккумуляторщик
2 20 мазахист-аккумуляторщик
3 30 Биг босс мазахиста-аккумуляторщика

Так понятней?

0

Сообщение от drvolodko Изменилась штатка. Профы тому же ООТиЗу править надо?

вот ты упертый. Если Prof - список профессий, при изменении штатного исправлять надо не здесь, а в таблице ШтатноеРасписание и там сменить ID_Prof на новый, соответствующий другой профессии.

Если у тебя существует prof.id_company - то это никакой не справочник профессий. Что это за профессии, называющиеся одинаковые, но имеющие разные записи для разных компаний? Значит это штатное, но тогда название должности/профессии должно храниться в другой таблице.

Добавлено через 32 минуты

Сообщение от drvolodko поменялась штатка 1 10 аккумуляторщик 2 20 мазахист-аккумуляторщик 3 30 Биг босс мазахиста-аккумуляторщика Так понятней?

нет.
если поменялась, то надо до и после
в штатке не должно быть никаких 'аккумуляторщик' там должен быть id из таблицы prof. Именно Id, а не id_prof и не Name_Prof. Все это должно оставаться (и меняться при острой необходимости) в таблице prof


там должно быть
до
в компании 1 было 10 ставок аккумуляторщика с окладом 30 тыс.рублей
в компании 2 было 20 ставок таких же аккумуляторщиков

id Company prof_id Count Wage ...
1 1 1 10.0 30.000 ...
1 2 1 20.0 30.000 ...

после
в компании 2 решили вместо 20 ставок аккумуляторщика ввести 10 ставок мазахист-ов с окладом 60.000
1 2 2 10.0 60.000 ...
т.е. мы просто выбираем другую запись из справочника, зачем справочник менять?

0

Да. Упертый. Потому что это лишь пример. Смотри. Rank – категория профессий.
Поле Тип данных Описание Уникальный ключ Зависимость (таблица.поле)
ID int Идентификатор записи (счетчик)
ID_Rank Int Идентификатор профессии Да
Rank_Name Nvarchar 255 Наименование профессии
Далее
Company – наименование организации.
Поле Тип данных Описание Уникальный ключ Зависимость(таблица.поле)
ID int Идентификатор записи (счетчик)
ID_Company Int Идентификатор организации Да
Company Nvarchar 255 Наименование организации
Далее
Spr_Fil – справочник филиалов.
Поле Тип данных Описание Уникальный ключ Зависимость(таблица.поле)
ID int Идентификатор записи (счетчик)
ID_FIL Int Идентификационный номер филиала Да
FIL Nvarchar 255 Наименование филиала
ID_Company Int Идентификатор организации Company.ID_Company
И вот хотя бы
Professions – справочник профессий.
Поле Тип данных Описание Уникальный ключ Зависимость
(таблица.поле)
ID int Идентификатор записи (счетчик)
ID_Prof Int Идентификатор профессии Да
Profession Nvarchar 255 Наименование профессии
Category Int Категория/разряд профессии
Category_Name Nvarchar 50 Наименование категории/разряда
Unheality int Вредность (логическое) 0 – нет, 1 – да.
ID_Rank Int Вид профессии (специалист/рабочий/руководитель) Rank.ID_Rank
ID_Company Int Идентификатор организации Company.ID_Company
ID_FIL Int Идентификатор филиала SPR_FIL.ID_FIL
Overtime Int Ненормированный рабочий день (логическое) 0 – нет, 1 – да.
А теперь еще раз во что я уперся. Ставлю зависимости SPR_FIL.ID_FIL и Rank.ID_Rank все норм с каскадным обновлением. Добавляю зависимость Company.ID_Company и северный пушной зверек получается в виде ошибки FOREIGN KEY. Будет еще таблица сотрудников. Там еще больше связей со справочниками, а больше двух справочников связать не дает. Пздц. Представь себе 5000 сотрудников, которые при изменении кода филиала перестанут существовать образно говоря Или код профессии поменялся. Да вообще любое изменение справочника без каскадного изменения данных приведет к реальному коллапсу. Потому как связь вроде есть, но ее тут же нет

Добавлено через 6 минут
И да. Я не про 1С тебе говорю. Я свое ПО писать буду для организации. Поэтому и свою базу надо правильно и хорошо сконфигурить и продумать, прежде чем за код браться.

0

Начнем сначала. И понемногу .

Rank – категория профессий. Поле Тип данных Описание Уникальный ключ Зависимость (таблица.поле) ID int Идентификатор записи (счетчик) ID_Rank Int Идентификатор профессии Да Rank_Name Nvarchar 255 Наименование профессии

что такое ID_Rank? Откуда берете его значения для каждого нового наименования профессии?
почему недостаточного того самого поля Id для суррогатного ключа и связи с другими таблицами?

Добавлено через 4 минуты
Аналогично здесь

Company – наименование организации. Поле Тип данных Описание Уникальный ключ Зависимость(таблица.поле) ID int Идентификатор записи (счетчик) ID_Company Int Идентификатор организации Да Company Nvarchar 255 Наименование организации

Что такое Идентификатор организации ID_Company? Откуда он берется для новых организаций. Почему он может измениться. Почему ОН а не Company.ID используется для связи? А ключевое поле тоже ID_Company? Почему не Company.ID?

Добавлено через 6 минут
если вместо этого

ID_Rank Int Вид профессии (специалист/рабочий/руководитель) Rank.ID_Rank
ID_Company Int Идентификатор организации Company.ID_Company
ID_FIL Int Идентификатор филиала SPR_FIL.ID_FIL

будет как должно быть

ID_Rank Int Вид профессии (специалист/рабочий/руководитель) Rank.Id
ID_Company Int Идентификатор организации Company.Id
ID_FIL Int Идентификатор филиала SPR_FIL.Id

то и не возникнет желания каскадного обновления Id-ов

0

ID_RANK -вид профессии. Допустим
id id_rank Rank_Name
1 1 специалист
2 2 рабочий
3 3 руководитель
4 4 студент
5 5 наемный рабочий
и т. д.
Можно, конечно в таблице сотрудников указать ручками Rank_name, а можно и связать поле со справочником и взять код вида профессии из справочника при запросе. И при изменении вида профы и наименования мне не надо вручную 2000 специалистов лопатить и менять им вид. Да и отслеживать другие таблицы (а их может быть очень много), связанные с этим справочником мне не надо. Достаточно внести изменения в справочник и указать, что теперь категория специалист (ID_Rank) теперь не 1, а 6 и у всех 2000 спецов в таблицах вид профы сразу меняется с 1 на 6. Идея понятна? А если в таблице связей со справочниками более двух, то все. Не работает.

Добавлено через 2 минуты
еще раз повторяю Я НЕ ХОЧУ МЕНЯТЬ ID-ШНИКИ Данные могут измениться На id-шники мне глубоко плевать. Пусть СУБД их отслеживает и наращивает

Добавлено через 1 минуту
было
id id_rank rank_name
1 1 специалист
2 2 рабочий
3 3 руководитель
4 4 студент
5 5 наемный рабочий

стало
id id_rank rank_name
1 6 специалист
2 9 рабочий
3 3 руководитель
4 4 студент
5 5 наемный рабочий

0

Сообщение от drvolodko было id id_rank rank_name 1 1 специалист 2 2 рабочий 3 3 руководитель 4 4 студент 5 5 наемный рабочий стало id id_rank rank_name 1 6 специалист 2 9 рабочий 3 3 руководитель 4 4 студент 5 5 наемный рабочий

вы так и не ответили каким нормативным документом, в записи
1 1 специалист
поле id_rank поменялось с 1 на 6. Уж не говоря о том, что оно нафиг никому не нужно, а связывать таблицу с другими надо
ID_Rank Int Вид профессии (специалист/рабочий/руководитель) Rank.Id

0

Приказ об изменении кода профессии, кода, блять, еще какой-нибудь херни подписанный президентом Зимбабве! Какая нахрен разница, какой норм док? Мне нужно как-то обойти ограничение на связи с таблицами!!!! и СВЯЗАТЬ ОДНУ ТАБЛИЦУ С ТРЕМЯ-ЧЕТЫРМЯ СПРАВОЧНИКАМИ И ДРУГИМИ ТАБЛИЦАМИ. Вот в чем вопрос. Если не знаешь так не тролль меня....

0

ну и правь свой id_rank, если президент зимбавбе каждую должность вводит с кодом, и раз в код коды меняет, да только связывай не по этому полю, а по Id-у. С таким же успехом ключом можно и Rank_Name сделать.
Где ты нахватался таких представлений о РСУБД, в той самой зимбаве?

0

блин... таблица1 имеет связи с другими таблицами (2,3,4,5,6....n) и совершенно похуй по каким полям... Количество связей ограничено двумя полями(таблицами). ПОЧЕМУ? Вот в чем вопрос.....

0

Сообщение от drvolodko Количество связей ограничено двумя полями(таблицами)

только у тебя. У меня с эти проблем нет.

Миниатюры

   

0

спецификации insert update как выставлены? Без каскадного обновления я тоже их нафигачить могу 1000 связей...

0

а это против "двум полям"

Миниатюры

 

0