ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Re: Платежка
21 сообщений из 21, страница 1 из 1
Re: Платежка
    #33626135
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
После некоторых мыканий снова:

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

Подскажите пожалуста как ее можно решить?
чтобы можно было бы отобразить и физлиц и юрлиц при заполнении и при случае по платежке получить данные соответствующие типу сущности"

Мне подсказали:
Создаем сущность

ЛИЦО
----------
ID
FK Тип Лица


ТИП ЛИЦА
-------------
ID
Тип Лица


ФИЗЛИЦО
------------
ID Лицо
...


ЮРЛИЦО
-------------
ID Лицо
...

ЧП
---------------
ID Лицо
...

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

Есть другой вариант:

ЛИЦО
----------
ID
FK ФИЗЛИЦО
FK ЧП
FK Предприятие

ФИЗЛИЦО
--------------
...

ЧП
--------------
...

ПРЕДПРИЯТИЕ
--------------
...

в этом варианте лишь необходимо написать ограничение что лицо долно быть лишь одного типа

В обоих случаях непонятно как писать запрос в котором бы к примеру отображать аттрибуты платежки и плательщиков если они из разных таблиц?

Покритикуйте оба варианта пожалуста.
И кто каким пользуется в жизни?

Спасибо за помощь!
...
Рейтинг: 0 / 0
27.03.2006, 02:38
| Ответить | Цитировать | Написать  
Re: Платежка
    #33626348
nnov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nnov
Участник
Если речь идет о формировании платежки, то по моему
тут одна сущьность "плательщик", а статус физ.лицо юр.лицо это атрибут сущьности. И резнесения в разные таблици вообще не надо делать
я бы делал две таблицы

таблица плательщиков
ID
Организационная форма
другие атрибуты
...

и платежные реквизиты
все реквизиты необходимые в платежке

связь один ко многим так как у плательщика может быть много банков
...
Рейтинг: 0 / 0
27.03.2006, 09:56
| Ответить | Цитировать | Написать  
Re: Платежка
    #33626768
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
Ну вы же невнимательно прочитали мой пост - все сущности самостоятельны и не могут быть в одной таблице в силу наличия не только кардинально разных аттрибутов, но и роли в системе

nnovЕсли речь идет о формировании платежки, то по моему
тут одна сущьность "плательщик", а статус физ.лицо юр.лицо это атрибут сущьности. И резнесения в разные таблици вообще не надо делать
я бы делал две таблицы

таблица плательщиков
ID
Организационная форма
другие атрибуты
...

и платежные реквизиты
все реквизиты необходимые в платежке

связь один ко многим так как у плательщика может быть много банков
...
Рейтинг: 0 / 0
27.03.2006, 12:07
| Ответить | Цитировать | Написать  
Re: Платежка
    #33627163
MX -- ALEX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MX -- ALEX
Гость
spНу вы же невнимательно прочитали мой пост - все сущности самостоятельны и не могут быть в одной таблице в силу наличия не только кардинально разных аттрибутов, но и роли в системе

nnovЕсли речь идет о формировании платежки, то по моему
тут одна сущьность "плательщик", а статус физ.лицо юр.лицо это атрибут сущьности. И резнесения в разные таблици вообще не надо делать
я бы делал две таблицы

таблица плательщиков
ID
Организационная форма
другие атрибуты
...

и платежные реквизиты
все реквизиты необходимые в платежке

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

выбор банка из всех его возможных банков автоматичски - по прецеденту
либо вручную если впервые
...
Рейтинг: 0 / 0
27.03.2006, 14:16
| Ответить | Цитировать | Написать  
Re: Платежка
    #33627626
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
MX -- ALEX
у нас установлен приоритет
если не находит среди частных лиц - тогда ищет среди фирм и т д

выбор банка из всех его возможных банков автоматичски - по прецеденту
либо вручную если впервые

