Как Вы справляетесь с обновлениями схемы производственной базы данных?

Если вы работаете на chrome, вы можете просто установить расширение chrome из хранилища chrome для решения проблем, связанных с CORS.

Расширение: Allow-Control-Allow-Origin Ссылка: [ https: // chrome .google.com / Webstore / детали / разрешения контроля-позволяют-ориги / nlfbmbojpeacfghkpbjhddihlkkiljbi? гл = еп] [1] [/ д2]

33
задан Mark Harrison 11 November 2009 в 23:21
поделиться

8 ответов

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

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

клиентский дизайн - это - то, где метод VB встроенного sql (даже с подготовленными операторами) получает Вас в проблему. Можно потратить ВОЗРАСТЫ, просто находящие те операторы. Если Вы используете что-то, любят, в спящем режиме и помещают столько же SQL в именованные запросы, у Вас есть единственное место для большинства sql (ничто худшее, чем попытка протестировать sql, который является в некотором операторе IF, и Вы просто не поражаете "триггерные" критерии в своем тестировании на тот оператор IF). До использования в спящем режиме (или другие orms'), когда я сделал бы SQL непосредственно в JDBC или ODBC, я помещу все sql операторы как любой общедоступные поля объекта (с соглашением о присвоении имен), или в файле свойств (также с соглашением о присвоении имен для значений говорят PREP_STMT_xxxx. И используйте или отражение или выполните итерации по значениям при запуске в a) тестовых сценариях b) запуск приложения (некоторые rdbms позволяют Вам предварительно компилировать с подготовленными операторами перед выполнением, таким образом, на входе в систему сообщения запуска я предварительно скомпилировал бы подготовительную-школу-stmts при запуске для подавания заявки сам тестирование. Даже для 100's операторов на хорошем rdbms это - только несколько секунд. и только однажды. И это сохранило мой зад много. На одном проекте не связался бы DBA (другая команда, в другой стране), и схема, казалось, изменилась НОЧЬЮ ни по какой причине. И каждое утро мы получали список точно, где он повредил приложение на запуске.

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

, Если Вы можете, также попытайтесь использовать хранимые процедуры. Их немного более трудно протестировать как выше. Некоторый дб также не предварительно проверяет sql в сохраненном procs против схемы во время компиляции только во время выполнения. Это обычно включает, говорят, что делание копии структуры схемы (никакие данные) и затем создание всех сохранило procs против этой копии (в случае, если команда дб, вносящая изменения, не проверила правильно). Таким образом структура может быть проверена. но как точка сохраненного procs управления изменениями являются большими. На изменении все получают его. Особенно, когда изменения дб являются результатом изменений бизнес-процесса. И все языки (Java, vb, и т.д. получают изменение)

я обычно также устанавливаю таблицу, я использую названный system_setting и т.д. В этой таблице, которую мы сохраняем Идентификатором версии. Это - то, так, чтобы клиентские библиотеки могли соединение и проверять, если они допустимы для этой версии схемы. В зависимости от изменений в Вашей схеме Вы не хотите позволять клиентам соединяться, если они могут повредить Вашу схему (т.е. у Вас нет большого количества справочных правил в дб, но на клиенте). Это зависит, если Вы также собираетесь иметь несколько версий клиента (который происходит в НЕ - веб-приложения, т.е. они выполняют неправильный двоичный файл). У Вас могли также быть пакетные инструменты и т.д. Другой подход, который я также сделал, определяют ряд схемы к операционным версиям в своего рода файле свойств или снова в system_info таблице. Эта таблица загружается на входе в систему и затем используется каждым "менеджером" (у меня обычно есть своего рода клиентский API, чтобы сделать большую часть материала дб) проверить для той операции, если это - правильная версия. Таким образом большинство операций может успешно выполниться, но можно также перестать работать (выдайте некоторое исключение) на устаревшем методы и говорят Вам ПОЧЕМУ.

управление изменением в схеме-> Вы обновляете таблицу или добавляете 1-1 отношение к новым таблицам? Я видел много магазинов который всегда данные доступа через представление поэтому. Это позволяет именам таблиц изменяться, столбцы и т.д. Я играл с идеей фактической обработки представлений как интерфейсы в COM., т.е. Вы добавляете новое ПРЕДСТАВЛЕНИЕ для новой функциональности / версии. Часто, что получает Вас, вот то, что у Вас может быть много отчетов (пользовательские отчеты особенно конечного пользователя), которые принимают форматы таблицы. Представления позволяют Вам развертываться, новый формат таблицы, но поддерживать существующие клиентские приложения (помните все те противные специальные отчеты).

кроме того, потребность записать сценарии обновления и отката. и снова ТЕСТ, ТЕСТ, ТЕСТ...

------------ХОРОШО - ЭТО - НЕМНОГО СЛУЧАЙНОЕ ВРЕМЯ--------------

ОБСУЖДЕНИЯ, На самом деле имел большой коммерческий проект (т.е. магазин программного обеспечения), где у нас была та же проблема. Архитектура была 2 уровнями, и они использовали продукт немного как PHP, но pre-php. То же самое. другое имя. так или иначе я вошел в версии 2....

Она стоила БОЛЬШОГО КОЛИЧЕСТВА ДЕНЕГ, чтобы сделать обновления. Много. т.е. отдайте недели свободного консультационного времени на сайте.

И это переходило к сути дела желания или добавить новые опции или оптимизировать код. Часть существующего кода использовала хранимые процедуры, таким образом, у нас были общие точки, где мы могли управлять кодом. но другие области были, это встроило sql разметку в HTML. Который был большим для получения на рынок быстро, но с каждым взаимодействием новых возможностей стоимость, по крайней мере, удвоенная, чтобы протестировать и поддержать. Таким образом, когда мы смотрели на вытаскивание php, вводят код, включая слои данных (это было 2001-2002 пред любой ORM's и т.д.), и добавляющий, что много новых возможностей (отзыв клиента) посмотрело на эту проблему того, как спроектировать ОБНОВЛЕНИЯ в систему. Который является грандиозным предприятием, поскольку обновления стоят большого количества денег, чтобы сделать правильно. Теперь, большинство шаблонов и все другие люди материала обсуждают с соглашениями об уровне энергии с кодом OO, который работает, но что относительно того, что Ваши данные должны a) интегрироваться к этой логике, b) значении, и также структура данных может изменяться со временем, и часто из-за способа, которым работают данные, Вы заканчиваете с большим количеством подпроцесса / приложения в Вашей клиентской организации, которой нужны те данные-> для данного случая создание отчетов или любое сложное пользовательское создание отчетов, а также пакетные работы, которые делались для пользовательских данных, питаются и т.д.

С этим в памяти, я начал играть с чем-то немного оставленное поля. Это также имеет несколько предположений. a) данных, в большой степени читается больше, чем запись. b) обновлениях, происходят, но не на уровнях банка т.е. один или 2 в секунду говорят.

идея состояла в том, чтобы применить представление COM / Interface к тому, как к данным получили доступ клиенты по ряду таблиц CONCRETE (который менялся изменений в зависимости от схемы). Вы могли создать отдельное представление для каждой операции типа - обновление, удалить, вставить и читать. Это важно. Представления или отобразились бы непосредственно на таблицу или позволили бы Вам триггеру фиктивной таблицы, которая делает реальные обновления или вставляет и т.д., Что я на самом деле хотел, была своего рода trappable косвенность уровня, которая могла все еще использоваться кристаллическими отчетами и т.д. ОТМЕТЬТЕ - вставками, обновите, и удаляет Вас, также мог использовать сохраненный procs. И у Вас была версия для каждой версии продукта. Тем путем Ваша версия 1.0 имела свою версию схемы, и если бы таблицы изменились, то у Вас все еще были бы ПРЕДСТАВЛЕНИЯ версии 1.0, но с НОВОЙ логикой бэкенда для отображения на новые таблицы по мере необходимости, но у Вас также были представления версии 2.0, которые будут поддерживать новые поля и т.д. Это должно было действительно только поддерживать для данного случая создание отчетов, который, если Ваш БИЗНЕС-человек и не кодер является, вероятно, смыслом того, почему у Вас есть продукт. (Вашим продуктом может быть дерьмо, но если у Вас есть лучшее создание отчетов в мире можно все еще победить, реверс верный - продуктом может быть лучшая мудрая функция, но если это - худшее при создании отчетов, что можно очень легко освободить).

хорошо, надеющиеся некоторые из тех идей справка.

3
ответ дан 27 November 2019 в 19:31
поделиться

Я - большой поклонник Красный Логический элемент продукты, которые помогают созданию пакеты SQL обновить схемы базы данных. Сценарии базы данных могут быть добавлены к управлению исходным кодом для помощи с управлением версиями и откатом.

4
ответ дан 27 November 2019 в 19:31
поделиться

Liquibase

liquibase.org:

  1. это понимает, в спящем режиме определения.
  2. это генерирует лучшее обновление схемы sql, чем в спящем режиме
  3. , это регистрируется, какие обновления были сделаны к базе данных
  4. , это обрабатывает двухступенчатые изменения (т.е. удалите столбец "нечто" и затем переименуйте другой столбец к "нечто")
  5. это обрабатывает понятие условных обновлений
  6. , разработчик на самом деле слушает сообщество (с, в спящем режиме, если Вы не находитесь в "в" толпе или новичке - Вы в основном проигнорированы.)

http://www.liquibase.org

8
ответ дан 27 November 2019 в 19:31
поделиться

мнение

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

6
ответ дан 27 November 2019 в 19:31
поделиться

В целом мое правило: "Приложение должно управлять своей собственной схемой".

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

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

Относительно тестирования, так как обновления являются частью приложения, тестирование их становится частью цикла испытаний для приложения.

Запоздалая мысль: Принятие части критики в других сообщениях здесь, обратите внимание, что в правиле говорится "свой собственный". Это только действительно применяется, где приложение владеет , схема как обычно имеет место с программным обеспечением, проданным в качестве продукта. Если Ваше программное обеспечение совместно использует базу данных с другим программным обеспечением, используйте другие методы.

4
ответ дан 27 November 2019 в 19:31
поделиться

Это все тяжелые темы, но вот моя рекомендация для обновления.

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

2
ответ дан 27 November 2019 в 19:31
поделиться
1
ответ дан 27 November 2019 в 19:31
поделиться

Как сказал Пат, используйте ликвибазу. Особенно, если у вас есть несколько разработчиков с собственными базами разработки. внесение изменений, которые станут частью производственной базы данных.

Если есть только один разработчик, как в одном проекте, над которым я сейчас работаю (ха), я просто фиксирую изменения схемы в виде текстовых файлов SQL в репозиторий CVS, которые я проверяю партиями на производственном сервере, когда код происходят изменения.

Но Liquibase организована лучше, чем это!

0
ответ дан 27 November 2019 в 19:31
поделиться
Другие вопросы по тегам:

Похожие вопросы: