В общем решил как по букве Науки понормализовывать все шо ни попадет под руку - и вот вышло:

-Физ-лицо
-Представители физлица
-банковские счета Физлица

-ЧПФЛ
-Представители ЧПФЛ
-банковские счета ЧПФЛ

-Юрлицо
-Представители Юрлица
-банковские счета Юрлица


правда создал еще

-Контрагент (тута их денормализовал в кучу :) )

типерь надо составить договор:
в котором должны участвовать Контраген, его Представитель и Банковские реквизиты

утут и уперся - шо типерь все взад денормализовывать по типу Контрагент? -> ПредставителиКонтрагента, БанковскиеСчетаКонтрАгента ?????

Как быть или это я зря начитался всяких букварей???????

Mr MarmeladА почему не упростить всё в одну форму


- Лицо
- Вид Лица (Физ, ЧПФЛ, Юр)
- Представитель Лица
- Банковские реквизиты Лица

....

Где нормализация то?

Низзя - у них аттрибуты разные и куча довесов разных

Mr Marmelad
ЧПФЛ (простите не знаю что это такое) ,


Частный Предприниматель-Физическое Лицо

Mr Marmeladsp
Низзя - у них аттрибуты разные и куча довесов разных

Ну единственный различительный аттрибут (на Американизме) бдет только:

SSN (для частного лица налогово - зависимого своим Такс Номером)
EIN (Employee Iditification Number - для юридического лица)

По Американским стандартам эти номера конфедициальны. Должны быть забанены и введены посредники - системно генерированые) Значит этот системный номер и Вид Лица - и будет первичным Ключом. Код представителя - Внешный Ключ. Банковский счёт (Код Банка + номер счёта) - ещё один Внешний ключ. Не вижу больше никаких особых различий в аттрибутике. Ну будет там название предприятия / имя человека... Ну и что И там и там должен быть Человек к которому обращаться за подписью. назовите ещё различия? плииииз.

Ну это Вы зря не видите - там куча спецыфичных для данных сущностей аттрибутов - иначе бы не было смысла нормализовать

Mr Marmeladsp
Низзя - у них аттрибуты разные и куча довесов разных

Ну единственный различительный аттрибут (на Американизме) бдет только:

SSN (для частного лица налогово - зависимого своим Такс Номером)
EIN (Employee Iditification Number - для юридического лица)

По Американским стандартам эти номера конфедициальны. Должны быть забанены и введены посредники - системно генерированые) Значит этот системный номер и Вид Лица - и будет первичным Ключом. Код представителя - Внешный Ключ. Банковский счёт (Код Банка + номер счёта) - ещё один Внешний ключ. Не вижу больше никаких особых различий в аттрибутике. Ну будет там название предприятия / имя человека... Ну и что И там и там должен быть Человек к которому обращаться за подписью. назовите ещё различия? плииииз.

лицо
--------------
PersonID
PersonSalutationID
F
I
O
SexID
BirthDate
Residency
INN
+++++
-внутренние паспорта
-зарубежные
-водительские права
-пенсионные удостоверения
-фактические адреса проживания
-контактные телефоны
-емайлы
-instant messengers
-уполномоченные лица
-банковские счета



юрлицо
----------
EnterpriseID
ParentEnterpriseID
EDRPOU
ShortTitle
FullTitle
OrgFormID
AddressID
SiteURL
++++++++++++
-фактические адреса проживания
-контактные телефоны
-емайлы
-instant messengers
-уполномоченные лица
-банковские счета
-безбалансовые подразделения
-балансовые подразделения




чпфл
-------
PrivateEntrepreneurID
PersonID
INN
Series
No
ActivityCategoryID
AddressID
IssuedBy
SiteURL
++++++++++
-фактические адреса проживания
-контактные телефоны
-емайлы
-instant messengers
-уполномоченные лица
-банковские счета
-безбалансовые подразделения

Mr Marmeladsp
Ну это Вы зря не видите - там куча спецыфичных для данных сущностей аттрибутов - иначе бы не было смысла нормализовать

Так вот нормализации как раз я у Вас и не увидел. Сплошная ДЕ-Нормализация. Я не говорю Коллега что это плохо. Просто согласитесь - повторение той же сущности (участник бизнеса) в трёх и более таблицах - будет называться ДЕ-НОРМАЛИЗАЦИЕЙ

Насколько я понимаю нормализацию - это разнесение аттрибутов, относящихся к разным сущностям по разным талицам - где же у меня денормализация???
даже контактные телефоны - это не одно и то же у них у всех, т.к. назначение у них в принципе разное: на предприятии это - секретарь, рабочий, факс, а для лица - домашний, ну и т.д.

