Есть система БД — клиент.

И БД (таблицы, код) и клиент могут быть подвержены изменениям (очень существенным), однако при этом заказчик хочет, чтобы была возможность в любой момент времени открыть дату, когда была другая логика, другие таблицы, отчеты и так далее.

Как такие системы организованы?

Первое, что приходит в голову, делать разные версии системы. Но это
а) Убиство с поддержкой всех этих версий
б) невозможность просмотра данных из разных версий одновременно.

Что посоветуете?

Здравствуйте, Ватакуси, Вы писали:

В>И БД (таблицы, код) и клиент могут быть подвержены изменениям (очень существенным),
Это во всех системах (живых).

В>однако при этом заказчик хочет, чтобы была возможность в любой момент времени открыть дату, когда была другая логика, другие таблицы, отчеты и так далее.
Чем обосновано это требование (с примерами из жизни)?

В>Как такие системы организованы?
С таким экстремальным вариантом до сих пор не встречался. Но обычно существует такое понятие, как обратная совместимость. В той или иной степени.

В>>однако при этом заказчик хочет, чтобы была возможность в любой момент времени открыть дату, когда была другая логика, другие таблицы, отчеты и так далее.
W>Чем обосновано это требование (с примерами из жизни)?
Что бы данные полученные 16.12.2005 на 16.12.2005 с существующей логикой работы были такими же и 16.12.2020 на 16.12.2005, когда логика, структура базы данных и даже отчеты будут сильно отличаться от того, что было 15 лет назад. Более того, заказчику хочется, чтобы данные были не в режиме "только для чтения", а с возможностью редактирования, причем редактирования на ту дату, на которую ведеться инспекция.

В>>Как такие системы организованы?
W>С таким экстремальным вариантом до сих пор не встречался. Но обычно существует такое понятие, как обратная совместимость. В той или иной степени.
Это не обратная совместимость в прямом смысле этого слова. Данные из 16.12.2020 не нужно тащить в 16.12.2005, а вот наоборот возможно (хотя в данном случае это не столь важно). Нужно иметь возможность как бы открыть систему с логикой работой, структурой базы данных, кодом клиента и прочими прибамбасами, которая была когда-то...

Я и сам такого не встречал, однако нужно вот.

Здравствуйте, Ватакуси, Вы писали:

В>Есть система БД — клиент.

В>И БД (таблицы, код) и клиент могут быть подвержены изменениям (очень существенным), однако при этом заказчик хочет, чтобы была возможность в любой момент времени открыть дату, когда была другая логика, другие таблицы, отчеты и так далее.

Не знаю насколько Вы располагаете временем и желанием делать все самому, но если таковое имеется то есть несколько соображений. Думаю, что нечто подобное можно реализовать, но это потребует создания дополнительного инструментария.
Идея — хранить в целевой базе данных не сущности предметной области, а их описания. Любая сущность в базе данных представлена набором своих атрибутов, а значит можно хранить и оперировать не целыми сущностями, а наборами атрибутов.
Другими словами в базе данных будет примерно такой набор базовых сущностей(т.е. таблиц): «сущность», «атрибут», «значение атрибута сущности».
Далее, в отдельной таблице нужно будет хранить алгоритмы, которые осуществляют сборку всех атрибутов в единую сущность, с которой и будет работать приложение. Здесь же хранить историю изменения представления сущности, т.е. с такого-то числа сущность собирается по такому-то правилу из таких-то атрибутов, с другого числа — из других атрибутов с другими правилами сборки.
Если это реализовать, то в небольшом количестве исходных таблиц можно будет единоообразно хранить(и обрабатывать) все сущности с которыми работает и будет работать система: т.е. собственно сущности предметной области + отчеты, структура и алгоритмы получения наборов данных, их формирующих, с учетом истории изменения + клиент и его изменения.
Фуух. Вышло несколько сумбурно, надеюсь что-то будет полезным.