про банки все и так понятно вопрос про организацию бд для выбора и подстановки разных сущностей в одно поле
...
Рейтинг: 0 / 0
27.03.2006, 16:16
| Ответить | Цитировать | Написать  
Re: Платежка
    #33627638
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Раз нельзя объединить таблицы, то создайте view Плательщик, в котором
outer join все соберет из разных таблиц, а CASE разложит по полям, нужным для платежки.
...
Рейтинг: 0 / 0
27.03.2006, 16:20
| Ответить | Цитировать | Написать  
Re: Платежка
    #33627680
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Если же вопрос в том, чтобы на уровне декларативной целостности гарнтировать, что документ типа А ссылается только на юрлицо или ЧП, а документ типа Б - только на ЧП или физлицо, то можно так
ЛИЦО
----------
ID
FK Тип Лица
...
UNIQUE (ID,Тип Лица)


ДОК А
----------
ID
Лицо_ID
Лицо_Тип
...
FK (Лицо_ID,Лицо_Тип) ЛИЦО (ID,Тип Лица)
CHECK Лицо_Тип ='юрлицо' or Лицо_Тип ='ЧП'

ДОК Б
----------
ID
Лицо_ID
Лицо_Тип
...
FK (Лицо_ID,Лицо_Тип) ЛИЦО (ID,Тип Лица)
CHECK Лицо_Тип ='физлицо' or Лицо_Тип ='ЧП'
...
Рейтинг: 0 / 0
27.03.2006, 16:31
| Ответить | Цитировать | Написать  
Re: Платежка
    #33628000
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Estets
Участник
spНу вы же невнимательно прочитали мой пост - все сущности самостоятельны и не могут быть в одной таблице в силу наличия не только кардинально разных аттрибутов, но и роли в системе
Что то это заявление не вяжется с
spв платежке отправителем может быть частный предприниматель, физлицо и предприятие.
Значит в этом (а как подсказывает опыт еще в десятках других случаев) все эти сущности могут использоваться в одной роли.

Так что я бы прислушался к совету объединить их в одной или наборе таблиц например:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
T_PARTNER( -- все лица
ID
PARTNER_TYPE
FULL_NAME
INN -- Общие данные по всем лицам
...)

T_LEGAL(
ID
-- специфичные данные по юрикам
...)

T_PERSON(
ID
-- специфичные данные по физикам
)

А если необходимо отображать "кардинально разных аттрибуты", создать WIEW

Код: plaintext
1.
2.
SELECT * FROM T_PARTNER, T_LEGAL
WHERE T_PARTNER.PARTNER_TYPE = 'LEGAL'
AND T_PARTNER.ID = T_LEGAL.ID

Часто используемая и достаточно удобная схема.
...
Рейтинг: 0 / 0
27.03.2006, 18:04
| Ответить | Цитировать | Написать  
Re: Платежка
    #33628203
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
а можно хотябы на схематично это изобразить ?


ModelRРаз нельзя объединить таблицы, то создайте view Плательщик, в котором
outer join все соберет из разных таблиц, а CASE разложит по полям, нужным для платежки.
...
Рейтинг: 0 / 0
27.03.2006, 20:01
| Ответить | Цитировать | Написать  
Re: Платежка
    #33628706
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Типа
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
select 
 case when ЛИЦО.ТипЛица ='юрлицо' then ЮРЛИЦО.Наименование
         when ЛИЦО.ТипЛица ='физлицо' then ФИЗЛИЦО.Имя+ФИЗЛИЦО.Фамилия
 end AS name
 ....
from
 ЛИЦО
 left join ФИЗЛИЦО on (ЛИЦО.ID=ФИЗЛИЦО.ID_Лицо)
 left join ЮРЛИЦО on (ЛИЦО.ID=ЮРЛИЦО.ID_Лицо)
 ..
Синтаксис проверьте по используемой СУБД.
...
Рейтинг: 0 / 0
28.03.2006, 09:31
| Ответить | Цитировать | Написать  
Re: Платежка
    #33628869
nnov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nnov
Участник
spНу вы же невнимательно прочитали мой пост - все сущности самостоятельны и не могут быть в одной таблице в силу наличия не только кардинально разных аттрибутов, но и роли в системе

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

sp
у нас установлен приоритет
если не находит среди частных лиц - тогда ищет среди фирм и т д

