Изменения схемы базы данных необходимы ежегодно. Какую стратегию следует использовать?

Question

Каждый год наша компания проводит конференцию / стенд, где участники могут продемонстрировать свою продукцию.

У нас есть веб-приложение, которое позволяет участникам записаться на конференцию. Они могут вводить такую ​​информацию, как название своей компании, платежная информация и т. Д.

Кажется, что требования к тому, какую информацию должны вводить участники, меняются из года в год.

I.E. Один год участникам может понадобиться ввести размер нужного им стенда, в следующем году он больше не нужен, и так далее. В один год вам может потребоваться ввести общее количество m ^ 2, которое вы хотите, а в следующем году вам может понадобиться добавить длину, высоту и количество этажей, которые вы хотите.

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

Итак: у кого-нибудь есть хорошая идея о том, как мы можем справиться с этим? Единственные решения, о которых я могу думать, это

• Версия нашей базы данных для каждой конференции, т.е.
• Хранить всю «различную» информацию в формате xml

Если у кого-то есть хорошая литература о том, как обращаться с развивающимися базами данных и работать с устаревшими данными, было бы хорошо!

Answer 1

Как бы мне не хотелось это говорить, это может быть в случае, когда структура Entity-attribute-value будет работать лучше всего.

http://en.wikipedia.org/wiki/Entity-Attribute-Value_model

Обратите внимание, что это не модель для легкого использования, с ней есть серьезные проблемы. Но это именно та проблема, для решения которой она предназначена.

Answer 2

Я бы рассмотрел использование подхода «имя-значение» для всех расширенных данных. По сути, вы определяете свои статические данные из года в год. Это будут такие вещи, как информация о компании, например, определение адреса не меняется год за годом. Они будут смоделированы как обычно.

Затем вы определите таблицу, которая будет содержать мастер всех ваших вопросов и будет каким-либо образом связана с вами, чтобы указать вам, для какого года эти вопросы действительны. Эта таблица также может указывать другие атрибуты вопроса, которые могут позволить вам динамически создавать графический интерфейс поверх него. Такие вещи, как регулярные выражения для проверки типа данных и т. Д.

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

Answer 3

"Теперь у нас есть много« устаревших »полей и таблиц в нашей базе данных, и это начинает выглядеть довольно грязно. По историческим причинам мы не можем просто сбросить схему обратно к основам для каждого года. Нам может понадобиться некоторые из данных старых конференций. "

Если они могут вам понадобиться, они не устарели.

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

Если у вас есть таблицы, такие как "standarea" (площадь в м ^ 2), "standize" (длина, ширина, высота и т. Д.) - тогда в вашей модели будут соответствующие объекты (StandArea, StandSize) - эти может расширить общий базовый класс StandData.

Один год одна таблица получает набор данных, а в следующем году другая таблица получает данные. Ваш DAO попытается загрузить каждый объект из каждой таблицы (через родительское поле, err, поле stand_uid), а затем установить для поля StandData в вашем объекте "ConferenceApplication" любое обнаруженное.

Другой вариант состоит в том, чтобы просто иметь все возможные поля в одной таблице и позволить им быть пустыми.