Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
24.12.2014, 16:58
|
|||
|---|---|---|---|
Как нужно спроектировать схему под такие условия ? |
|||
|
#18+
Привет. Подскажите пожалуйста. как нужно спроектировать таблицы по такой задаче. Задаю вопрос не по лабораторной работе а для понимания :) Имеется Таблица заявок MainTable. заявки могут оставлять Организации (OrgTable) и Пользователи (UserTable). MainTable id RequesterID Type Столбец Type: 1 - ссылка на OrgTable, 2 - ссылка на userTable OrgTable id Name userTable id name Как спроектировать таблицы, чтобы можно было настроить Ограничения (уникальности, внешних ключей) для столбца MainTable.RequesterID ? Ведь он должен ссылатся на две таблицы ! В итоге в MainTable.RequesterID будут дубли (1,1,2,2) - т.к. она ссылается на 2 разные таблицы. Может быть нужно пойти от обратного, и пусть в таблицах OrgTable/UserTable пусть будут ссылки на MainTable ? Но каким ограничением обеспечить, чтобы не появились "мертвые записи" в таблице MainTable в этом случае ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2014, 17:10
|
|||
|---|---|---|---|
|
|||
Как нужно спроектировать схему под такие условия ? |
|||
|
#18+
ProBiotek, общая должна быть таблица для Организации и Пользователи (Клиенты) и поле Type - уже в ней если для Организации и Пользователи реквизиты слишком разные, и вы не терпимы к "дырявым" таблицам, то делаете ещё 2-е таб. КлиентыОрганизации и КлиентыПользователи , связанные в 1:(1,0) с Клиенты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2014, 17:13
|
|||
|---|---|---|---|
Как нужно спроектировать схему под такие условия ? |
|||
|
#18+
Вы выбираете подход, когда Организации (OrgTable) и Пользователи (UserTable) у Вас суть две разные сущности. Я бы предложил подумать над вариантом объединить их в одну сущность, скажем, Клиент. Тут проблемы с целостностью уже не возникнет, ибо формально таблица одна. Реально же их будет три - Client, ClientOrganizationExtended и ClientPersonExtended. В основной будут только базовые совместимые характеристики, в Extended - дополнительные и уникальные для типа клиента характеристики. Да, контроль целостности типа "вилка" останется. Но критичность нарушения целостности резко снизится, потому можно будет использовать методы контроля целостности, допускающие нарушение (удаление при CHECK CONSTRAINT, например). А можно вообще вместо двух Extended-таблиц пойти на создание одной EAV-таблицы. Там, правда, свои заморочки. В общем, куда не плюнь, везде свои минусы... да, есть и ещё варианты, и тоже с минусами - фантазия-то у нас безгранична. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2014, 17:19
|
|||
|---|---|---|---|
Как нужно спроектировать схему под такие условия ? |
|||
|
#18+
Akina, Что означает "удаление при CHECK CONSTRAINT" ? Каким образом это реализуется ? Я понимаю про каскадное удаление, но там связано с внешними ключами.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2014, 18:02
|
|||
|---|---|---|---|
Как нужно спроектировать схему под такие условия ? |
|||
|
#18+
ProBiotekЧто означает "удаление при CHECK CONSTRAINT" ? Каким образом это реализуется ? То, что тебя смутило в соседней теме " Как сделать такое ограничение ? ". Ни больше ни меньше... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2014, 18:09
|
|||
|---|---|---|---|
|
|||
Как нужно спроектировать схему под такие условия ? |
|||
|
#18+
Правильно было бы разделить MainTable на две таблицы по горизонтали. Как вариант - отказаться от нормализации и собрать в общий "хвост" обе таблицы OrgTable и UseTable. Тогда появятся незаполненные поля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2014, 18:15
|
|||
|---|---|---|---|
Как нужно спроектировать схему под такие условия ? |
|||
|
#18+
Владислав КолосовКак вариант - отказаться от нормализации и собрать в общий "хвост" обе таблицы OrgTable и UseTable. Тогда появятся незаполненные поля.Пустые поля - не так страшно, как избыточные индексы. С хреновой тучей NULL-ов. Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&mobile=1&tid=1540699]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 161ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
