Ну в общем чем дальше, тем больше путаюсь...
Уж извините за ламерские вопросы...
До этого пытался спрашивать "в общем случае", но в общем все ясно, а на практике...

Нужно вместо обычного списка сотрудников (Таб.ном., Ф,И,О) сделать список, в котором табельный номер и фамилия могут быть "историчными" (или "периодическими", или как еще там...). Причем их изменения должны (могут) задаваться как задним числом, так и до того, как они произойдут по факту.

Что для этого можно сделать:
Создать табл. истории Таб.ном. и табл. истории фамилии.
В них: IDсотрудника(FK), IDзаписи(PK), значение, дата начала действия значения.

Пробовал следующие варианты:
1. просто добавить таблицы и наложить фильтры на даты, отбирая тем самым значения "историчных" полей, действительные на текущий момент.
ПЛЮСЫ: просто, удобно, красиво
МИНУСЫ: тормозит (4 сек.), причем только с одним полем - почти не заметно, а с двумя - сильно;
-кстати, в этом варианте заметно, что сервер кеширует результаты запросов: повторное (при тех же данных в таблицах) заполнение Browse происходит быстрее (почти мгновенно)
-тормоза, как я понимаю, вызваны "перемножением" таблиц (LEFT OUTER или INNER - разницы не заметно), т.е. большим объемом данных

2. использовать для подстановку на место обычного
поля результата вспомогательного запроса по таблице истории, определяющего
действительное на текущий момент значение "историчного" поля
ПЛЮСЫ: чуть быстрее, в запросе отсутствует JOIN
МИНУСЫ: все равно медленно (2 сек).

Не могли бы вы покритиковать то, на чем я остановился и предложить (намекнуть) более эффективный подход?
Мне кажется, задачи такого рода возникают очень часто, как правильно решать их?
Может быть есть какие-то статьи по этому поводу?

Ссылка http://www.msaccess.ru/Raznoe_BigPrgOriginal.html которую нашел в этом форуме не работает :(

Спасибо!

Спасибо, что в выходной день нашли время ответить :))

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

Пробую такие запросы:

select * from Сотрудники, ФамилияСотрудника, ТабНомерСотрудника
where ...стыковка таблиц по ID Сотрудника...
and ...фильтры по дате-времени действия записей...

(или тоже самое через JOIN)

И если есть 1000 сотрудников, для них как минимум 1000 записей о фамилия и 1000 - о таб. номерах, то получаем что сервер оперирует 1000*1000*1000 записями? это у меня в конечном итоге занимает 4 секунды

Был вариант как описано выше только с историей фамилии - все было ОК, тормозов не было. Добавил аналогично историю Таб. номера - тормоза :((

А если добавится история имени сотрудника? еще *1000? а другие изменяюиеся со временем
поля (например, статус сотрудника, место работы, должность)? Это ведь все тоже (УЖЕ!) хранится в таблицах с предложенной структурой! Ой как дойдет дело до расстановки персонала, скажем...
__________________________________________
Есть другой вариант, запросы вида:

select * from Сотрудники,
(select ... from ФамилияСотрудника
where ...стыковка таблиц по ID Сотрудника...
and ...фильтры по дате-времени действия записей...),
(select ... from ТабНомерСотрудника
where ...стыковка таблиц по ID Сотрудника...
and ...фильтры по дате-времени действия записей...)

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

Насколько это допустимо на практике?
В других информационных системах?
Тут чисто жизненный опыт требуется :)

PVP WolfcubМИНУСЫ: тормозит (4 сек.), причем только с одним полем - почти не заметно, а с двумя - сильно;
-тормоза, как я понимаю, вызваны "перемножением" таблиц (LEFT OUTER или INNER - разницы не заметно), т.е. большим объемом данных
Согласен с softwarer. Тормоза исключительно из-за отсутствия индексов. Включите в индекс все поля, используемые в связке ON и в условии WHERE, и используйте в запросе явный индекс, например join TABLE t with (index(...)) on ... И тогда оба запроса будут проходить быстро и за одинаковое время.

Спасибо!
Попробую!

Огромное спасибо! Тормоза (после создания индексов) исчезли :))
(кстати with(index()) не пришлось - это нормально? :)

У меня своя специфика - пишу клиентов в Clarion 6 ("корпоративный стандарт", однако) - поэтому тормоза работы SQL-драйвера Clarion-a (не прямой ODBC) иногда смешиваются с неэффективностью структуры базы данных, как вот было сейчас.

Еще один момент: в таблице у меня есть и BeginDT и EndDT, но это так сложилось исторически.
Я же сейчас использую только BeginDT - мне кажется, что хранить EndDT - это лишнее, ведь во-первых это некоторая избыточность данных, а во-вторых что будет, если в историю изменения параметров нужно вставить посередине еще одну запись; или, например, есть необходимость скорректировать дату начала действия "исторического" значения

