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

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

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

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

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

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

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

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

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

В>>однако при этом заказчик хочет, чтобы была возможность в любой момент времени открыть дату, когда была другая логика, другие таблицы, отчеты и так далее.
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С" предлагаю прекратить. Я думал — ясно все вышеприведенным кодом.