Здравствуйте, Ватакуси, Вы писали:

В>Есть система БД — клиент.

В>И БД (таблицы, код) и клиент могут быть подвержены изменениям (очень существенным), однако при этом заказчик хочет, чтобы была возможность в любой момент времени открыть дату, когда была другая логика, другие таблицы, отчеты и так далее.

В>Как такие системы организованы?

В>Первое, что приходит в голову, делать разные версии системы. Но это
В>а) Убиство с поддержкой всех этих версий
В>б) невозможность просмотра данных из разных версий одновременно.

В>Что посоветуете?

В свое время Никита Хрущев, будучи генеральным секретарем, предложил создать конструкторам (на полном серьезе) самолет-катер-подводную лодку. От самолета удалось отговорить, но катер, который мог ненадолго погружаться на небольшую глубину под воду все-таки появился. Дальше экспериментальных образцов дело не пошло.

S>Не знаю насколько Вы располагаете временем и желанием делать все самому, но если таковое имеется то есть несколько соображений. Думаю, что нечто подобное можно реализовать, но это потребует создания дополнительного инструментария.
S>Идея — хранить в целевой базе данных не сущности предметной области, а их описания. Любая сущность в базе данных представлена набором своих атрибутов, а значит можно хранить и оперировать не целыми сущностями, а наборами атрибутов.
S>Другими словами в базе данных будет примерно такой набор базовых сущностей(т.е. таблиц): «сущность», «атрибут», «значение атрибута сущности».
S>Далее, в отдельной таблице нужно будет хранить алгоритмы, которые осуществляют сборку всех атрибутов в единую сущность, с которой и будет работать приложение. Здесь же хранить историю изменения представления сущности, т.е. с такого-то числа сущность собирается по такому-то правилу из таких-то атрибутов, с другого числа — из других атрибутов с другими правилами сборки.
S>Если это реализовать, то в небольшом количестве исходных таблиц можно будет единоообразно хранить(и обрабатывать) все сущности с которыми работает и будет работать система: т.е. собственно сущности предметной области + отчеты, структура и алгоритмы получения наборов данных, их формирующих, с учетом истории изменения + клиент и его изменения.
S>Фуух. Вышло несколько сумбурно, надеюсь что-то будет полезным.
Интересная идея. Видимо не только мне в голову пришла , я только надеялся, что есть что-то попроще .

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

___>В свое время Никита Хрущев, будучи генеральным секретарем, предложил создать конструкторам (на полном серьезе) самолет-катер-подводную лодку. От самолета удалось отговорить, но катер, который мог ненадолго погружаться на небольшую глубину под воду все-таки появился. Дальше экспериментальных образцов дело не пошло.
Юмор понятен , а вот если серьезно, то, например в 1С или там в каком-нить Гаранте, когда меняется законодательство (а оно за последние лет 10 поменялось существенно в некоторых местах), то как обеспечивается возможность работы с данными, когда было другое законадательство?

Здравствуйте Ватакуси, Вы писали :
> Юмор понятен , а вот если серьезно, то, например в 1С или там в
> каком-нить Гаранте, когда меняется законодательство (а оно за последние
> лет 10 поменялось существенно в некоторых местах), то как обеспечивается
> возможность работы с данными, когда было другое законадательство?

Никак.
Если серьезно, то вся бизнес логика отдельного модуля не
перерабатывается и никуда не исчезает. Просто пишется отдельный модуль и
все новые документы/отчеты/шаблонами реализуются через него. Все старое
остается с теми же формами/документами/диалогами/шаблонами и пр. сранью.

Здравствуйте, Ватакуси, Вы писали:

В>Интересная идея. Видимо не только мне в голову пришла , я только надеялся, что есть что-то попроще .

Конечно же, возможно есть что-то и попроще, но эта и эта идея мне нравится своими потенциальными возможностями.

