Подскажите пожалуйста, как в СУБД можно решить такую задачу:

Есть некоторые данные {X} (сложные, в нескольких таблицах), на основании этих данных проводятся вычисления, результат которых {Y} записывается в БД. Вычисления могут проводиться в разное время и дополнять множество {Y}. Через некоторое время значения {X} изменяются пользователем. Как определить, что {Y} уже не соответствует исходному набору данных {X}?

С уважением,

ABN69

Michael_N, спасибо за быстрый ответ,

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

С триггерами связываться тоже не очень хочется, поскольку в {X} может быть до 100 тысяч записей, есть ощущение, что тормоза будут ощутимые.

А нет ли других механизмов? Задача, по ощущениям, трудоемкая, где искать эффективное решение (хотя бы теоретически) - непонятно.

А.

LSV, всем большое спасибо, ситуация прояснилась, вопрос снимаю.

А6дуллаh3, спасибо, что поддержали разговор,

Относительно ключей - идея хорошая, но есть ощущение, что с ними будет не очень удобно работать, т.к. в теле функции расчета придется указывать те значения, которые входят в {X}. Кроме того, при большом количестве аргументов (>10**5), время сканирования списка ключей может стать слишком большим.

Более эффективным (при больших Nx) мне представляется подход, основанный на построении некоторой функции проверки НП. Поскольку алгоритм проверки в "наших руках", можно найти несколько простых признаков, по которым можно проверять сложные данные. Например, если есть длинный список элементов, то прежде чем проверять его состав, можно проверить количество элементов в списке или факты добавления-удаления элементов из списка. При N > 10**3 можно получить весьма ощутимое ускорение. В первую очередь следует проверять аргументы, частота изменения которых максимальна (больше вероятность наткнуться на условие нарушения НП), и т.п.

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

С уважением,

А.

Alexey Mugalev,

На сегодня у нас примерно так и сделано. Каждый входной параметр имеет временную метку (tx), и если она окажется больше временной метки результата (ty) - значит НП нарушена.

Для определения подмножества, образующего ИД задачи на текущий момент времени, формируется специальный запрос (аналог запроса, формируемого при вычислениях), сравниваются временные метки X-параметров с временной меткой результата. При обнаружении данных с tx > ty результаты расчета сбрасываются.

Если юзеру они опять потребуются, он сам запускает расчет (реально, расчет может длиться сутками, прерываться и продолжаться многократно, возможен просмотр промежуточных результатов). Проверка возможных изменений, произошедших без контроля приложения, производится при загрузке объекта в память и затем контролируется "на лету".

Этот вариант всех устраивал, до тех пор пока не возникла необходимость существенно усложнить структуру ИД и увеличить их объем. Теперь задумались над возможными путями оптимизации, поскольку есть опасения, что время проверки НП будет слишком большим.

Устав от долгих раздумий, и отчаившись найти простое и эффективное решение, у нас возникли сомнения относительно правильности постановки задачи. М.б. и не надо контролировать НП?

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

Обычно, при анализе результатов расчета у пользователя возникает желание что-то изменить в объекте, а у него на экране вчерашняя версия, у которой вместо колес гусеницы...:-). Да и какая польза от вчерашних результатов - только если захочется что-то приятное вспомнить...:-).

Так что, поиски решения пока продолжаются, видимо, нарушать законы проектирования БД и платить за это контролем НП, все таки придется, вопрос - как?

ЗЫ: Мне кажется, аналогичная ситуация возникает при генерации отчетов. Они же формируются на данный момент времени, и, ЕСНО, могут устаревать. Но вряд ли кому то придет в голову проверять актуальность отчета сравнением состояний БД - проще сгенерировать новый. В конце концов, можно сравнить результаты отчетов.

А6дуллаh3,

Огромное спасибо за подсказку, буду изучать,