Arm79Вопрос сформулирован некорректно. Все элементы в БД в любой момент времени должны находиться в согласованном состоянии. Так что в общем случае при ведении истории для ВСЕЙ БД нужно при любом изменении любой сущности делать копию всех остальных связанных сущностей. Соответственно, решение ужасно затратное как по дисковому пространству, так и по производительности.

Как раз не вижу причин делать копию всех связанных сущностей. Достаточно иметь прозрачный идентификатор.

Arm79Для начала, чем не устраивает решение иметь таблицу истории для каждой сущности отдельно и делать, как уже упоминалось выше по топику, на каждый делете/апдейт копирование удаленных записей в триггере в историческую таблицу?

Исключено. Все операции с данными производятся на стороне приложения в слое доступа к данным.

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

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

17-77* связи идут по сквозному ИД, а конкретная редакция сведений достается по результатам расчета текущей даты актуальности -вот тут и требуется оптимизация запросов

Если есть пара дат, то запрос достаточно тривиальный.

EvLaUyЯ помню, что в книге http://www.ozon.ru/context/detail/id/2808650/ в одной из последних глав рассматривается теория - как спроектировать БД с возможностью ретроспективы и есть примеры на Cache. Почитайте, если найдете, может, увидите что-то для себя полезное.

Спасибо за наводку, гляну.

anvanoВ БД куча других объектов, в том числе и реализующих прикладную логику.

За прикладную логику в БД у нас бьют по рукам. Обоснование должно быть такое, что по-другому просто ну никак. Пока таких случаев не было.

anvanoИногда при доработках вообще меняются алгоритмы расчета тех или иных величин, то есть на одних и тех же исходных данных, лежащих в таблице вчера выдавалось одно расчитываемое значение, а сегодня выдаётся другое.

Поэтому алгоритмы расчётов не меняются, а создаются новые.

anvanoТо есть кроме ретроспективного хранения данных придется еще хранить все изменения КОДА базы данных, реализующего бизнес логику. Включая ошибки, да. Ибо какая-то ошибка в коде могла приводить к совершенно другим результатам каких-то расчетов. Вы же хотите увидеть именно те результаты, которые видели вчера? А не те, которые отображаются сегодня после исправления этой ошибки?

База данных хранит данные, поэтому ретроспектива касается только хранения данных. Гораздо большая проблема в миграциях при возникающих доработках, это может сломать всю ретроспективу.

anvanoА еще логика бывает не только в БД зашита, а еще и в клиентском ПО, то есть надо еще и клиентское ПО брать соответствующей версии, чтобы увидеть в точности то, что вывидели "вчера".

Логика в БД -- моветон. На счёт версий согласен. С ретроспективой дальнейшая разработка может сильно усложнится. Может в конце концов придётся отказаться от этой затеи, но надо получить соответствующий опыт. По крайне мере это всё оплачивается

prog123hVostt,

Вы про область применения ничего не сказали. Допустим есть абсолютно полная история абсолютно всего, - что дальше?!

Область применения чего? Если интересно что это за приложение, это довольно таки сложный CRM. Просмотр ретроспективы нужен клиенту. Эту функциональность УЖЕ продали за большие деньги. Теперь надо делать

17-77это один из способов организации даты актуальности, но его минус в том, что надо всегда находит предыдущую запись и закрывать в ней конечную дату актуальности - следовательно при массированной вставке записей будет работать медленней

Массивные операции с данными исключены. С системой работают только люди. Если в компанию наберут толпу китайцев, которые будут колбасить в режиме Batch, тогда это означает, что компания много работает, ещё больше зарабатывает, можно и серверов воткнуть.

Arm79Увы, не исключено. По опыту - если нужна высокая скорость работы с БД, то логика должна быть в БД. Тяжелые ORM только замедляют работу, хотя дают удобство. Как минимум, устраняются затраты на пересылку данных по сети.

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

17-77мой вариант подходит под это: репозиторий, метод сохранения например, туда передается экземпляр сущности с новыми данными - метод ищет предыдущую запись - закрывает в ней конечную дату актуальности, вставляет новую, одна транзакция, с многопоточностью - надо знать требования и думать

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


17-77ну от этой сложности можно абстрагироваться - выделив ее в отдельный слой, который с одной стороны потребляет БД, а с другой стороны отдает базу как будто она без истории

Вот это было бы идеально, к этому стремимся.

17-77джоины да, станут сложнее, условия по дате актуальности в джоине должны всегда выдавать одну зависимую запись, соответственно, если за день может быть несколько новых редакций - надо с учетом времени, с оптимизациями по скорости - попробовать перевести на int/long тики

Думаете, int/long ощутимо улучшат ситуацию по сравнению с датами?

17-77не уверен что ORM переварит такие запросы самостоятельно и на раз-два-три, надо курить документацию

С ORM как-нибудь справимся :) Чего-то только мы из него не выжимали, в противовес всем заявлениям, что дескать ORM медленный. Это далеко не так.


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

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

prog123Дык у фирмы 1С все свалено в одну большую кучу дерьмища, у них не каждый релиз их же программы свою базу открыть сможет:) , но это не помешало им растиражировать свою программу.

это называется ма́́ркетинг

soulsurferВам нужен встроенный в СУБД Git чтоли?

Ну типа.