Лучшие практики развертывания базы данных [закрываются]
У меня точно такая же проблема, как и у вас, ежедневная квота всего 10 тыс. Я уверен, что значение по умолчанию было намного выше, например, 1 миллион или что-то в этом роде.
Я нашел эту форму, которую вы можете использовать, чтобы запросить увеличение квоты, но 10k кажется смешно низким, так что я не думаю, что нам нужно запрашивать увеличить (также запрашивать любую информацию, например, о вашей компании)
4 ответа
У нас есть наш дб при Управлении исходным кодом. Любые изменения прослежены тот путь. Что-либо еще было бы кошмаром.
У Jeff есть статья о нем также - http://blog.codinghorror.com/get-your-database-under-version-control/
SQL Server имеет Генерирование, и Опубликуйте Мастер Сценариев, который может быть действительно полезным, если Вы хотите поместить существующую базу данных в управление исходным кодом.
Сценарии и хранение каждого изменения, которое Вы внесли в SQL, являются лучшим способом IMO.
В одном проекте у меня есть все свои изменения DB в сценариях DDL. Те сценарии содержат SQL-операторы, которые необходимы для обновления DB до определенной версии. Имя файла сценария также содержит номер версии DB, до которого DB будет обновлен (_versionnumber.sql)
Рядом с этим у меня есть небольшое приложение, которое обновляет DB до последней версии путем выполнения тех файлов сценария в правильном порядке (от текущего versionnr DB в последний файл сценария).
Для новых проектов я теперь использую Migrator.NET. Эта платформа позволяет Вам записать свои изменения DB в классах C#. Платформа имеет консольное приложение, с которым можно выполнить изменения DB, и также возможно использовать его с msbuild.
Каждый объект базы данных должен храниться в отдельном файле в системе контроля версий. Система управления версиями может содержать файлы, подобные этому примеру:
|- tables
|- employees.sql
|- contracts.sql
|- packages
|- contract_api.sql
|- functions
|- get_employee_name.sql
...etc...
Каждый раз, когда вы изменяете какой-либо объект БД, вы также должны изменять соответствующий файл SQL (DDL) в системе управления версиями. Например, если вы изменяете пакет contract_api , то вы обновляете файл contract_api.sql . Поскольку этот файл был изменен - он может быть установлен, скажем, механизмом непрерывной интеграции.
НО, как вы знаете, есть сценарии DDL, которые нельзя выполнить дважды. Например ' CREATE TABLE mytable ... 'может быть выполнен только один раз. А если ваша система уже находится в производстве, вы не можете позволить себе использовать оператор «DROP TABLE mytable» в заголовке сценария «CREATE TABLE ...». Поэтому для производственных систем вам необходимо создать так называемые дельта-скрипты , которые будут доставлять только изменения. В этом случае вы можете просто создать новый файл с именем employee_upd01.sql, который содержит оператор 'ALTER TABLE mytable ADD COLUMN ...'.
Через некоторое время ваш репозиторий может выглядеть так:
|- tables
|- employees.sql
|- employees_upgr20091001.sql
|- employees_upgr20091004.sql
|- contracts.sql
|- packages
|- contract_api.sql
|- functions
|- get_employee_name.sql
...etc...
И это нормально, потому что : Поэтому для производственных систем вам необходимо создать так называемые дельта-скрипты , которые будут доставлять только изменения. В этом случае вы можете просто создать новый файл с именем employee_upd01.sql, который содержит оператор 'ALTER TABLE mytable ADD COLUMN ...'.
Через некоторое время ваш репозиторий может выглядеть так:
|- tables
|- employees.sql
|- employees_upgr20091001.sql
|- employees_upgr20091004.sql
|- contracts.sql
|- packages
|- contract_api.sql
|- functions
|- get_employee_name.sql
...etc...
И это нормально, потому что : Поэтому для производственных систем вам необходимо создать так называемые дельта-скрипты , которые будут доставлять только изменения. В этом случае вы можете просто создать новый файл с именем employee_upd01.sql, который содержит оператор 'ALTER TABLE mytable ADD COLUMN ...'.
Через некоторое время ваш репозиторий может выглядеть так:
|- tables
|- employees.sql
|- employees_upgr20091001.sql
|- employees_upgr20091004.sql
|- contracts.sql
|- packages
|- contract_api.sql
|- functions
|- get_employee_name.sql
...etc...
И это нормально, потому что : 1) когда вам нужно внести сегодняшние инкрементальные изменения в базу данных - вы развертываете файлы, которые были изменены сегодня 2) если вам нужно развернуть чистую установку вашей системы - вы запускаете все сценарии по порядку, например, сначала employee.sql , затем employee_upgr20091001.sql и т. Д.
Как каждый объект БД находится в отдельном файле в системе контроля версий, вы хорошо контролируете все изменения.