Здравствуйте _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,
когда вы пишете только логику,
а как она хранится в новом варианте базы — вам писать не надо каждый раз.
но версии проверять надо все равно.