|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
Прошу помощи, т.к. нервы уже на пределе, пол инета обрыл, но везде одно и тоже из банальных вещей. Есть таблица Clients(id(PK), name) и таблица Clients_type(id, ver(PK), name, start_date, end_date) Пусть в Клиентах будет Иванов и Петров. В Clients_type будут ФилЛица (1900-2999) и ЮрЛица (1900-2999), и так же элемент ИП с датами действия 2010-2999 Реализован якорь Clients_X_attr, где будут поля Clients_id и Clients_type_id добавляя в этот якорь поля - мы можем без изменения архитектуры добавлять еще атрибуты к Clients - это ясно! Ну и вопрос: Если у Иванова сменился тип клиента с ФЛ на ЮЛ, как это реализовать? 1. Сделать Clients_X_attr и впендюрить туда Дату начала и дату окончания - не есть верное, т.к. прийдётся тогда при каждом изменении любого атрибута пересчитывать всю таблицу, затрагивая и учитывая все другие атрибуты у Clients. Наверное не верно! 2. Вынести связку Clients_X_attr по связке Clients_type_id в другую таблицу с Началом и Концом действия этой связки. Наверное так, но нахрена тогдя сам якорь? для каждого атрибута делать свой якорь если атрибутов версионных будет несколько? Якорь же для этого и есть якорь чтобы не плодить 200+ таблиц и не переделывать! 3. наверное есть 3-ий вариант более удобный и правильный! За схему и подсказку буду очень признателен! ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2021, 11:22 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
НиколайСН, Клиент Иванов ФЛ это новый клиент и он не может сменится с ФЛ, на ЮЛ. Может только уйти один клиент, а придти новый, а могут быть сразу оба. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2021, 12:20 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
mad_nazgul, Спасибо, конечно за уточнение! Хорошо, давай вместо ТИП КЛИЕНТА будет НСИ типа Размер Хрена, а в Клиенты будут только мужики, без женщин! Резмер Хрена может меняться у Клиента со временем, например встал и упал, или с возрастом растёт! НЕ важно всё это! Сегодн ты обратился как ФЛ, а завтра пришел, расторг договор как ФЛ и открыл ИП! И клиент как был Иванов И.И., он так и остался Иванов И.И. Это тотже самый человек! Может его проще назвать тогда Контактом, а не клиентом! И опять же не важно - вопрос в прхитектурной реализации )) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2021, 12:30 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
НиколайСН ... НЕ важно всё это! Сегодн ты обратился как ФЛ, а завтра пришел, расторг договор как ФЛ и открыл ИП! И клиент как был Иванов И.И., он так и остался Иванов И.И. Это тотже самый человек! Может его проще назвать тогда Контактом, а не клиентом! И опять же не важно - вопрос в прхитектурной реализации )) Нет, важно Тот Иванов, который сам себе, один Иванов - он не клиент . Чтобы стать клиентом, он должен получить определенную роль по отношению к сделке . ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2021, 12:46 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
НиколайСННу и вопрос: Если у Иванова сменился тип клиента с ФЛ на ЮЛ, как это реализовать? Да очень просто: атрибут "тип клиента" со значением "ФЛ" получает дату разрегистрации ИП, добавляется атрибут "тип клиента" со значением "ЮЛ" и датой начала действия равной регистрации ЮЛ. Это обычный способ работы временнЫх атрибутов. НиколайСНИ опять же не важно - вопрос в прхитектурной реализации )) Вопрос, как я посмотрю, в постановке задачи, которая хромает. Если это один и тот же клиент - напрочь не нужно деление на типы лица. А если "расторг один договор и заключил другой" - то это таки два разных клиента. Хотя, конечно, это зависит от того, что у вас называется "договором", поскольку различие как раз в связи между договорами и клиентами. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2021, 12:53 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
НиколайСН Если у Иванова сменился тип клиента с ФЛ на ЮЛ, как это реализовать? Надуманная проблема из разряда садо-мазо... mad_nazgul Клиент Иванов ФЛ это новый клиент и он не может сменится с ФЛ, на ЮЛ. Может только уйти один клиент, а придти новый, а могут быть сразу оба. +++ - Иванов И.И. не может стать ООО "Рога и копыта" и наоборот - Иванов И.И. если чо, станет Индивидуальным Предпринимателем Ивановым Иваном Ивановичем, сокращенно ИП Иванов И.И. и это совсем не одно и то же... А вот атрибут контактное лицо (руководитель) и контакты у них могут быть или одинаковыми или разными - по желанию самого Иванова... То что вы обозвали якорем - является связующей таблицей и при таком раскладе возникает вопрос о её необходимости вообще... Возможно достаточно в таблице Клиент признака физ/юр лицо ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2021, 14:38 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
НиколайСН mad_nazgul, Спасибо, конечно за уточнение! Хорошо, давай вместо ТИП КЛИЕНТА будет НСИ типа Размер Хрена, а в Клиенты будут только мужики, без женщин! Резмер Хрена может меняться у Клиента со временем, например встал и упал, или с возрастом растёт! НЕ важно всё это! Сегодн ты обратился как ФЛ, а завтра пришел, расторг договор как ФЛ и открыл ИП! И клиент как был Иванов И.И., он так и остался Иванов И.И. Это тотже самый человек! Может его проще назвать тогда Контактом, а не клиентом! И опять же не важно - вопрос в прхитектурной реализации )) Если мы говорим именно о клиентах, то мне больше всего нравится, как здесь сделано: https://globalqss.com/idempiere/6.2_20190709/schemaspy/BusinessPartner/tables/c_bpartner.html Есть одна сущность, которая может быть и клиентом, и поставщиком, и сотрудником. А изменения во времени - чем SCD2 не подходит? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2021, 15:33 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
Спасибо большое всем за ответы. Реализацию историчности атрибутов согласовали через референсы, т.е. таблицу, где будет храниться версионность атрибутов, т.е. по 1 варианту из мною предложенных. причины - инфа будет ежедневная, поэтому проблем с апдейтами/инсертами быть не должно, т.к. не придётся рвать никакие временные отрезки. ПыСы. Зря развели димагогию на слова может/НЕможет. Пример конечно корявый, речь была о реализации архитектурного хранения историчности (версионности) атрибутов. А зациклились на слова Клиент и ФЛ/ЮЛ - безусловно правильно подмечено, за что отдельное спасибо, но это всего-лишь пример - не более. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2021, 16:21 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
НиколайСН ФЛ/ЮЛ - безусловно правильно подмечено, за что отдельное спасибо, но это всего-лишь пример - не более. Нет, это как раз важно - исходя из предметной области обычно и выбирается решение. Ваше решение неправильно. Клиент ФЛ и клиент ИП - это совсем разные клиенты, а не один клиент с разными атрибутами, даже если это один Иванов. Объяснение банальное: вам 100% потребуется делать с клиентами операции, которые обязаны учитывать различие этих клиентов. Например, вам нужно заблокировать ФЛ, но ИП должен работать. Или наоборот. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2021, 21:07 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
Конечно, совсем другое дело, если вам нужно просто учесть ошибки ввода в истории. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2021, 21:09 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
НиколайСН, У вас анкор модель ущербная, засунули end_date хотя: авторUpdate is never allowed in an anchor database Еще по факту Clients_type - статичный справочник аттрибутов. В нем вообще дат не надо. а вот в Clients_X_attr и нужна дата, но одна - start_date. и все. Больше ничего не надо. А вот это всё: авторСделать Clients_X_attr и впендюрить туда Дату начала и дату окончания - не есть верное т.к. прийдётся тогда при каждом изменении любого атрибута пересчитывать всю таблицу, чистый бред. Так как у анкор модели - на КАЖДЫЙ атрибут своя таблица отдельная. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2021, 00:46 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
а еще имхо, у вас там нормальная 3нф модель dwh, с ней и живите, с scd2 и блекджеком. И закопайте уже стюардессу. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2021, 00:47 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
НиколайСН mad_nazgul, Спасибо, конечно за уточнение! Хорошо, давай вместо ТИП КЛИЕНТА будет НСИ типа Размер Хрена, а в Клиенты будут только мужики, без женщин! Резмер Хрена может меняться у Клиента со временем, например встал и упал, или с возрастом растёт! НЕ важно всё это! Сегодн ты обратился как ФЛ, а завтра пришел, расторг договор как ФЛ и открыл ИП! И клиент как был Иванов И.И., он так и остался Иванов И.И. Это тотже самый человек! Может его проще назвать тогда Контактом, а не клиентом! И опять же не важно - вопрос в прхитектурной реализации )) Если у вас клиенты публичного дома, у которых перестаёт стоять периодически, то так и надо делать. Таблица Клиент, таблица Свойства_клиента В таблице Свойства есть поля: ID, ClientID, TypeID, дата начала действия, дата прекращения действия, и ссылка на саму же таблицу для связи между двумя свойствами (nullable поле). Т.о. вы по клиенту можете получить любое свойство по типу, периоду, а также найти свойство, которое отменило прежнее (что заменит и упростит нахождения истории, если это требуется). Легко заметить, что это касается меняющихся свойств одной и той же сущности. Базовые свойства сущности меняться не могут! Физлицо и ИП - это не "один и тот же человек", это два разных лица в юридическом смысле. Как правильно проектировать эту связку? Да очень просто: у вас есть сущность/таблица клиент/контрагент, она ссылается на сущность Лицо. При "смене типа лица" создаётся новое лицо (ИП в данном случае), на которое и начинает ссылаться сущность клиент/контрагент. Если очень сильно надо, то такая связь делается не через поле с ID Лица. А через таблицу связи, в которой есть статус Действительна или нет, ну и возможно период действия. Т.е. один ко многим. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 18:40 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
P.S. Более того. Если у вас извратные случаи, когда вы ведёте дела с одним клиентом в несколько потоков, то в таблице связи ещё можно добавить поле ОснованиеДействияID. Которое будет ссылать на соответствующую сущность (которая уже будет чем-то объясняющим этот бардак). ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 18:46 |
|
Реализация версионности в якорной модели
|
|||
---|---|---|---|
#18+
Спасибо всем за лишнюю демагогию "зачем" и "почему" так или иначе! Ворос стоял "как"! А вот и ответ на вопрос "Как сделать?" 1. Создаётся доп таблица Clients_KTBL из одних "ID" 2. На таблицу Clients вешается триггер instead insert, который записывает все уникальные ключи в таблицу из п.1 3. Далее, делаем FK с Clients на Clients_KTBL и FK с Clients_type на Clients_KTBL В результате, получаем нужную связь и без лишних манипуляций в дальнейшем. Можно еще поставить триггер на удаление из Clients_KTBL лишних IDшников для феншуя) Вроде такой подход используется в реализации Табличных справочников НСИ в платформе Prognoz Platform (ForeSight). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.06.2021, 10:43 |
|
|
Start [/forum/topic.php?fid=32&tid=1539790]: |
0ms |
get settings: |
23ms |
get forum list: |
10ms |
check forum access: |
8ms |
check topic access: |
8ms |
track hit: |
111ms |
get topic data: |
102ms |
get forum data: |
7ms |
get page messages: |
827ms |
get tp. blocked users: |
3ms |
others: | 156ms |
total: | 1255ms |
0 / 0 |