LINUX.ORG.RU
Форум — Development  

SQL проектирование


0

0

Добрый день!

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

Как принято решать такую задачу в SQL:

Есть сущности Сущность1, Сущность2, Сущность3, Сущность4.

Сущность1 может иметь несколько Сущность2 (т.е. отношение один ко многим). Сущность2 может быть двух типов либо Сущность3 либо Сущность4.

Т.е. между Сущность2 и (Сущность3 или Сущность4) есть отношение многие к одному. Но одновременно связи между (Сущность2-Сущность3) и (Сущность2-Сущность4) быть не может

Например,

Table A (Сущность1)
id


Table B (Сущность2)
id
A_id -> A.id
C_id -> C.id
D_id -> D.id

Table C (Сущность3)
id

Table D (Сущность4)
id

Т.е. в таблице B не может одновременно быть NOT NULL C_id D_id, но один быть NOT NULL обязан.Есть предположение решить через CHECK ().
Правильно ли это? Или есть более изящный способ?




★★
← OpenSource startup business model
zlib helper →
Ответ на: комментарий от true_admin

Тут дело в другом. Это я для краткости не расписывал таблицы. На самом деле они (таблицы типов C и D) имеют сложную структуры и свои зависимости. Поэтому просто флаг типа не подходит.

olegk ★★
() автор топика

В данном случае что может быть изящнее check? Запрета ссылаться на 2 таблицы одновременно проще не придумать (C_id is not null and D_id is null) or (C_id is null and D_id is not null)

anonymous
()

А нас делаю так. Есть таблица services. У services есть service_money (расходы) Расходы бывают двух видов (грубо: трафик или время), которые вообще разные совсем.

и есть соответственно таблицы

services (service_id, login)
service_money (service_money_id, service_id, time_acct_id, traff_acct_id, money)
time_acct (time_acct_id, amount, другие поля)
traff_acct (traff_acct_id, amount, более другие поля)

поля service_money.time_acct_id и service_money.traff_acct_id могут быть null а могу ссылаться на соотвтетствующие таблицы по внешнему ключу.

остальные проверки в клиентсокй части.

name_no ★★
()

Если нужна проверка на уровне СУБД, то CHECK.

Если не обязательно, то можно в Сущность2 добавить поле тип_этой_самой_сущности, а поле для ссылки оставить одно. В этом случае внешний ключ работать не будет, надо будет поддерживать связь на уровне клиентской логики.

Ну и в обоих случаях клиентская логика должна правильно обрабатывать связь между таблицами, принципиальное отличие - второй вариант не дает проверку ссылочной целостности на уровне СУБД.

Bach
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← OpenSource startup business model
Development
zlib helper →