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

Question

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

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

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

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

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

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

Answer 1

Учитывая, что ваша система уже написана и установлена, самый простой подход к этой проблеме (и тот, который меньше всего влияет на существующую базу данных / код) - добавить таблицу истории членства, содержащую столбцы MemberID, status, type и date.Затем добавьте ОБНОВЛЕНИЕ и триггер ВСТАВКИ в основную таблицу элементов.Когда срабатывают эти триггеры, вы записываете новые значения для участника (вместе с датой изменения статуса) в таблицу истории участников.Затем вы можете просто запросить эту таблицу, чтобы получить истории для каждого участника.

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

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

Answer 2

Я не могу рекомендовать вам достаточно прочитать книгу Джо Селко "Sql для smarties - расширенное программирование sql".у него есть целая глава о проектировании временной базы данных И о том, как (эффективно и действенно) запускать запросы временной проекции, выбора и временного объединения.И я бы не отдал ему должное, если бы даже попытался объяснить, что он говорит в своей главе в этом посте.

Answer 3

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

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

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

Это большая работа, но со временем она окупится.

Answer 4

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