Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

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

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

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

bushmen (2004-05-24 13:49:00) [3]
>Неприятность в том, что население в такой схеме может запросто >продать кому-нибудь электроэнергию

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

paul_k (2004-05-24 13:05:00) [4]

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

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

31512 (2004-05-24 13:01:00) [5]

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

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

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

31512 (2004-05-24 13:00:00) [7]

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

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

31512 (2004-05-24 12:47:00) [8]

> paul_k ©

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

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

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

paul_k (2004-05-24 12:25:00) [10]
Кстати, вопрос взаимоотношений и их учета сильно зависит от задачи. Уж не очередную CRM ли пишешь?

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

31512 (2004-05-24 12:11:00) [12]

> 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:05:00) [13]

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

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

PersonId ContragentId KlassTypeId KlassValueId

31512 (2004-05-24 12:02:00) [14]

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

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

paul_k (2004-05-24 11:58:00) [15]

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

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

bushmen (2004-05-24 11:57:00) [16]
В смысле tinyint:)))

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

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

bushmen (2004-05-24 11:49:00) [18]
>Добавить булевское поле, такое, что
>true - население является потребителеи этой организации
>false - население не является потребителеи этой организации

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

31512 (2004-05-24 11:42:00) [19]

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

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

31512 (2004-05-24 11:33:00) [20]
А такое решение:

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »