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

Question

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

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

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

По существу, мы хотели бы поменять тип элемента и его статус на temporal properties или effectivities a-la Fowler (или некоторые другие вещи, которые меняются со временем).

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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