Пожтому приноровился делать так:
BeginDT =
(select top 1 (BeginDT)
from DEmpStatus
where IDEmp = A.IDEm
and BeginDT <= __СЕГОДНЯиСЕЙЧАС__
order by StatusBeginDT desc)

все пока работает :) если есть желание покритировать такой подход - буду только рад

PVP
На мой взгляд, перебор в детализации. Не надо делать историю для каждого поля. Обычно существует группа полей, общих по смыслу. Например, общие данные о сотруднике (фио, дата раждения, дата поступления, дата увольнения, паспорт и т.д.), данные о повеременной работе (Где, кем, за сколько), данные о отчеслиниях (ссуды, алименты, квартплата) и т.д. Досточно иметь историю для группы однородных полей.

Физически это выглядит следующим образом. В записи таблицы есть набор полей S01 - S0N, код вида данных (группы набора параметров), период ввода параметров (DW - отчетный период), DateN, DateK - период действия параметров. Одна и таже переменная (поле S01) в разных видах данных (в разных группах) имеет разный смысл.


чуть-чуть не понял: поля S01 - S0N - наверное разного типа (даты, числа, наименования)? или все сведено к строкам и потом конвертируется?

и еще один вопросик:
я полгода назад пытался сделать что-то супер-пупер универсальное - хранить все атрибуты объекта в одной таблице:

IDОбъекта
IDАтрибута
ЗначениеАтрибута
ДатаНачалаДействияЗначенияАтрибута
ДатаКонцаДействияЗначенияАтрибута

Целью было: обеспечить раширяемость базы - в том числе за счет свободного добавления новых атрибутов и за счет поддержки "историчности" всех атрибутов. Написал для этого библиотеку классов.

в конце концов уткнулся к то, что обработка запросов безбожно тормозила. Например, чтобы вывести простой список сотрудников нужно было в запросе создать для таблицы несколько алиасов и присоединить их друг к другу.
С добавлением в запрос новых атрибутов (ФИО, дата рождения, таб номер и т.д.) скорость обработки запроса падала катастрофически. Потому бросил...

PVP Wolfcub
(кстати with(index()) не пришлось - это нормально? :)
Я обычно перестраховываюсь.
ок, попробую перестраховаться :)

WolfcubЯ же сейчас использую только BeginDT - мне кажется, что хранить EndDT - это лишнее...Зря. Например ....
Пример полезный :)

Но вот если история создается задним числом?
было:
Иванова - c 01.01.2000 по NULL (или 01.01.3000 :)
хотим добавить
Петрова - с 01.01.1977 по 01.01.2000
надо: определить дату начала действия Ивановой (для конца Петровой)

было
Петрова - с 01.01.1977 по 01.01.2000
Иванова - c 01.01.2000 по NULL
хотим добавить
Сидорова - с 01.01.1990 по 01.01.2000
надо: 1. обрезать дату конца действия Петровой
2. определить дату начала действия Ивановой (для конца Сидоровой)

А если надо скорректировать данные:
Петрова - с 01.01.1977 по 01.01.2000
Сидорова - с 01.01.1990 по 01.01.2000
Иванова - c 01.01.2000 по NULL
хотим изменить
Сидорова - с 01.01.1995
нужно:
найти Петрову и исправить у нее дату конца

и так далее... а если мы хотим исправить так:
Сидорова - с 01.01.2005
тогда ой-ой :) Иванову тоже придется обрабатывать

Или я усложняю и такое на практике не требуется?
:))

PVP:
про подход с одной таблицей: одна таблица для хранения всех атрибутов вообще или только истории изменения всех атрибутов?

спрашиваю вот почему - я делал все с одной таблицей (более того - был вариант с одной таблицей ВООБЩЕ ДЛЯ ВСЕХ типов объектов).

но при такой структуре полностью теряется возможность использовать ограничения ссылочной целостности между атрибутами объектов!
(то есть они конечно реализуемы, но насколько это сложно сделать я даже представить опасаюсь :))

И тогда огромное количество уже разработанных стандартных средств "визуализации" (шаблоны в Clarion или компоненты в Delphi-Builder) не использует большую часть своих функций!!!

про периоды:
я примерно представляю что Вы имеете в виду под разными периодами, но
мой пример с разными фамилиями ОДНОГО и ТОГО ЖЕ человека более простой.
Объект: конкретный человек
Атрибут: фамилия
Значения: фамилия человека в разные периоды его жизни

И эти фамилии сквозные для всего времени существования объекта и не зависят от каких-то еще периодов!

Ваш пример со справками для подоходнего налога - ведь это же ДВЕ разные справки, насколько я понял :) В обоих указан период льготы. Логика расчета налога может, работая с расчетным периодом, просто проанализировать все справки и сроки действия льгот, попадающие в этот период.
Хотя я может быть не совсем понял :))
Если не трудно - можно еще примерчик, касающийся отчетных и расчетных периодов?

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