И как Вы себе представляете единую таблицу с аттрибутами и ФизЛица И ЮрЛица и ЧПФЛ? - или необходимо как в той пьесе - тут мы не читаем, тут мы рыбу заворачивали, а тут ваще ничего не надо!? )

Mr MarmeladОй а что за бизнес то у Вас... Colleague... Выглядит как контрразведка близко к ФБР


не знаю как у Вас, но для страховой компании эти данные все нужны - и если мы работаем круче чем ФБР - то в жоп... ту ФБР! )))

MasterZiv
sp wrote:

> Низзя - у них аттрибуты разные и куча довесов разных
Надо наследование делать. Вывести общее, от него наследовать
частное. Юрлицо, физлицо, ИЧП - у них должен быть общий предок,
субъект хоздеятельности (назвать можно по любому). вот его
и в договоры можно совать.


Я так и сделал - у меня есть 2 сущности еще:

Контрагент
---------------
PersonID
PrivateEntrepreneurID
EnterpriseID

СубъектХозДеятельности
----------------------------
EnterpriseID
PrivateEntrepreneurID

но в таком случае все ихние множественные аттрибуты получаетца тоже надо делать через наследование??
ТелефоныКонтрагента, ПредставителиКонтрагента, Банковские реквизитыКонтрагента, Структурные подразделенияКонтрАгента ??????

Belyspутут и уперся - шо типерь все взад денормализовывать по типу Контрагент? -> ПредставителиКонтрагента, БанковскиеСчетаКонтрАгента ?????С чего вы взяли, что это денормализованное представление?
Просто надо специфичные атрибуты для каждого типа контрагента - вынести в отдельную таблицу.

тут такая структура уже обсуждалась.

блин ну сколько уже можно говорить на данном форуме что для EAV(который там обсуждаецца) нужен уже готовый движок - иначе это будет геморрой на всю оставшуюся жизнь!

Belyspутут и уперся - шо типерь все взад денормализовывать по типу Контрагент? -> ПредставителиКонтрагента, БанковскиеСчетаКонтрАгента ?????С чего вы взяли, что это денормализованное представление?
Просто надо специфичные атрибуты для каждого типа контрагента - вынести в отдельную таблицу.

тут такая структура уже обсуждалась.

кстати там /topic/480889&pg=3 есть схемка в которой мои сущности и выделены Лицо, Компания и т.д.

sp,

да еще один тезис забыл в некоторых договорах должны участвовать разные сучности - в одних только физлица в других только СубъектыХозДеятельности, в третьих только Предприятия

iscrafmпро EAV речь вообще не идет.

ну как же там не идет - там обсуждается единый ObjectID

Belyspутут и уперся - шо типерь все взад денормализовывать по типу Контрагент? -> ПредставителиКонтрагента, БанковскиеСчетаКонтрАгента ?????С чего вы взяли, что это денормализованное представление?
Просто надо специфичные атрибуты для каждого типа контрагента - вынести в отдельную таблицу.

тут такая структура уже обсуждалась.

и тут возникает вопрос: как я этого гибрида на клиенте должен буду отображать???
утут читаем, утут не читаем - это от другой сучности, утут ваще не смотрите пока!??

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

а в этой схеме как - если допустим структурные подразделения относяцца только к СХД, а самостоятельные(балансовые) подразделения исключительно только к Предприятиям

Как в единой той структуре контролировать эти ограничения? как их отображать/неотображать на клиенте????

Mr MarmeladДа я пытаюсь хоть одну систему вспомнить где бы мы объекты трудовой (бизнес) деятельности - читай - стороны контрактов - разводили в три (или более) сущности - ни одной не припомню. Все в одной сущности и потом договор сводится просто к формулировке ЗАКАЗЧИК (объект А со всеми своими аттрибутами) вступает в отношения с ИСПОЛНИТЕЛЕМ (объект Б со всеми такими же аттрибутами) при посредстве КОНТРАГЕНТА (объект В со всеми такими же аттрибутами) для выполнения ЗАКАЗА (Проекта и так далее) СРОК - ляляля (Начало Конец) УСЛОВИЯ - ляляля (пп1 ...пп125)

Подписи сторон...

ну я такое видел в 1С - там пишецца Наименование, а подним понимаецца и название Предприятия и Название ЧП и ФИО !))

Правильно я понял Вашу мысль?