Какова цель (или полезность) таблицы версий данных / приложений в базе данных?

#database-design #architecture #versioning #application-design

#database-design #архитектура #управление версиями #дизайн приложения

Вопрос:

Это вопрос дизайна.

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

Например, следующий DDL…

 CREATE TABLE
  [dbo].[Version]
  (
    FreshnessDate DATETIME,
    DatabaseVersion VARCHAR(10),
    ApplicationVersion VARCHAR(10)
  )
  

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

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

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

У меня лично есть аргументы в пользу этого, но мне нужны советы и отзывы о том, является ли добавление такой таблицы чрезмерным инженерным.

Спасибо!

Ответ №1:

На нашей стороне мы получили такую таблицу, и у нас есть автоматическая миграция на основе этой таблицы — обновления схемы, миграции схемы. Мы получили дополнительное поле — ссылку на файл. Таким образом, в нашем рабочем процессе невозможно существовать без такой таблицы. Данные таблицы также поддерживаются автоматически.

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

Я скорее удаляю ее на основе вашего рабочего процесса.

  • минусы поддерживают таблицу автоматически во время развертывания
  • минусы дополнительной новой таблицы на сервере БД
  • история плюсов, какую версию приложения использует какая версия базы данных

Комментарии:

1. Спасибо. Я думаю, мы пропустим создание этой таблицы. Я думаю, однако, что вы имели в виду «поддерживать таблицу вручную во время развертывания» в качестве своего первого кона. Эта таблица действительно должна обрабатываться автоматически во время непрерывной интеграции и непрерывных циклов выпуска.