Спасибо за подробные ответы!

Про периоды в принципе понял, только вот...

Объект - конкретная справка для конкретного сотрудника
данные об справке:
1. дата создания справки (внесения в систему, начала действия)
2. даты начала
3. дата конца периода действия льготы
4. размер льготы и т.д.

По-моему здесь "историчности" атрибутов как таковой и нет - просто есть насколько объектов, для правильного учета которых необходимо знать дату, когда они были созданы (внесены с систему, начали действовать).
То есть ИМХО "историчность" здесь - период жизни _самого_объекта_, а не актуальности значений его атрибутов.

А вот если бы мы рассматривали все данные о льготах сотрудника как ОДИН ЕДИНСТВЕННЫЙ объект, то тогда бы у него ВСЕ поля были бы "историческими" и " дата создания справки " определяла бы как раз историю изменения атрибутов этого объекта.
Хотя в принципе - это "те же яйца, только сбоку" :))

___________
а по поводу вопроса про универсальную структуру БД - или здесь на форуме это уже обсуждалось? тогда я пойду почитаю :))

PVP WolfcubВот например изменение условий работы сотрудника (другой оклад, другие надбавки) - известны границы периода в пределах которого действительны эти условия работы. Какой еще период может быть необходимо рассматривать? :))Рассмотрим два отчетных периода - сентябрь и октябрь. В сентябре в базу системы было занесено, что у Иванова была льгота по подоходному налогу 50% , которая началась 15 июля и должна, закончится 25 ноября. Начисляя в сентябре деньги за отпуск, переходящий на октябрь, бухгалтер берет подоходный налог из октябрьских денег, учитывая льготу.

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

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

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

Извиняюсь за предыдущий пост - ошибся кнопками :))

ModelR Здесь

ХА!!!
Да по этой ссылке (и еще по одной) мы приходим к Вашему же посту:
Re: Как построить изменение справочников?
.....
Запросы конечно будут сложнее типа

SELECT ....., NSchet, Schet_Number
FROM .....
LEFT JOIN spSchet_history ON spSchet_history.SchetID=Docum.SchetID
and spSchet_history.Date =
(select max(h.Date) from spSchet_history h where
h.SchetID=Docum.SchetID and h.Date <=Docum.Date)
WHERE ...

так я такой же вариант предлагал :))
только sofеwarer его раскритикковал и я в принципе с ним согласен :))

принцип хранения истории мне ясен - мне сейчас важно определиться:
ВАРИАНТ А: хранить ОБЕ границы временного периода
или
ВАРИАНТ В: только ЛЕВУЮ (раннюю) чисто из следующих соображений:

1. скорость обработки сложных запросов
2. сложность программирования триггеров для управления ПРАВОЙ (вспомогательной) границей временного периода

может быть я предъявляю слишком высокие требования к универсальности структуры, но мне хотелось бы реализовать поддержку след. возможных действий пользователя:
1. штатное изменение значения после того как оно произошло
2. изменение значения, которое произойдет в будущем
3. редактирование истории изменений:
- удаление записей из истории
- добавление - в том числе и в середину
- корректировка даты начала - в том числе с изменением порядка следования записей!!!

1 п. в реализации вообще примитивный
2 п. простой как для варианта А , так и В

3 п. для варианта А - влечет усложнение структуры запросов и снижение скорости их обработки
для варианта В - упрощение и повышение скорости, но ценой более сложных алгоритмов для управления дополнительной ПРАВОЙ границей периода

:))
а так я во всем согласен
спасибо за участие в обсуждении

Опять о наболевшем...
Wolfcub
принцип хранения истории мне ясен - мне сейчас важно определиться:
ВАРИАНТ А: хранить ОБЕ границы временного периода или
ВАРИАНТ В: только ЛЕВУЮ (раннюю) чисто из следующих соображений:
A. скорость обработки сложных запросов
B. сложность программирования триггеров для управления ПРАВОЙ (вспомогательной) границей временного периода

может быть я предъявляю слишком высокие требования к универсальности структуры, но мне хотелось бы реализовать поддержку след. возможных действий пользователя:
1. штатное изменение значения после того как оно произошло
2. изменение значения, которое произойдет в будущем
3. редактирование истории изменений:
- удаление записей из истории
- добавление - в том числе и в середину
- корректировка даты начала - в том числе с изменением порядка следования записей!!!

1 п. в реализации вообще примитивный
2 п. простой как для варианта А , так и В
3 п. для варианта А - влечет усложнение структуры запросов и снижение скорости их обработки
для варианта В - упрощение и повышение скорости, но ценой более сложных алгоритмов для управления дополнительной ПРАВОЙ границей периода


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

Хочу спросить - этого будет достаточно, или нужно еще что-то предусмотреть?

С новым годом и спасибо!