====== Технология внесения изменений в структуру базы данных ======
В настоящий момент серверная платформа LSS лучше всего адаптирована для совместной работы с SQL сервером Postgresql. На его примере и рассмотрим внесение изменений в структуру БД.
===== Первоначальное создание базы данных =====
Необходимо создать пустую БД и выполнить на ней скрипт pgsql-systable.sql, см [[db-datastructure-postgresql]].
===== Режим локальной разработки =====
Существует несколько конкурирующих технологий совместной работы команды программистов над проектом.

В настоящий момент наиболее проработанная технология - **режим локальной работы**. Разберем его подробнее.

В этом режиме есть 3 разновидности **ролей** для серверов, в данном случае под сервером мы понимаем сочетание **SQL сервера** PostGreSQL, **базы данных** и комплекта ПО **бизнес логики** проекта.
  * Роль сервера **local** - компьютер разработчика. Каждый разработчик работает со своей копией БД, разработчики обмениваются между собой изменениями через git.
  * Роль сервера **dev** - эталонный общий сервер команды разработчиков. На нем развернут последний актуальный релиз ПО проекта. Именно на нем следует править содержимое системных таблиц.
  * Роль сервера **prod** - сервер развернут у заказчика (заказчиков может быть несколько, у каждого свой сервер), БД содержит ценные пользовательские данные, версия ПО проекта не самая последняя, свободный доступ программистов к серверу ограничен.

Для работы в режиме **локальной работы** необходимо в конфигурационных настройках задать:
<code>
/// Локальный режим работы разработчика с сервером БД
$config['sqlLocalMode']=true;
/// Роль подключаемого сервера БД: local|dev|prod
$config['sqlServerRole']='local';
</code>

==== Внесение изменений в структуру базы данных ====

Для внесения изменений в структуру базы данных используется технология **версион-скриптов**. Каждый скрипт оформляется в виде отдельного файла. Программисты обмениваются этими файлами через git.

В меню проекта: "Разработка/Утилиты" присутствует утилита "Актуализация базы данных". При ее запуске последовательно, в алфавитном порядке, выполняются файлы **версион-скриптов**, ранее не выполнявшиеся на этой базе данных. Имя каждого выполненного файла запоминается в БД (таблица **sysdbversion**), и потом файлы с такими, сохраненными именами, больше не запускаются.

После выполнения всех новых **версион-скриптов** структура БД становится актуальной.

Помимо актуальной **структуры**, база данных должна быть наполнена актуальным **содержимым** системных таблиц. Содержимое системных таблиц правится на сервере **dev**, затем с помощью утилиты "Экспорт системных справочников в виде SQL скрипта" формируется скрипт, актуализирующий содержимое системных таблиц. Для гарантии его корректной работы структура БД должна быть актуальна. Соответственно, сначала необходимо выполнить утилиту "Актуализация базы данных", а затем скрипт, обновляющий содержимое системных таблиц.
==== Написание версион-скриптов ====
  * версион-скрипты это **файлы**, содержащие **sql запросы** по внесению изменений в структуру и содержимое БД
  * важен **порядок** выполнения версион-скриптов, скрипты выполняются в алфавитном порядке. Имена файлов стандартизированы из соображений того, что-бы позже написанные скрипты выполнялись позже. Таким образом файлы именуются: <code>YYYY-MM-DD-HH-II-<команда разработчиков>-<разработчик>.sql</code>
  * нельзя вносить изменения в версион-скрипт после того, как он откинут в ветку git, предназначенную для совместной работы
  * SQL код версион-скриптов выполняется в **режиме репликации**, при этом отключены все constraint, в том числе проверка ссылочной целостности и каскадные удаления.
  * удаление или изменение типа существующих полей таблицы в версион-скрипте может не сработать из-за наличия связанного с таблицей view представления. Для решения проблемы служит вызов процедуры: <code>call cmd_dropviews('имя таблицы');</code> эта процедура удаляет все автоматически формируемые представления view для заданной таблицы.
==== Подведем итоги ====
В режиме **локальной разработки**:
  * каждый разработчик работает как со своей, независимой копией БД, так и со своей копией ПО слоя бизнес логики
  * обмен изменениями между разработчиками происходит через git
  * внесение изменений в структуру БД оформлено в виде файлов версион-скриптов, разработчики ими обмениваются между собой через git, аналогично другим исходникам проекта
  * после каждой синхронизаций git необходимо прогонять утилиту "Актуализация базы данных" для актуализации структуры БД
  * содержимое системных таблиц правится на сервере **dev**. Разработчик должен периодически актуализировать у себя содержимое системных таблиц, прогоняя sql скрипт, сформированный утилитой "Экспорт системных справочников в виде SQL скрипта" запускаемой на сервере **dev**