В>Наверное с БД можно справиться (хотя тут встанет вопрос производительности, ведь это, по-сути, абстракция над данными и логикой — еще один уровень),

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

В> а вот как быть с клиентом, где отчеты генерируются? Данные, он положим с сервера получит какие надо, а структура отчетов, оформление и прочие прибамбасы?

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

Здравствуйте, Ватакуси, Вы писали:

В>Что посоветуете?

Машину времени — судя по всему, она точно подходит под описание задачи. Успехов ...

Здравствуйте, Ромашка, Вы писали:

Р>Здравствуйте Ватакуси, Вы писали :
>> Юмор понятен , а вот если серьезно, то, например в 1С или там в
>> каком-нить Гаранте, когда меняется законодательство (а оно за последние
>> лет 10 поменялось существенно в некоторых местах), то как обеспечивается
>> возможность работы с данными, когда было другое законадательство?

Р>Никак.
Р>Если серьезно, то вся бизнес логика отдельного модуля не
Р>перерабатывается и никуда не исчезает. Просто пишется отдельный модуль и
Р>все новые документы/отчеты/шаблонами реализуются через него. Все старое
Р>остается с теми же формами/документами/диалогами/шаблонами и пр. сранью.
Т.е. фактически пишеться новая система, особенно, если изменения — масштабны?

S>Главное проработать этот промежуточный уровень до приемлемого уровня абстракции и производительности, имхо, остальное — уже дело техники.
А не знаете каках либо примеров подобных систем? Хотелось бы посмотреть, как люди делают подобное.

Здравствуйте, Ватакуси, Вы писали:

___>>В свое время Никита Хрущев, будучи генеральным секретарем, предложил создать конструкторам (на полном серьезе) самолет-катер-подводную лодку. От самолета удалось отговорить, но катер, который мог ненадолго погружаться на небольшую глубину под воду все-таки появился. Дальше экспериментальных образцов дело не пошло.
В>Юмор понятен , а вот если серьезно, то, например в 1С или там в каком-нить Гаранте, когда меняется законодательство (а оно за последние лет 10 поменялось существенно в некоторых местах), то как обеспечивается возможность работы с данными, когда было другое законадательство?

Ну, 1С, у нас просто пример для подражания. Что-то вроде этого:

if Дата < XXXX
    старая логика
else
    новая логика

А в курсе, что помимо компании "Первый Сорт" (т.е. 1С) существует еще и компания "Высший сорт"

___>Ну, 1С, у нас просто пример для подражания. Что-то вроде этого:
___>

___>if Дата < XXXX
___>    старая логика
___>else
___>    новая логика
___>

А БД тоже хранится, т.е. каждый раз содается новая БД и диспетчер потом разруливает запросы?

Здравствуйте Ватакуси, Вы писали :
> Т.е. фактически пишеться новая система, особенно, если изменения —
> масштабны?

А вы пишете сферического коня в вакууме???
Конкретизируй что за система и что ты понимаешь под масштабными
изменениями. Революции???

Вообщем-то согласен.
У самого подобная задача стоит.
Пока додумался до того, что бы всё базу опписать функциями и view'хами.
У каждого обьекта есть три дейсвия (у меня): покупка, использование, продажа.

Дело в том, что цена у меня зависит от очень многих факторов, и не для каждого товара алгоритм одинаковый.

Пока придумал вот, что:
при создания товара, писать три функции, возвращающие мне нужные результаты.

Здравствуйте, Ромашка, Вы писали:

Р>Здравствуйте Ватакуси, Вы писали :
>> Т.е. фактически пишеться новая система, особенно, если изменения —
>> масштабны?

Р>Конкретизируй что за система и что ты понимаешь под масштабными
Р>изменениями. Революции???
Например, появилось 10 новых таблиц и 20 старых поменяли свою структуру, удалилиь столбцы, поменялись типы, поменялись ключи, связи, ограничения, триггеры.
Не революция возможно, но очень сильная эволюция.

