плиз помогите с ДБ дизайном

User avatar
Sabina
Уже с Приветом
Posts: 5669
Joined: 13 Oct 2000 09:01
Location: East Bay, CA

плиз помогите с ДБ дизайном

Post by Sabina »

Есть кусочек базы (см. диаграмму на картинке)

Проблема с managerID. По идее хорошо бы его привязать к userID, но получаются сплошные противоречия.

1) Если посадить в Department table, то нельзя делать FK на CMSUser.userID, потому что как тогда заполнять. Department не заполнишь без юзеров, а юзеров без department-а.

2) Если посадить аттрибутом в CMSUser, то получается референс таблицы саму на себя и опять сложности с заполнением таблицы: типа начать с менеджера но в первом же рекорде ссылка на самого себя....

Получается никак этого manager ID в foreign key не засунешь...
Ну не делать же отдельную таблицу с парами Отдел-Менеджер, которая будет заполняться после отдела и юзеров?

Как это все дело нормализовать пограмотнее?

Сабина
User avatar
Dmitry67
Уже с Приветом
Posts: 28294
Joined: 29 Aug 2000 09:01
Location: SPB --> Gloucester, MA, US --> SPB --> Paris

Post by Dmitry67 »

Картинка не читается
Но если структура запутанная то зачем городить FK ?
Многие сложные аспекты логики проверяются триггерами или обеспечиваются 'по построению' через stored proc
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
User avatar
Sabina
Уже с Приветом
Posts: 5669
Joined: 13 Oct 2000 09:01
Location: East Bay, CA

Post by Sabina »

Dmitry67 wrote:Картинка не читается


Я на html поменяла.
User avatar
Sabina
Уже с Приветом
Posts: 5669
Joined: 13 Oct 2000 09:01
Location: East Bay, CA

Post by Sabina »

Dmitry67 wrote:Картинка не читается
Но если структура запутанная то зачем городить FK ?
Многие сложные аспекты логики проверяются триггерами или обеспечиваются 'по построению' через stored proc


Дима, у меня есть подозрение, что я это все потому что я дальше first normal form сама никогда не "ходила"... :oops:
Пусть думаю спецы глянут.

Сабина
zVlad
Уже с Приветом
Posts: 15311
Joined: 30 Apr 2003 16:43

Re: плиз помогите с ДБ дизайном

Post by zVlad »

Sabina wrote:Есть кусочек базы (см. диаграмму на картинке)

Проблема с managerID. По идее хорошо бы его привязать к userID, но получаются сплошные противоречия.

1) Если посадить в Department table, то нельзя делать FK на CMSUser.userID, потому что как тогда заполнять. Department не заполнишь без юзеров, а юзеров без department-а.

.....


А может уточну позже, но навскидку объяснение такое: внешний ключ может иметь значение NULL (по крайней мере в DB2). Таким образом сначала заводится департмент с NULL в столбце менеджера, затем имрлои (менеджер) и строка департмента обновляется с этим (или другим) имплои.
User avatar
JustMax
Уже с Приветом
Posts: 1476
Joined: 05 Dec 2000 10:01
Location: Vilnius -> Bonn

Post by JustMax »

1 ) Я бы IMHO обьеденил USER и LoginInfo. (Third Normal Form ?)
Зачем городить сущности ? Ну ето дело вкуса.
2) Согласен с zVlad, добавлю только что, начиная с 8 Оракла
есть возможность создавать deffered constraints, t.e проверка на ссылочную целостность осуществляется только при commit.
T.e. вставляете запись в департамент без managerID -> всавляете
менеджера -> изменяете managerID -> commit. Все FK not null :)
User avatar
Sabina
Уже с Приветом
Posts: 5669
Joined: 13 Oct 2000 09:01
Location: East Bay, CA

Post by Sabina »

JustMax wrote:1 ) Я бы IMHO обьеденил USER и LoginInfo. (Third Normal Form ?)
Зачем городить сущности ? Ну ето дело вкуса.


Моим мотивом было то, что LoginInfo table будет востребована гораздо чаще чем CMSUser.

Сабина

Return to “Вопросы и новости IT”