Эта логика работы прекрасно вписывается в предложенный мною вариант
Если форма собственность выделена отдельным атрибутом плательщика нет никаких проблем выбрать сначала частников потом фирмы, если хотите
то сначала частников, потом ЗАО, потом ООО, потом ОАО и т.д.
...
Рейтинг: 0 / 0
28.03.2006, 10:46
| Ответить | Цитировать | Написать  
Re: Платежка
    #33629994
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
Это если работать только с платежками, а если думать о других видах учета где эти сущности могут быть не только в роли плательщиков то тогда нужно получается и из других сущностей лепить в одну кучу и таких куч надо плодить по каждой роли сущностей?

nnov
Я думаю вы преувеличиваете, приведите пример разных ролей в системе
да и атрибуты должны быть одинаковы, сущность одна - плательщик
Попробуйте более абстракто посмотреть на задачу
...
Рейтинг: 0 / 0
28.03.2006, 15:28
| Ответить | Цитировать | Написать  
Re: Платежка
    #33630098
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
ну все же никто не помог с ответом: что лучше наследовать физлицо, юрлицо от Лицо или наоборот Лицо наследовать от сущностей Юрлицо и Физлицо
(проще: создавать FK поля в сущностях Физлицо и Юрлицо на Лицо или в сущности Лицо создать поля FK Физлицо и FK Юрлицо)
...
Рейтинг: 0 / 0
28.03.2006, 15:57
| Ответить | Цитировать | Написать  
Re: Платежка
    #33630556
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
nnovЭта логика работы прекрасно вписывается в предложенный мною вариант
Если форма собственность выделена отдельным атрибутом плательщика нет никаких проблем выбрать сначала частников потом фирмы, если хотите
то сначала частников, потом ЗАО, потом ООО, потом ОАО и т.д.

Это когда речь идет о субъектах предпринимательской деятельности, а если платит гражданин в банке через кассу, что тоже его в общую таблицу?
...
Рейтинг: 0 / 0
28.03.2006, 18:08
| Ответить | Цитировать | Написать  
Re: Платежка
    #33630663
Фотография proposed amendment
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
proposed amendment
Участник
БОЯН