Здравствуйте Ватакуси, Вы писали :
> Р>Конкретизируй что за система и что ты понимаешь под масштабными
> Р>изменениями. Революции???
> Например, появилось 10 новых таблиц и 20 старых поменяли свою структуру,
> удалилиь столбцы, поменялись типы, поменялись ключи, связи, ограничения,
> триггеры.

Вот это и есть сферический конь в вакууме. Что в реальности может
повлечь такие изменения???? Высадка марсиан? Хотя нет, знаю...

> Не революция возможно, но очень сильная эволюция.

Толкьо добавлять. Ничего не менять, ничего не удалять. Фуркционал
переключать на новые данные. Старые подтягивать вьюхами.

Здравствуйте Darkman_VLT, Вы писали :
> У самого подобная задача стоит.
> Пока додумался до того, что бы всё базу опписать функциями и view'хами.
> У каждого обьекта есть три дейсвия (у меня): покупка, использование,
> продажа.
>
> Дело в том, что цена у меня зависит от очень многих факторов, и не для
> каждого товара алгоритм одинаковый.

Определять цену на уровне БД???? Бррррр.....

Здравствуйте, Ватакуси, Вы писали:

___>>Ну, 1С, у нас просто пример для подражания. Что-то вроде этого:
___>>

___>>if Дата < XXXX
___>>    старая логика
___>>else
___>>    новая логика
___>>

В>А БД тоже хранится, т.е. каждый раз содается новая БД и диспетчер потом разруливает запросы?

Какой диспетчер в 1С??? Какие запросы??? Ветку дискусии по теме "а как это сделано в 1С" предлагаю прекратить. Я думал — ясно все вышеприведенным кодом.

Здравствуйте _d_m_, Вы писали :
> Какой диспетчер в 1С??? Какие запросы??? Ветку дискусии по теме "а как
> это сделано в 1С" предлагаю прекратить. Я думал — ясно все
> вышеприведенным кодом.

Ууууу... Это вы промышленных решений на 1С не видели. Со сторед
процедурами и триггерами отхинтоваными по самое нехочу...

ЗЫ. Я знаю что в 1С так делать нехорошо, более того неправильно, но по
другому ОНО не работает.

Здравствуйте, Ватакуси, Вы писали:

В>Есть система БД — клиент.

В>И БД (таблицы, код) и клиент могут быть подвержены изменениям (очень существенным), однако при этом заказчик хочет, чтобы была возможность в любой момент времени открыть дату, когда была другая логика, другие таблицы, отчеты и так далее.

В>Как такие системы организованы?

В>Первое, что приходит в голову, делать разные версии системы. Но это
В>а) Убиство с поддержкой всех этих версий
В>б) невозможность просмотра данных из разных версий одновременно.

В>Что посоветуете?

Сложно что-либо советовать, т.к. слишком мало информации.
Тем не менее, некоторые соображения всё же есть.

Как практически у любой проблемы, в этой задаче есть две стороны:

1. Психологическая
   
2. Техническая

С психологической точки зрения Вам стоит попробовать переубедить заказчика. Только представте себе, что в зависимости от даты ему постоянно придётся работать с разными системами. Если их 2-3 — это терпимо. Но думаю с пятью работать будет просто невозможно. Попытайтесь нарисовать "реальную" картину будущего, которое ждёт пользователя. Возможно это поможет.

С технической точки зрения обычно стараются "перетаскивать"/импортировать данные старой версии программы в новую версию так, чтобы со старыми данными можно было работать так же, как с новыми.

Повторюсь, слишком мало информации, чтобы советовать что-то конкретное. Возможно для Вашей задачи требования заказчика вполне оправданы.

Здравствуйте, Ватакуси, Вы писали:

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

