Дизайн базы данных для хранения информации человека, которая меняется со временем?

Question

Мы используем сторонний продукт для управления членством в нашем спортивном центре. У нас есть несколько типов членства (например, младший, студент, персонал, сообщество) и несколько статусов членства (например, годовой, активный, неактивный, приостановленный). К сожалению, продукт записывает только текущий тип членства и статус участника. Я хотел бы иметь возможность отслеживать, как тип и статус наших членов менялись со временем.

В настоящее время у нас есть доступ к дизайну базы данных продукта. Он работает на SQL Server, и мы регулярно выполняем собственные SQL-запросы к таблицам продукта, чтобы создавать собственные таблицы. Затем мы связываем наши таблицы с сводными таблицами в Excel для создания диаграмм. Итак, мы знакомы с дизайном базы данных и SQL. Однако мы застряли в том, как лучше всего подойти к этой проблеме.

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

По сути, мы хотели бы превратить свойства типа и статуса члена в временные свойства или эффективность а-ля Фаулер (или что-то другое, что меняется со временем).

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

ОБНОВЛЕНИЕ 2009-08-25: Отстранены и еще не имели возможности опробовать предложенные решения. Надеюсь сделать это в ближайшее время и на основе результатов выберет ответ.

Answer 1

Учитывая, что ваша система уже написана и работает, самый простой подход к этой проблеме (и тот, который меньше всего влияет на существующую базу данных / код) - это добавить таблицу истории членства, которая содержит MemberID, статус, тип и столбцы даты. Затем добавьте триггер UPDATE и INSERT в основную таблицу элементов. Когда эти триггеры срабатывают, вы записываете новые значения для члена (вместе с датой изменения статуса) в таблицу истории членов. Затем вы можете просто запросить эту таблицу, чтобы получить истории для каждого члена.

Это довольно просто реализовать и никак не повлияет на существующую систему.

Я напишу это для вас для бесплатного членства. :)

Answer 2

Я не могу порекомендовать вам прочитать «Sql для умников - продвинутый SQL-программирование» Джо Селко. у него есть целая глава о проектировании временных баз данных и о том, как (эффективно и эффективно) выполнять запросы Temporal Projection, Selection и Temporal Join. И я бы не стал отдавать ему должное, даже пытаясь объяснить, что он говорит в своей главе в этом посте.

Answer 3

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

Затем я бы создал процедуры обновления для периодического обновления базы данных отчетов, скажем, раз в неделю, из основной базы данных. Вот где основная работа придет.

Затем я бы выгнал отчеты из базы данных отчетов. Довольно просто сделать схему типа «звезда» так же, как в сводной таблице. При необходимости я бы использовал какой-нибудь инструмент OLAP, чтобы он находился перед базой данных отчетов.

Это много работы, но со временем это окупится.

Answer 4

Я бы поместил информацию о членстве в свою таблицу с датами начала и окончания. Хранение клиента в отдельной таблице. Это неприятно, если вам постоянно нужна «текущая» информация о членстве, но есть много способов обойти это с помощью запросов или триггеров.