Как люди рекомендуют управлять обновлениями структуры базы данных?Как управлять обновлениями структуры sql
например. добавлены новые функции, которые требуют изменения существующих таблиц, новых добавленных и т. д.
Есть ли хороший программный продукт или это случай написания операторов типа ALTER.
Хотя есть программное обеспечение, которое может анализировать различия между двумя схемами (RedGate SQL Compare) и генерировать необходимые сценарии изменений, я предпочитаю писать свои собственные операторы изменения базы данных. Таким образом, у меня есть полный контроль над тем, что меняется - ни больше, ни меньше. Внесите изменения в сценарий Install.sql или что-то в этом роде для каждой версии базы данных, чтобы вы могли просто запустить этот скрипт и обновить базу данных.
Это позволяет легко перемещать изменения от разработчика до тестирования на производство.
Im просят от имени кого-то на работе - Pro версия Red-gate sql compare выглядит неплохо и доступно. –
Если вы говорите об управлении структурами баз данных между версиями одной и той же базы данных, то SQL Compare отлично, мы используем на работе и экономим массу времени. – Nick
+1 Гибкость и эффективность – Andomar
Если вы не хотите, чтобы рукописным все альтер заявления, SQL Server Management Studio имеет графический интерфейс для решения всех такого рода вещи. Вы можете использовать графический интерфейс, а затем посмотреть на сценарий, который он генерирует, и перейти оттуда, если вам нужен какой-то быстрый гибридный подход.
Что-нибудь для Linux или Mac? Я попытался задать вопрос в технологии нейтрально, но наши требования являются стек ЛАМПЫ на серверах и Macs и Ubuntu на разработчика настольных компьютеров –
Вы не указали сферу применения вашего приложения или количество разработчиков и т. Д., Поэтому немного сложно сделать какие-либо рекомендации. Однако, если ваш проект состоит из нескольких параллельных проектов и нескольких разработчиков, и вы копируете из разработки до производства я бы рекомендовал что-то вроде следующий:
Примечание: контроль качества практически идентична продукции, за исключением прикладных изменений, ожидающих их конечной продукции установки. dev содержит любые изменения в работе, дополнительный отладочный мусор и т. д. Вы можете периодически восстанавливать производственную резервную копию на qa и dev для повторной синхронизации их (просто убедитесь, что все разработчики знают об этом и планируют соответственно), потому что (в зависимости от количества разработчики), они (производство против qa vs. dev) начнут испытывать больше различий с течением времени.
Наша установка: Test сервер - MySQL 5, php5.2, apache2 производства сервер - mysql 5, php5.2, apache2 У нас также запущен phpMyAdmin. –
Я удалил серверные ссылки sql и добавил тэг mysql к вашему вопросу. Сколько разработчиков, если это просто вы, не более 10 человек. Если вы меняете таблицы только раз в год, то каждый раз они меняются, как изменения таблицы. –
Одна из наших команд работает так, и это беспорядок. Изменения происходят так долго, что они начинают перекрываться. Хранение каждого объекта в CVS означает, что изменения распространяются по многим файлам, что делает время развертывания и склонность к ошибкам. И Devs забывают о своих запросах в тот момент, когда QA одобряет их, поставляя продукты, которые конечные пользователи испытывают как полупеченные. Ваш пробег может отличаться; Надеюсь, он лучше работает на вашем месте :) – Andomar
Я собираюсь добавить одну вещь. Недостаточно написать инструкцию alter table для изменения структуры таблицы. Если вы меняете структуру таблицы, вам лучше быть уверенным, прежде чем запускать ее, чтобы точно знать, какие другие представления, функции, таблицы, хранимые процедуры, триггеры, пакеты SSIS (DTS) (для SQL Server) и динамический код из приложений будет изменяться. Если вы не совсем уверены, какие другие объекты могут быть затронуты, вы не готовы изменить таблицу. Я видел, как слишком много критически важных бизнес-функций ломаются, потому что кто-то hapahazardly изменил структуру таблицы без учета того, что еще использовало эту структуру. Если вы планируете внести структурные изменения в базу данных, я предлагаю вам ознакомиться с рефакторингом базы данных, прежде чем вы это сделаете.
Здесь иша хорошая книга, чтобы начать с: http://www.amazon.com/Refactoring-Databases-Evolutionary-Addison-Wesley-Signature/dp/0321293533
вы должны упоминали MySQL в вопросе, это будет влиять, как вы можете создавать сценарии, изменять базу данных, и т.д. –