Что хороший путь состоит в том, чтобы реализовать гибкий процесс базы данных, который находится в синхронизации с кодовой базой, особенно в отношении непрерывной интеграции? [закрытый]
http://webostv.developer.lge.com/api/webos-service-api/db/ Похоже, что он подключается к какой-то внутренней БД. Существует способ подключения js к БД SQL Server, но для этого необходимо, чтобы у клиента был объект activex. Как подключиться к базе данных SQL Server из JavaScript в браузере?
Если бы мне пришлось угадывать, вам пришлось бы создавать вызовы API для подключения к лазурной БД. Какие вы должны быть в состоянии использовать функции Azure. Что для этого, вероятно, было бы идеально. Плюс функции, вы платите только за использование, поэтому вы платите в зависимости от количества вызовов, сделанных против этой функции. https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-http-webhook
5 ответов
Вам нужен процесс сборки, который создает схему базы данных и добавляет любые необходимые данные начальной загрузки. При использовании инструмента O/R, который поддерживает поколение схемы, большая часть той работы сделана для Вас. Независимо от того, что не сгенерировано инструментом, сохраните в сценариях.
Для непрерывной интеграции идеально "сборка" должна включать полное, восстанавливают базы данных и перезагрузки данных статического испытания.
Я просто видел, что у Вас нет инструмента ORM..., вот то, что мы имели в компании, на которую я раньше работал
db/
db/Makefile (run `make` to rebuild db from scratch, `make clean` to close db)
db/01_type.sql
db/02_table.sql
db/03_function.sql
db/04_view.sql
db/05_index.sql
db/06_data.sql
Расположение, однако необходимое... каждый из тех *.sql скрипты были бы запущены для генерации структуры. Разработчики у каждого были локальные копии DB и любое изменение DB, были просто другим изменением кода, ничем специальным.
Если Вы работаете над проектом, который уже имеет процесс сборки (Java, C, C++), это - вторая натура. При использовании сценариев таким способом, которым нет никакого процесса сборки вообще, это будет небольшим количеством дополнительной работы.
"Нет такой вещи как "регистрация в изменении базы данных"".
На самом деле я думаю, что можно зарегистрироваться в изменении базы данных. Прием должен прекратить использовать простой - неимеющий версию - схема и имена таблиц.
Если Вам присоединили номер версии к схеме в целом (или таблица), то у Вас может легко быть регистрация версии.
Обратите внимание, что версии базы данных не имеют необычного главного незначительного выпуска. "Главный" пересмотр в прикладном программном обеспечении обычно отражает базовый уровень совместимости. Тот базовый уровень совместимости должен быть определен как "использование та же модель данных".
Так версия приложения 2.23 и 2.24 используют версию 2 схема базы данных.
Регистрация версии имеет две части.
Новая таблица. Например, MyTable_8 является версией 8 данной таблицы.
Сценарий миграции. Например, MyTable_8 включает MyTable_7 в сценарий MyTable_8, который перемещает данные, обеспечивая значения по умолчанию или независимо от того, что требуется.
Существует несколько способов, которыми это используется.
Совместимые обновления. Просто изменяя таблицу для добавления столбца, который аннулируют разрешения номер версии остается таким же.
Несовместимые обновления. При добавлении непустых столбцов (что начальные значения потребности) или изменение фундаментальной формы таблиц или типов данных столбцов, Вы вносите большое изменение, и у Вас есть сценарий миграции.
Обратите внимание, что старые данные остаются на месте, пока явно не отброшено в конце процедуры изменения. Необходимо запустить тесты, чтобы гарантировать, что все работало.
У Вас могло бы быть отбрасывание с двумя частями - сначала переименовывают, затем (неделю спустя) наконец отбрасывают.
Удостоверьтесь, что Ваш инструмент O/R-Mapping может создать необходимые таблицы из конфигурации по умолчанию, которую он имеет, и также добавьте недостающие столбцы. Это должно покрыть 90% Ваших случаев.
Другие 10%
- преодоление отсутствующих значений для столбцов, что, где добавлено после того, как данные были вставлены
- запишите сценарии миграции данных для редкого случая, где необходимо сделать более коренные изменения между версиями
См. проект с открытым исходным кодом DBDeploy. http://dbdeploy.com/
Это позволяет Вам регистрироваться в сценариях изменения базы данных. Это затем произведет объединенный сценарий изменения включая все изменения, которые не были применены. Сайт описывает процесс вполне прилично.
Этот проект основан на методах в статье Martin Fowler, которая была упомянута прежде. Я был на проекте, о котором Martin основывал статью. DbDeploy является довольно хорошей реализацией процесса, который мы использовали.
The migrations facility of Ruby on Rails was developed to handle exactly this need. If you're not using Rails for your application, you might see if this same concept has been ported to the framework of your choice, or read up on it and determine whether you could write some quick scripts that implement the same sort of functionality.