Одна "сущность" не вписывается в рамки БД!

← →
31512 © (2004-05-24 11:01) [0]

Описание проблемы:
Есть в миру организации, которые могут вступать в некие отношения. Например, "Организация А" может выступать поставщиком чего-либо для ряда других организация. "Организация Б" может являться потребителем чего-либо от множества других организаций. В свою очередь возможно, что "Организация Б" является поставщиком для "Организации А" в одном случае, и потребителем в другом. Дабы отобразить эти отношения я создал в БД следующие таблицы:

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.

Но есть одна загвоздка. В отношения может вступать "Население", которое организацией ну ни как не назовёшь. Оно не может быть поставщиком, а может быть только потребителем.

Вопрос.
Как впихнуть его в такую схему? Или может схема принципиально неверна?

← →
paul_k © (2004-05-24 11:09) [1]

А чем физик (или бешеный физик под названием ПБЮЛ) не укладывается в эту схему?
схема вроде проста
лицо --> связь --> классификатор
Осталось, в зависимости от типа лица, ограничить выбор возможных классификаторов, для того, что-бы наш "любимый умный и очень внимательный" пользователь имел как можно меньше шансов ввести полный бред

← →
Sergey13 © (2004-05-24 11:14) [2]

А зачем фиксировать "отношения"? Может имеет смысл определять эти отношения в докаментах, которые отношения порождают. Есть "Договор", в нем поставщик такой то, потребитель такой то. Для другого договора может быть наоборот.
А население... Хоть горшком назови, только в печку не ставь. 8-) Можно и в одну таблу с признаком, можно и в отдельную. Я бы сделал в одной скорее всего.

← →
bushmen © (2004-05-24 11:14) [3]

Ну и что, что население не является организацией!
В справочнике организаций заводишь еще одно поле - признак населения. И в момент формирования отношений смотришь, что если значение этого поля 1, то программно блокируешь возможность добавления его как поставщика

← →
31512 © (2004-05-24 11:21) [4]

> paul_k © (24.05.04 11:09) [1]

Не уверен что полностью тебя понял. Поясни, пожалуйста.
Классификатор это, например, "организация"/"не организация"?

← →
XYZ (2004-05-24 11:23) [5]

Ну да, одна таблица - Контрагенты. А в ней и ФЛ, и ЮЛ (с признаком - Ю/Ф), +можно 2 дополнительные табл. атрибутов создать - для юр.лиц одно, для физ.лиц другое.

← →
31512 © (2004-05-24 11:25) [6]

> Sergey13 © (24.05.04 11:14) [2]

Не годится. Документов нет.

> bushmen © (24.05.04 11:14) [3]

Интересно. Анализирую твоё предложение.

← →
Sergey13 © (2004-05-24 11:30) [7]

2 31512 © (24.05.04 11:25) [6]
>Не годится. Документов нет.
Отношения без документов называют еще сожительством физиков с лириками. 8-)

← →
31512 © (2004-05-24 11:33) [8]

А такое решение:

Добавить булевское поле, такое, что
true - население является потребителеи этой организации
false - население не является потребителеи этой организации.

← →
31512 © (2004-05-24 11:42) [9]

> Sergey13 © (24.05.04 11:30) [7]

У тебя есть документ, свидетельствующий, что ты являешься потребителем электроэнергии. Между тем ты - население.

← →
bushmen © (2004-05-24 11:49) [10]

>Добавить булевское поле, такое, что
>true - население является потребителеи этой организации
>false - население не является потребителеи этой организации

В принципе, хрен редьки не слаще. Просто может возникнуть ситуация, когда надо будет отделять Юридических лиц от ПБОЮЛ. Мне кажется уж лучше использовать тип byte

← →
Sergey13 © (2004-05-24 11:52) [11]

2 31512 © (24.05.04 11:42) [9]
>У тебя есть документ, свидетельствующий, что ты являешься потребителем электроэнергии.
А как же? Квиток каждый месяц присылают, я по нему и плачУ.

>Между тем ты - население.
Я народ!!! 8-)

← →
bushmen © (2004-05-24 11:57) [12]

В смысле tinyint :)))

← →
paul_k © (2004-05-24 11:58) [13]

> 31512 © (24.05.04 11:21) [4]

Лицо - справочник
Взаимоотношения - тип классификатора
потребитель
поставщик
партнер
......
- Значения типа классификатора
Тип лица связан с типом (типами ) классификатора через таблицу

← →
31512 © (2004-05-24 12:02) [14]

> Sergey13 © (24.05.04 11:52) [11]

Так вот. Открую тебе страшную тайну! На самом деле - потребителем элктроэнергии является твоя квартира, или точнее жилплощадь. Поэтому платит за это тот, кто там проживает. Вот, например, ты уехал на дачу. А к тебе пришёл дядя Вася и давай гнать самогон на бесконечно любимой тобой, твоей же, электроплите. И нажёг он, скажем, 800 кВт*ч. А платить будешь ты, поскольку счётик прикреплён к твоей квартире, его серийный номер записан в Энергосбыте и проживаешь в не ты - на основании регистрации (ранее прописки). Именно поэтому при переезде меняют только прописку и не заключают никакие договора с ЖКХ.

← →
paul_k © (2004-05-24 12:05) [15]

← →
31512 © (2004-05-24 12:11) [16]

> paul_k © (24.05.04 11:58) [13]