Это уже больше похоже на революцию. Такую систему пракитически невозможно будет поддерживать. Единственно правильным решением тут будет некий промежуточный слой в базе данных, позволяющий хранить историю изменений и настраивать структуру базы в зависимости от даты. Ранее здесь вам уже предлагали подобный вариант. Основная идея в том чтобы спроектировать в действительности не меняющуюся структуру данных (здесь не имеется ввиду вообще, естесственно в результате разработки придется вносить коррективы), которая будет содержать описание вашей структуры в самих данных. Ну а для того чтобы легче с этим чудом было работать, использовать view, materialized view, stored procedures и так далее. Тоже самое и в клиенте, выбор логики есть функция от даты, логика работы меняется не так уж и часто. Лично я бы здесь применил следующую технику: постараться выделить общий интерфейс работы системы (если таковое сделать невозможно, то об одной единственной системе не может быть и речи), если логика работы меняется очень сильно, то уместно использовать паттерн фабрика и каждый раз для логики реализовывать новый модуль (как уже предлагали ранее if (date < Date1) loadModule("businessLogicOld") else loadModule("businessLogicNew")). Если логика меняется незначительно, можно попробовать паттерн фасад, т.е есть модуль с набором некоторых функций, как новых так и старых и есть модуль (фасад) который реализует интерфейс системы в зависимости от даты и сам выбирает какую функцию использовать в данный момент.

Здравствуйте, Ромашка, Вы писали:

Р>Здравствуйте Darkman_VLT, Вы писали :
>> У самого подобная задача стоит.
>> Пока додумался до того, что бы всё базу опписать функциями и view'хами.
>> У каждого обьекта есть три дейсвия (у меня): покупка, использование,
>> продажа.
>>
>> Дело в том, что цена у меня зависит от очень многих факторов, и не для
>> каждого товара алгоритм одинаковый.

Р>Определять цену на уровне БД???? Бррррр.....
А какая разница где это делать?
SQL запросы пусть в базе лежат, а клиентский софт пусть только функу вызывает.
Вслучаи если изменится формирование цены — клиентский софт переписывать не нужно будет

Здравствуйте, Ватакуси, Вы писали:
В>Что посоветуете?
Погуглить на тему Temporal databases.
Научная мысль уже долетала до этих вершин, и некоторые результаты были получены. Я не в курсе статуса этих результатов. В мое поле зрения не попадало никаких коммерческих реализаций, что вовсе не означает их отсутствия.

Здравствуйте, Darkman_VLT, Вы писали:
Р>>Определять цену на уровне БД???? Бррррр.....
D_V>А какая разница где это делать?
D_V>SQL запросы пусть в базе лежат, а клиентский софт пусть только функу вызывает.
D_V>Вслучаи если изменится формирование цены — клиентский софт переписывать не нужно будет

Очень может оказаться так, что в недостаточно отдаленном будущем развитие такой логики существенно напряжет СУБД. Прогрессивное человечество предпочитает применять в таких случаях сервера приложений. Они как раз позволяют не переписывать клиента при изменении алгоритмов формирования цены.

У вас неизбежно должны оставать и старая логика и страя систематика данных где-то.
чтобы быть применимым,
организация может быть разной.

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

"полиморфизм",
если изменения "во всем" а не только работе с данными,
то интерфейс делаете более общего вида.

загружаете нужный модуль обработки согласно версии — и все.

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

а обработчик конкретных версий иерархии написан как вверху.

______________________

Но такое описание данных хорошо, но есть недостаток- скорость на больших обьемах не вполне хорошая.

Поэтому если у вас высокие требования к скорости на данных —
создавайте каждый раз новую версию таблиц, в новой базе,
не убирая старых- раз эти данные нужны.

Это более громоздко, но скорость требует жертв.

______________________

Еще небольшой под-вариант хранения данных в таблицах:
используйте Object-relational mapper,
когда вы пишете только логику,
а как она хранится в новом варианте базы — вам писать не надо каждый раз.
но версии проверять надо все равно.