![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Одна "сущность" не вписывается в рамки БД! [D7, MSSQL]
31512 © (2004-05-24 11:01:00)Описание проблемы:
Есть в миру организации, которые могут вступать в некие отношения. Например, "Организация А" может выступать поставщиком чего-либо для ряда других организация. "Организация Б" может являться потребителем чего-либо от множества других организаций. В свою очередь возможно, что "Организация Б" является поставщиком для "Организации А" в одном случае, и потребителем в другом. Дабы отобразить эти отношения я создал в БД следующие таблицы:
1. Эта таблица представляет справочник организаций, хранящий их атрибуты. Они общие для всех организаций.
create table [ORGANISATION](
ID_ORGANISATION int not null primary key,
ORGANISATION_NAME nvarchar (255) collate Cyrillic_General_CI_AS not null default 'Нет данных',
ORGANISATION_ADRESS nvarchar (255) collate Cyrillic_General_CI_AS not null default 'Нет данных',
ORGANISATION_CODE nvarchar (255) collate Cyrillic_General_CI_AS not null default 'Нет данных',
.
.
.
и т.д.
)
2. Эта таблица есть справочник типов отношений, могущих возникать между организациями
create table [CONTRAGENTS_TYPE](
ID_CONTRAGENT_TYPE int not null primary key,
CONTRAGENT_TYPE nvarchar (255) collate Cyrillic_General_CI_AS not null default 'Неопределено',
)
3. Ну и, собственно, таблица, устанавливающая эти отношения
create table [CONTRAGENTS](
ID_ORGANISATION1 int not null foreign key references [ORGANISATION](ID_ORGANISATION) on delete no action,
ID_ORGANISATION2 int not null foreign key references [ORGANISATION](ID_ORGANISATION) on delete cascade,
ID_CONTRAGENT_TYPE int not null foreign key references [CONTRAGENTS_TYPE](ID_CONTRAGENT_TYPE) on delete cascade
)
Считать надо так: Для ID_ORGANISATION1 - ID_ORGANISATION2 является ID_CONTRAGENT_TYPE.
Но есть одна загвоздка. В отношения может вступать "Население", которое организацией ну ни как не назовёшь. Оно не может быть поставщиком, а может быть только потребителем.
Вопрос.
Как впихнуть его в такую схему? Или может схема принципиально неверна?
Sergey13 (2004-05-24 11:30:00) [21]2 31512 © (24.05.04 11:25) [6]
>Не годится. Документов нет.
Отношения без документов называют еще сожительством физиков с лириками. 8-)
31512 (2004-05-24 11:25:00) [22]
> Sergey13 © (24.05.04 11:14) [2]
Не годится. Документов нет.
> bushmen © (24.05.04 11:14) [3]
Интересно. Анализирую твоё предложение.
XYZ (2004-05-24 11:23:00) [23]Ну да, одна таблица - Контрагенты. А в ней и ФЛ, и ЮЛ (с признаком - Ю/Ф), +можно 2 дополнительные табл. атрибутов создать - для юр.лиц одно, для физ.лиц другое.
31512 (2004-05-24 11:21:00) [24]
> paul_k © (24.05.04 11:09) [1]
Не уверен что полностью тебя понял. Поясни, пожалуйста.
Классификатор это, например, "организация"/"не организация"?
bushmen (2004-05-24 11:14:00) [25]Ну и что, что население не является организацией!
В справочнике организаций заводишь еще одно поле - признак населения. И в момент формирования отношений смотришь, что если значение этого поля 1, то программно блокируешь возможность добавления его как поставщика
Sergey13 (2004-05-24 11:14:00) [26]А зачем фиксировать "отношения"? Может имеет смысл определять эти отношения в докаментах, которые отношения порождают. Есть "Договор", в нем поставщик такой то, потребитель такой то. Для другого договора может быть наоборот.
А население... Хоть горшком назови, только в печку не ставь. 8-) Можно и в одну таблу с признаком, можно и в отдельную. Я бы сделал в одной скорее всего.
paul_k (2004-05-24 11:09:00) [27]А чем физик (или бешеный физик под названием ПБЮЛ) не укладывается в эту схему?
схема вроде проста
лицо --> связь --> классификатор
Осталось, в зависимости от типа лица, ограничить выбор возможных классификаторов, для того, что-бы наш " любимый умный и очень внимательный " пользователь имел как можно меньше шансов ввести полный бред