Лучшая практика для управления изменениями модели данных в выпущенной системе

Question

Я собираюсь приступить к разработке проекта веб-приложения.

Я хотел бы поднять что-нибудь пораньше и часто, чтобы ранние последователи могли поиграть и получить обратную связь.

Но я предполагаю, что модель данных будет меняться по мере продвижения проекта и улучшения моего понимания системы.

Как мне решить дилемму надлежащего обновления модели данных и предотвращения потери данных для первых пользователей? Должен ли я просто выложить большое предупреждение «пользователь остерегается», или я должен приложить усилия для создания сценариев миграции?

Answer 1

Какую платформу вы используете? Ruby on Rails предоставляет вам скрипты миграции как часть пакета. Если вы находитесь на Java-земле, вы можете проверить migrate4j .

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

Answer 2

Скотт Эмблер (Scott Ambler) написал несколько хороших вещей о гибких базах данных. Есть книга и веб-сайт .

Answer 3

Для моей компании ...

Это жесткое и быстрое правило, согласно которому база данных ДОЛЖНА быть обратно совместимой с текущей версией программного обеспечения. Если это не прибегнуть к смоле и тактике пернатых против обидчика.

В нашем случае мы пишем пользовательское программное приложение для наших клиентов, поэтому у нас есть некоторая гибкость в том, как мы можем что-то реализовывать ... но чаще или нет, клиент хочет просматривать свои изменения с живыми данными . Таким образом, мы должны иметь возможность поддерживать текущую версию приложения, а также новую версию приложения, которую клиент рассматривает и утверждает.

Некоторые другие вещи, которые мы делаем, инвестируются в Sql Compare и Sql Data Red Sql Compare . Это обеспечит правильное перемещение изменений из среды разработки в производственную среду.

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

Answer 4

Первый раз, когда я услышал о гибких данных, был разговор Мартина Фаулера и Прамода Садалажа .

Answer 5

@ bradheintz; Я использую Microsoft Web Stack.

Я нашел короткий список инструментов миграции, связанных с .NET, здесь:

http://flux88.com/blog/net-database-migration-tool-roundup/.