история записей в таблицах поиска

Question

Я надеюсь, что термин «справочная таблица» выбран правильно, я имею в виду, например, таблицу ставок (справочную) со следующими ставками:

дешево: 15 долларов, -

Средний: $ 30, -

дорогое: $ 45, -

мы находимся в ситуации, когда для данного объекта (мы называем это «ошибка», это неисправность устройства, airco,лифт, кран, туалет и т. д.) для ремонта этого устройства нанят конструктор.этот конструктор имеет эти три (составленных) показателя: дешевый, средний и дорогой.

Когда конструктор устраняет ошибку, он вводит отработанные часы и ставку (когда старший выполнял работу, «дорогой»).и когда младший выполнил работу, «дешево»)

технически, мы затем добавляем FK из таблицы ошибок в таблицу тарифов.

Поэтому, когда счет должен быть распечатанмы получаем тариф через FK и количество часов, отработанных из записи об ошибке.

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

Итак, мы должны построить какую-то историю, и вот в чем вопрос: как это делается?

я придумал две разные ситуации, ивопрос в том, является ли один из них хорошим, есть ли лучшие способы?

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

2 не ставьте FK из-за ошибки в оценку, но когда вы устанавливаете скорость в случае сбоя, вы просто копируете ЗНАЧЕНИЕ из значения скорости в состояние сбоя.Недостатком является то, что когда ошибка все еще редактируема, когда вы редактируете скорость, частота ошибки не обновляется.И, когда вы редактируете ошибку, вы получаете выпадающий список с 3 значениями, из которых не совпадают текущие значения.

На данный момент спасибо уже за чтение всего этого поста!

Answer 1

Было хорошее обсуждение этого вопроса на Программистах. SE

Как хранить цены с эффективными датами

Это хорошо известная проблема и использование эффективныхсвидания - лучший способ сделать это.

Answer 2

Мне не нравится # 2;Мне никогда не нравится заменять отношения фактическими значениями (денормализуя), если я могу помочь.Кроме того, это делает аудит намного сложнее;если есть странное значение для ставки, откуда она взялась?

Однако проблема с # 1 заключается в том, что если по какой-то причине вы измените дату счета, он, вероятно, все еще должен иметьс той же скоростью, что и при первоначальном создании.

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

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

Answer 3

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