История значений реквизита и выбрка из него

[Glazz]

Уважаемые программеры, я начинающий, не хватает опыта, прошу за вопрос не пинать

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

Имеем таблицу вида(пусть для одного реквизита):

ID_R(Реквизит) | Date_R(ДатаИзменения) | Value_R(ЗначениеРеквизита)

Как эффективно выбрать набор значений за период (С .. По.. ) времени, с учетом того
что в результирующий набор нужно включать предыдущее значение реквизита.. т.е. значение которое имело место быть на начало выбираемого периода?

Ну типа из этого:

===================
...
PODR 01.01.1990 Хоз.отдел
PODR 01.01.1991 Секритариат
PODR 15.08.06 Бухгалтерия
PODR 01.09.06 Руководство

с 01.08.06 по 31.12.06
получить:

PODR 01.01.1991 Секритариат
PODR 15.08.06 Бухгалтерия
PODR 01.09.06 Руководство


...
Конечно все намного сложнее, но поскльку важна лишь суть упрощаю.

Да и таблица не 10 записей а большая..
Раньше такое делали исп. подзапросы (inner join)
ну т.е. в подзапросе находили макс значение даты по реквизиту до начала периода по которому запрашиваем и включали значения попадающие в диапазон дат и значение которое равнялось макс значению даты из подзапроса.
Как тут быть чтобы не тащить все записи на клиента?

[artkashin]

Установить ключ, сортируемый по дате.
Обычно, дата, в таких случах, входит в первичный ключ, поэтому даже устанавливать не надо
rec.setrange(Date, 0D, <требуемая дата>);
IF rec.Find('+') THEN// находит последнюю запись
BEGIN
//rec содержит информацию, действующую на требуемую дату.
END;

[Glazz]

Цитата:

Сообщение от Kashin

Установить ключ, сортируемый по дате.
Обычно, дата, в таких случах, входит в первичный ключ, поэтому даже устанавливать не надо
rec.setrange(Date, 0D, <требуемая дата>);
IF rec.Find('+') THEN// находит последнюю запись
BEGIN
//rec содержит информацию, действующую на требуемую дату.
END;

Спасибо понял! Курсоры рулит

[Fordewind]

Совет:
Первичный ключ в таблицах с историей лучше делать по номеру записи (Entry No.)

[artkashin]

Цитата:

Сообщение от Fordewind

Совет:
Первичный ключ в таблицах с историей лучше делать по номеру записи (Entry No.)

А причина? Просто это дополнительный головняк в виде ключа по дате. Где экономия?

[Fordewind]

Цитата:

Сообщение от Kashin

Цитата:

Сообщение от Fordewind

Совет:
Первичный ключ в таблицах с историей лучше делать по номеру записи (Entry No.)

А причина? Просто это дополнительный головняк в виде ключа по дате. Где экономия?

Простые первичные ключи быстрее работают. А таблица истории обычно содержит много записей.
Убедился сам, когда делал что-то на подобии журнала изменений, заточенного под цикл квота-заказ-отгрузка-подбор-учтенный документ.
И главное: где головняк в виде ключа по дате? SETCURRENTKEY написать сложно?
И еще не рекомендуется вставлять дату в первичный ключ. Это сравнительно недавно обсуждалось здесь.

[artkashin]

Цитата:

Сообщение от Fordewind

И главное: где головняк в виде ключа по дате? SETCURRENTKEY написать сложно?

дело в том, что не сложно. но кроме первичного ключа по числовому полю, появляется квазипервичный ключ по дате. Т.е. в любом случае поиск будет проходить по вторичному ключу, в который будет включена дата. Я могу согласится, что при вставке данных в базу по числовому ключу, теоритически будет быстрее, но насколько, я - сказать не берусь, с учетом того, что не знаю, как хранит, добавляет и модифицурует данные SQL-сервер. Единственно, что точно - так это размер базы будет больше из-за двух ключей.

Цитата:

Сообщение от Fordewind

И еще не рекомендуется вставлять дату в первичный ключ. Это сравнительно недавно обсуждалось здесь.

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

[Fordewind]

Цитата:

Сообщение от Kashin

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

Тут я погорячился. Обсуждалось несколько другое

[randrews]

Цитата:

Сообщение от Kashin

Цитата:

Сообщение от Fordewind

Совет:
Первичный ключ в таблицах с историей лучше делать по номеру записи (Entry No.)

А причина? Просто это дополнительный головняк в виде ключа по дате. Где экономия?

Во-первых, в первичный ключ совать дату не надо, так как нет смысла... В данном случае речь идет о неком логе изменений... а, значит, уникального ключа не найти, исполользуя дату. Только через Entry No.

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

[artkashin]

Цитата:

Сообщение от randrews

Во-первых, в первичный ключ совать дату не надо, так как нет смысла... В данном случае речь идет о неком логе изменений... а, значит, уникального ключа не найти, исполользуя дату. Только через Entry No.

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

Цитата:

Сообщение от randrews

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

Ключевая фраза здесь - могут быть тормоза.
Никто не проверял реальное падение скорости.

Собственно, проверка на уникальность по дате, в данном случае очень важна. История реквизитов, когда на одну дату будет множество значений данного реквизита, ставит дополнительную задачу на то, какой реквизит брать.

Т.е. первичный ключ по дате однозначно будет определять уникальность реквизитов в эту дату.

[konrad_imported]

А потом какой-нибудь очень смышленый юзер сдвинет себе системную дату - и будете гадать, а что когда было. Только по номеру записи журналы изменений надо делать.