поиском по форуму - на тему "физики vs юрики"... только ленивый еще не высказался...
...
Рейтинг: 0 / 0
28.03.2006, 18:46
| Ответить | Цитировать | Написать  
Re: Платежка
    #33630956
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
там к сожалению не обсуждаются эти 2 модели - там только спор держать ли все это в одной таблице или в отдельных, а мне необходимо другое :(

proposed amendmentБОЯН

поиском по форуму - на тему "физики vs юрики"... только ленивый еще не высказался...
...
Рейтинг: 0 / 0
28.03.2006, 22:59
| Ответить | Цитировать | Написать  
Re: Платежка
    #33631888
nnov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nnov
Участник
spЭто когда речь идет о субъектах предпринимательской деятельности, а если платит гражданин в банке через кассу, что тоже его в общую таблицу?
Какая разница как он платит, от того через кассу или безналом, его статус не меняется - ОН ПЛАТЕЛЬЩИК
Я уже спрашивал где еще применяются эти объекты
spЭто если работать только с платежками, а если думать о других видах учета где эти сущности могут быть не только в роли плательщиков
Какие другие роли?
Или мы говорим о обстрактной задаче?
...
Рейтинг: 0 / 0
29.03.2006, 12:28
| Ответить | Цитировать | Написать  
Re: Платежка
    #33631962
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
О ролях и классах. С точки зрения структуры СУБД единственно чем роль отличается от подкласса - неисключительность.
По классификации лицо либо юридическое либо физическое.
По роли лицо может быть и плательщиком и кем угодно еще.
И роли и подклассы реализуются одинаково - через ФК на ЛИЦО.

Ограничение исключительности как правило вообще никак не реализуется,
а отражается а программном коде запросов, как в примере 2495947. Т.е если сказано что ЛИЦО.ТипЛица ='юрлицо' то даже если в таблице ФИЗЛИЦО что-то есть, оно игнорируется.

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

Набор ФК из ЛИЦО в подклассы, роли может быть полезен, если рассматривать ЛИЦО как нормативный реестр. Наличие отметки в нем о роли/подклассе запрещает удаление из соответсвующей сущности.

Так что можно использовать оба ФК одновременно, только будут заморочки - проверка должна быть отложена до конца транзакции, меняющей этот кластер таблиц.
...
Рейтинг: 0 / 0
29.03.2006, 12:46
| Ответить | Цитировать | Написать  
Re: Платежка
    #33637925
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
Ну вроде со структорой все роде понятно - либо:

Лицо СПД ФизЛицо Персона Тип лица
---------- ------------ ----------- ------------- ------------
ID лицо ID лицо ID лицо ID лицо ID тип лица
FK тип лица .... .... .... тип лица

все понятно, но необходимо следить чтоб подсущность СПД,Физлицо и Персона удалялись бы вместе с сущностью Лицо

либо:
Лицо СПД ФизЛицо Персона
---------- ------------ ----------- -------------
ID лицо ID СПД ID Физлицо ID Персона
ID СПД .... .... ....
ID Физлицо
ID Персона

а в этом случае необходимо следить наоборот + следить чтобы лишь одно поле в сущности Лицо имело ссылку

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

В чем еще плюсы и минусы обоих способов реализации?
Попутно еще возникает вопрос: при платежах населения их всех надо будет запихивать в сущность персона - фактически там организуется мусорник т.к. никак нельзя отличить одного Иванова Ивана Ивановича от другого, тем не менее там должны храниться и сотрудники компании и клиенты и многие другие.
Как рулить этот мусорник?
...
Рейтинг: 0 / 0
31.03.2006, 15:21
| Ответить | Цитировать | Написать  
Re: Платежка
    #33637931
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
Прошу прощения в предылущем посте форматирование было сожрано
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
Ну вроде со структорой все роде понятно - либо:

Лицо               СПД                   ФизЛицо           Персона             Тип лица
----------        ------------        -----------       -------------       ------------
ID лицо            ID лицо              ID лицо            ID лицо               ID тип лица
FK тип лица      ....                     ....                  ....                     тип лица

все понятно, но необходимо следить чтоб подсущность СПД,Физлицо и Персона удалялись бы вместе с сущностью Лицо

либо:
Лицо               СПД                   ФизЛицо           Персона            
----------        ------------        -----------       -------------    
ID лицо            ID СПД              ID Физлицо        ID Персона          
ID СПД             ....                     ....                  ....                   
ID Физлицо
ID Персона

а в этом случае необходимо следить наоборот + следить чтобы лишь одно поле в сущности Лицо имело ссылку

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

В чем еще плюсы и минусы обоих способов реализации?
Попутно еще возникает вопрос: при платежах населения их всех надо будет запихивать в сущность персона - фактически там организуется мусорник т.к. никак нельзя отличить одного Иванова Ивана Ивановича от другого, тем не менее там должны храниться и сотрудники компании и клиенты и многие другие.
Как рулить этот мусорник?
...
Рейтинг: 0 / 0
31.03.2006, 15:23
| Ответить | Цитировать | Написать  
Re: Платежка
    #33641305
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
sp
В первом случае с увеличением ролей необходимо будет модифицировать структуру трех таблиц добавляя в них поле-ссылку на сущность-роль[quot]Кто здесь роль?[/quot sp]
Во втором случае - лишь одну

В чем еще плюсы и минусы обоих способов реализации?
Попутно еще возникает вопрос: при платежах населения их всех надо будет запихивать в сущность персона - фактически там организуется мусорник т.к. никак нельзя отличить одного Иванова Ивана Ивановича от другого, тем не менее там должны храниться и сотрудники компании и клиенты и многие другие.
Как рулить этот мусорник?Клиенты и сотрудники - типичные роли. Как правило сотрудникам не запрещается быть клиентами. С ролями вроде разобрались. Вопрос в доступе. Человек нанимается на работу. Доступна ли кадрам база клиентов? Менеджерам кадровая база?
...
Рейтинг: 0 / 0
03.04.2006, 14:53
| Ответить | Цитировать | Написать  
21 сообщений из 21, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Re: Платежка
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=33627680&tid=1545335]:
 0ms
get settings:
 7ms
get forum list:
 9ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 170ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 78ms
get tp. blocked users:
 2ms
others: 230ms
total:  515ms
созд. / загр.: 515ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]