Хранение истории в базе данных

Question

Что касается хранения истории в базе данных, лучше ли использовать DateEnd (пример 1) или Duration (пример 2)?

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

Есть ли другие изменения, которые я должен внести в один из этих примеров, если окажется, что это правильный подход?Используемая БД - это MySQL, хотя я не думаю, что это имеет отношение к подходу здесь.

Answer 1

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

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

Answer 2

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

Вы также можете записать все три и применить ограничение строки, чтобы они не могли «не соответствовать».

Однако, один из очень часто используемых типов данных «дата окончания» - это отфильтровать строки, которые «не являются текущими»: что-то вроде WHERE END_DATE> CURRENTSYSTEMDATE ().Если у вас есть такой способ использования, то, вероятно, не рекомендуется «опускать» дату окончания.

Answer 3

Производные значения, такие как длительность, не нужно хранить в базе данных.

В некоторых случаях ваш подход к записи истории строки будет работать, но для того, чтобы действительно отловить все изменения во всех строках, вы будетеСкорее всего, нужна другая таблица, например, subscription_hist, которая будет обновляться триггером при вставке и обновлении подписки.Тогда вам придется отслеживать только last_modified_date и last_person_changed_by.Все остальное можно вывести.Таким образом, вы могли видеть, что случилось со временем.У меня нет картинок для уточнения, но этот метод, если он будет реализован тщательно, позволит полностью восстановить данные на определенный момент времени, а также сохранить историческую информацию.

Answer 4

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