Прошу помощи, т.к. нервы уже на пределе, пол инета обрыл, но везде одно и тоже из банальных вещей.
Есть таблица 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-ий вариант более удобный и правильный!

За схему и подсказку буду очень признателен!

mad_nazgul,

Спасибо, конечно за уточнение!
Хорошо, давай вместо ТИП КЛИЕНТА будет НСИ типа Размер Хрена, а в Клиенты будут только мужики, без женщин!
Резмер Хрена может меняться у Клиента со временем, например встал и упал, или с возрастом растёт!

НЕ важно всё это!

Сегодн ты обратился как ФЛ, а завтра пришел, расторг договор как ФЛ и открыл ИП! И клиент как был Иванов И.И., он так и остался Иванов И.И. Это тотже самый человек! Может его проще назвать тогда Контактом, а не клиентом! И опять же не важно - вопрос в прхитектурной реализации ))

Спасибо большое всем за ответы.

Реализацию историчности атрибутов согласовали через референсы, т.е. таблицу, где будет храниться версионность атрибутов, т.е. по 1 варианту из мною предложенных.
причины - инфа будет ежедневная, поэтому проблем с апдейтами/инсертами быть не должно, т.к. не придётся рвать никакие временные отрезки.

ПыСы. Зря развели димагогию на слова может/НЕможет.
Пример конечно корявый, речь была о реализации архитектурного хранения историчности (версионности) атрибутов. А зациклились на слова Клиент и ФЛ/ЮЛ - безусловно правильно подмечено, за что отдельное спасибо, но это всего-лишь пример - не более.

Спасибо всем за лишнюю демагогию "зачем" и "почему" так или иначе!
Ворос стоял "как"!
А вот и ответ на вопрос "Как сделать?"
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).