|
|
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
Собственно, пока вижу решение на основе исторических записей (копий) и сохранении периодов актуальности. Стоит ли бросаться "в омут" с таким решением, или у кого-то есть ещё предложения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 21:27 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
Вспомнил такое в 1с версия 7.7 В справочниках у реквизитов есть свойство Периодический, у системы есть свойство РабочаяДата. Можно выбрать любую дату и заполнять или смотреть информацию на эту дату. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 21:57 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
hVostt Стоит ли бросаться "в омут" с таким решением, или у кого-то есть ещё предложения? Вам надо будет принять несколько решений основываясь на 1 Это доделка существующей (смотрящей в настоящее) системы или сразу новая разработка 2 Как часто будут запросы в прошлое. Насколько критична производительность по сравнению с запросами "на настоящее время". 3 Какой объем устаревших версий строк по сравнению с общим объемом данных? Решения которые надо принять - 1 хранить версии в той же таблице myTable (проще и быстрее) или в другой myTable_hist (нет влияния на запросы к "живым данным", все ключи/ограничения работают, но выборка исторических данных сложнее и медленнее) 2 использовать две даты d_from default(до начала времен), d_to default(конец времен) или одну дату d_change (надежнее, но медленнее выборки) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 22:25 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
SERG1257, Спасибо за подробный ответ. Это не доделка. Есть работающая версия 1 (но без ретроспективы). Надо делать версию 2 практически с нуля, но с оглядкой на 1 (т.е. бизнес-процессы, данные -- те же). Путешествия в прошлое планируются не частые, производительность в режиме ретроспективы не критична (т.е. некоторые просадки можно вполне обосновать). Т.е. это не часть бизнес-процесса, это лишь возможность быстрей разобраться при каких-то проблемах и по-ностальгировать начальству. Объём устаревших версий большой, наверное надо будет предусмотреть чистку, или сжатие (т.е. частые изменения со временем надо будет упаковывать в большие, пока даже не знаю как мы это будем делать). Придётся хранить версии в отдельных таблицах, так как к "живым" данным по перфомансу предъявляются высокие требования. Да, две даты, надёжность обеспечивается слоем доступа к данным. Что ж, будем делать. Спасибо за просвещение! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 23:40 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
hVosttПридётся хранить версии в отдельных таблицах, так как к "живым" данным по перфомансу предъявляются высокие требования. Одно с другим связано слабо. Архивную аналитику выносят в отдельную базу по другим причинам. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2014, 23:46 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
hVostt Да, две даты, надёжность обеспечивается слоем доступа к данным. Добавьте в расписание запрос на предмет поиска строк у которых дата конца не совпадает с датой начала при том же ай-ди. В нормальных условиях запрос не должен возвращать данные, ну а если кто накосячил то отловите вы, а не пользователь. Я к тому что верить никому нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 00:11 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovОдно с другим связано слабо. Архивную аналитику выносят в отдельную базу по другим причинам. Предлагаете хранить историю в одной таблице? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 00:26 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
SERG1257Добавьте в расписание запрос на предмет поиска строк у которых дата конца не совпадает с датой начала при том же ай-ди. В нормальных условиях запрос не должен возвращать данные, ну а если кто накосячил то отловите вы, а не пользователь. Я к тому что верить никому нельзя. Благодарю за совет! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 00:29 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
> Путешествия в прошлое планируются не частые, производительность в режиме ретроспективы не критична Тогда вы фигней занимаетесь. Держите нужное количество архивных копий, это будет на порядки дешевле редизайна и поддержки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 00:43 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Тогда вы фигней занимаетесь. Держите нужное количество архивных копий, это будет на порядки дешевле редизайна и поддержки. Заглянув в хрустальный шар, предположу что hVostt - разработчик и проблему решает как разработчик. когда в руках молоток, все проблемы выглядят как гвозди. (с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 01:23 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
> проблему решает как разработчик Так я и пишу для того, чтобы люди не ходили по граблям. Это наиболее серьёзная задача из всех, когда-либо здесь обсуждавшихся. Более того, о решениях промышленного качества я не слышал и не читал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 02:01 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
hVosttТакже, если программа логгирует просмотры, она должна перестать это делать. Эт-то почему же? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 05:18 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
guest_20040621> проблему решает как разработчик Так я и пишу для того, чтобы люди не ходили по граблям. Это наиболее серьёзная задача из всех, когда-либо здесь обсуждавшихся. Более того, о решениях промышленного качества я не слышал и не читал . А вы не потрудитесь вкратце сформулировать своё видение проблемы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 07:18 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
Вопрос сформулирован некорректно. Все элементы в БД в любой момент времени должны находиться в согласованном состоянии. Так что в общем случае при ведении истории для ВСЕЙ БД нужно при любом изменении любой сущности делать копию всех остальных связанных сущностей. Соответственно, решение ужасно затратное как по дисковому пространству, так и по производительности. Для начала, чем не устраивает решение иметь таблицу истории для каждой сущности отдельно и делать, как уже упоминалось выше по топику, на каждый делете/апдейт копирование удаленных записей в триггере в историческую таблицу? В принципе, это решение позволит иметь снепшот данных на любой время: нужно просто выбирать из исторических таблиц самые близкие записи к указанному времени, а если их нет - брать значения из актуальных таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 10:46 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
вы посмотрите как реализован механизм Capture Data Source (СDS) в MS SQL 2008 и позднее. там именно история изменений значений атрибутов. заводиться альтернативная таблица и заполняется значениями полей таблицы с историей. что-то можно попробовать сделать на их архитектуре - там здоровенная система наворочена ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:09 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
Arm79Для начала, чем не устраивает решение иметь таблицу истории для каждой сущности отдельно и делать, как уже упоминалось выше по топику, на каждый делете/апдейт копирование удаленных записей в триггере в историческую таблицу? В принципе, это решение позволит иметь снепшот данных на любой время: нужно просто выбирать из исторических таблиц самые близкие записи к указанному времени, а если их нет - брать значения из актуальных таблиц. Это означает, грубо говоря, держать две копии всех запросов - "с историческими таблицами" и "без исторических таблиц", поскольку вариативность во FROM поддерживается достаточно плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:14 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
hVosttИнтересует, доводилось ли кому-нибудь проектировать базу данных таким образом, чтобы в программе можно было выбрать дату и посмотреть полное состояние всей системы на это время без артефактов, естественно без возможностей изменения данных? Как будто был произведён откат, но без использования отката, т.е. на уровне данных. При чём в режиме "исторического просмотра" должны полноценно работать все функции системы (просмотр, фильтрация, сортировки и т.д.), кроме создания/изменения данных. доводилось, даже с изменением, ничего сложного, но объем базы больше и запросы надо оптимизировать получше, да и гемора больше суть: * помимо основной таблицы сущности, нужна еще таблица исторических сведений, либо одна таблица и для каждой сущности сквозной ИД + ИД редакции + дата актуальности * с датой актуальности несколько вариантов, гугль подскажет подробное описание, там есть плюсы и минусы у каждого * связи идут по сквозному ИД, а конкретная редакция сведений достается по результатам расчета текущей даты актуальности -вот тут и требуется оптимизация запросов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:15 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинArm79Для начала, чем не устраивает решение иметь таблицу истории для каждой сущности отдельно и делать, как уже упоминалось выше по топику, на каждый делете/апдейт копирование удаленных записей в триггере в историческую таблицу? В принципе, это решение позволит иметь снепшот данных на любой время: нужно просто выбирать из исторических таблиц самые близкие записи к указанному времени, а если их нет - брать значения из актуальных таблиц. Это означает, грубо говоря, держать две копии всех запросов - "с историческими таблицами" и "без исторических таблиц", поскольку вариативность во FROM поддерживается достаточно плохо. Да ну, не все так плохо. select top 1 from (select from history union select from source) t where t.last_update >= @date order by date desc ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:23 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
Я помню, что в книге http://www.ozon.ru/context/detail/id/2808650/ в одной из последних глав рассматривается теория - как спроектировать БД с возможностью ретроспективы и есть примеры на Cache. Почитайте, если найдете, может, увидите что-то для себя полезное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:23 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
Arm79Кот Матроскинпропущено... Это означает, грубо говоря, держать две копии всех запросов - "с историческими таблицами" и "без исторических таблиц", поскольку вариативность во FROM поддерживается достаточно плохо. Да ну, не все так плохо. select top 1 from (select from history union select from source) t where t.last_update >= @date order by date desc Смысл тогда разделять на 2 таблицы, если в каждом запросе делать union? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:36 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
Почему все говорят только о данных? В БД куча других объектов, в том числе и реализующих прикладную логику. Иногда при доработках вообще меняются алгоритмы расчета тех или иных величин, то есть на одних и тех же исходных данных, лежащих в таблице вчера выдавалось одно расчитываемое значение, а сегодня выдаётся другое. То есть кроме ретроспективного хранения данных придется еще хранить все изменения КОДА базы данных, реализующего бизнес логику. Включая ошибки, да. Ибо какая-то ошибка в коде могла приводить к совершенно другим результатам каких-то расчетов. Вы же хотите увидеть именно те результаты, которые видели вчера? А не те, которые отображаются сегодня после исправления этой ошибки? Это касается не только уровня пакетов в БД. Это же касается и самой БД, ибо сама СУБД тоже дорабатывается и при очередных релизах бывает меняется какое-то поведение. А еще логика бывает не только в БД зашита, а еще и в клиентском ПО, то есть надо еще и клиентское ПО брать соответствующей версии, чтобы увидеть в точности то, что вывидели "вчера". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:47 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Путешествия в прошлое планируются не частые, производительность в режиме ретроспективы не критична Тогда вы фигней занимаетесь. Держите нужное количество архивных копий, это будет на порядки дешевле редизайна и поддержки. Ну хорошо, давайте рассмотрим такой вариант. В приложении есть кнопка "Ретроспектива". Как решить задачу по нажатию на кнопку? Где-то в подвале загорается красная лампочка и бригада админов начинает интенсивно шевелиться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:48 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
SERG1257Заглянув в хрустальный шар, предположу что hVostt - разработчик и проблему решает как разработчик. когда в руках молоток, все проблемы выглядят как гвозди. (с) Именно. А как ещё можно решать эту задачу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:50 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
АнатоЛойhVosttТакже, если программа логгирует просмотры, она должна перестать это делать. Эт-то почему же? :) Нет нужды для ретроспективы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:53 |
|
||
|
Путешествия в прошлое
|
|||
|---|---|---|---|
|
#18+
Arm79Вопрос сформулирован некорректно. Все элементы в БД в любой момент времени должны находиться в согласованном состоянии. Так что в общем случае при ведении истории для ВСЕЙ БД нужно при любом изменении любой сущности делать копию всех остальных связанных сущностей. Соответственно, решение ужасно затратное как по дисковому пространству, так и по производительности. Для начала, чем не устраивает решение иметь таблицу истории для каждой сущности отдельно и делать, как уже упоминалось выше по топику, на каждый делете/апдейт копирование удаленных записей в триггере в историческую таблицу? В принципе, это решение позволит иметь снепшот данных на любой время: нужно просто выбирать из исторических таблиц самые близкие записи к указанному времени, а если их нет - брать значения из актуальных таблиц . Сами себе противоречите, - если ничего не менялось, нафига копировать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2014, 11:53 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=38751342&tid=1540795]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
70ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 406ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
