Какой дизайн БД использовать для сбора настраиваемых демографических данных?

Question

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

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

Мне интересно, есть ли другие альтернативы, которые я не рассматривал. Или, если вы столкнулись с подобной проблемой, как вы справились с ней (и насколько вы были удовлетворены результатом)?

Answer 1

Вот мои мысли:

• Вы не должны связывать демографию с регистрацией. Это не имеет смысла логически, и это всегда может привести к практическим проблемам. Вместо этого вы можете создать таблицу истории демографии, например, StudentID, StartDate, EndDate, xxxDemographics, yyyDemographics ...)
• Различные академические институты могут иметь совершенно разные демографические потребности. Чтобы уменьшить настройку, вы можете захотеть программно кодировать все определения в таблице конфигурации, например, Демография (DemographicsID, DemographicsDesc) и вести таблицу отношений между студентом и демографией, например StudentDemographics (StudentID, DemographicsID ...). Единственная хитрость с вышеуказанным решением состоит в том, что вы можете использовать PIVOTing для некоторых отчетов.

Answer 2

Если вы пишете свой код таким образом, что добавление столбцов не нарушит его (или его будет легко обновить), например, будьте осторожны с SELECT * и указывайте столбцы в INSERT, то из вашего описания это не Звучит так, как будто вам нужна сверхгибкость значения атрибута, поэтому я остановлюсь на варианте 1.