Тут у меня ещё одна мысль созрела.
Может завести на население отдельную таблицу?
Ведь всегда ясно, что население - потребитель.
Например так:
create table [PEOPLE]( ID_ORGANISATION int not null foreign key references [ORGANISATION](ID_ORGANISATION) on delete cascade, VALUE float null, DESCRITION nvarchar (255) null )

И читать можно так: Население потребляет VALUE чего-либо у ID_ORGANISATION.
Разумеется таблицу надо расширить...

← →
paul_k © (2004-05-24 12:22) [17]

Вариант , по моему, неверный.
ПБЮЛ у тебя - это физик или юрик?
Физик (как ты выражаешся население) может участвавать в действиях из перечня-1
Юрик (организация) в действиях из перечня-2
Перечень-1 является подмножеством перечня-2
Следовательно, по моему мнению, Физики и Юрики должны составлять единое множество.
то есть должен существовать список в котором присутствуют и те и другие. Как это организовывать - личное дело каждого программиста.
Мне понравилась реализация, при которой существует таблица с относительно общими параметрами для всех типов лиц (Физ.,Юр.. и пока все) и связь с таблицами данных для каждого из них.

← →
paul_k © (2004-05-24 12:25) [18]

Кстати, вопрос взаимоотношений и их учета сильно зависит от задачи. Уж не очередную CRM ли пишешь?

← →
Сергей Суровцев © (2004-05-24 12:40) [19]

Подход всегда стандартный - таблица контрагентом ЛЮБЫХ, туда и население, и организации и все что угодно, только желательно признаки выставлять. И таблица взаимоотношений - кто кому чего и сколько. По одной строке на операцию. Из такой схемы ты всегда быстро и точно выжмешь конечный остаток на любую точку периода. И вести ее - одно удовольствие. (А не вести - другое :)) ).

> paul_k ©

Может и CRM, не знаю. Пока не решил.
Население - не совсем физическое лицо. Точнее совсем не физическое лицо. Чтобы окончательно всё запутать скажу, что это "группа потребителей", для которой отдельно устанавливаются определённые правила.
Итак, что требуется:
1. Население заносить в эти отношения как любую другую организацию.
2. Население не может быть производителем или поставщиком. Только потребителем.
3. У населения не может быть атрибутов организации (Юр. адрес, код ОКПО и пр.)

Вот я и пытаюсь уяснить твою схему.

> Сергей Суровцев © (24.05.04 12:40) [19]

На сей момент так оно и есть. НО! Неприятность в том, что аеселение в такой схеме может запросто продать кому-нибудь электроэнергию. Такое недопустимо. + Население может войти во все прочие взаимоотношения, даже стать Базовым поставщиком для некой организации.
Сразу оговорюсь, что имею дело с аудитом, а не с бухучётом. И таких "невписываемых" объектов там полно.

Чем "население" отличается от "организации" (по структуре данных)
1. - несколькими модификаторами . остальное у них, IMHO, общее.
2. - ТИПОМ!!!!
Простейшее и описанное выше -
В зависимости от ТИПА лица используем разные ТИПЫ классификаторов, описанные выше
Кстати, является лицо "населением" или "организацией" - тоже классификатор типа "Типы лиц" и так далее....

> Сергей Суровцев © (24.05.04 12:40) [19]

На сей момент так оно и есть. НО! Неприятность в том, что население в такой схеме может запросто продать кому-нибудь электроэнергию. Такое недопустимо. + Население может войти во все прочие взаимоотношения, даже стать базовым поставщиком для некой организации.
Сразу оговорюсь, что имею дело с аудитом, а не с бухучётом. И таких "невписываемых" объектов там полно.

> Неприятность в том, что население в такой схеме может запросто
> продать кому-нибудь электроэнергию.

А по сопатке тому, кто такой бред ввел, вплоть до увольнения, чтоб неповадно остальным было

>Неприятность в том, что население в такой схеме может запросто >продать кому-нибудь электроэнергию

А ты как программист на что? В логике программы и учитывай это по признвку!

>31512 © (24.05.04 13:00) [21]
>На сей момент так оно и есть. НО! Неприятность в том, что >аеселение в такой схеме может запросто продать кому-нибудь >электроэнергию. Такое недопустимо.

Это хорошо, что так и есть. Значит дело за малым - сделать признак "покупатель, продавец, провец-покупатель", последний по вкусу и выставить запрет операции на продажу если контрагент - покупатель прямо на уровне интерфейса. Снимешь сразу и свою головную боль, и оператора. Да и к базе обращений меньше будет.
А от того аудит это или бухучёт ничего не меняется. Подход общий.

2 31512 © (24.05.04 12:02) [14]
>Так вот. Открую тебе страшную тайну! На самом деле - потребителем элктроэнергии является твоя квартира
Открой мне еще одну тайну. Как я плачу за электроэнергию? Может кидаю деньги с балкона на ветер, который уже сам донесет их до поставщика. Или все таки иду в кассу и заполняю некий документ на оплату за услугу?
Ты, ИМХО, слегка зациклился на населении и отсутствии у него "формального" договора (кстати, наличие счетчика - уже договор, хотя может и не формальный). А между организациями - тоже нет документов? Или не завод платит, а владец юридического адреса предприятия - так что ли? А как будут отражаться возможные трехсторонние отношения, когда мы им железо, они кому то гвозди, а уж те нам энергию? А бартерные договоры? Нет, без "Документа" в "отношениях" трудно, да и не стоит, ИМХО, шкурка выделки.

Одна "сущность" не вписывается в рамки БД! Найти похожие ветки