Различия

Показаны различия между двумя версиями страницы.

--- lss-server-php:db-datastructure-versionscript [2025/12/29 12:33] – [Требования к версион-скриптам] madmin
+++ lss-server-php:db-datastructure-versionscript [2026/06/15 16:36] (текущий) – [Написание версион-скриптов] madmin
@@ Строка 1: / Строка 1: @@
 ====== Технология внесения изменений в структуру базы данных ======
-В настоящий момент серверная платформа LSS лучше всего адаптирована для совместной работы с SQL сервером Postgresql. На его примере и рассмотрим внесение изменений в структуру БД.
+В настоящий момент полноценно реализована поддержка серверов **PostgreSql** и **SQlite**. На их примере и рассмотрим внесение изменений в структуру БД.
 ===== Первоначальное создание базы данных =====
-Необходимо создать пустую БД и прогнать на ней скрипт pgsql-systable.sql, см [[db-datastructure-postgresql]].
+Необходимо создать пустую БД и выполнить на ней скрипты создания и инициализации системных таблиц
+  * для **PostgreSql** скрипты **pgsql-systable-create.sql** и **pgsql-systable-init.sql**, см [[db-datastructure-postgresql]].
+  * для **SQlite** скрипты **sqlite-systable-create.sql** и **sqlite-systable-init.sql**, см [[db-datastructure-sqlite]].
 ===== Режим локальной разработки =====
 Существует несколько конкурирующих технологий совместной работы команды программистов над проектом.
@@ Строка 8: / Строка 11: @@
 В настоящий момент наиболее проработанная технология - **режим локальной работы**. Разберем его подробнее.
-В этом режиме есть 3 разновидности **ролей** для серверов, в данном случае под сервером мы понимаем сочетание **SQL сервера** PostGreSQL, **базы данных** и комплекта ПО **бизнес логики** проекта.
+В этом режиме есть 3 разновидности **ролей** для серверов, в данном случае под сервером мы понимаем сочетание **SQL сервера**, **базы данных** и комплекта ПО **бизнес логики** проекта.
   * Роль сервера **local** - компьютер разработчика. Каждый разработчик работает со своей копией БД, разработчики обмениваются между собой изменениями через git.
   * Роль сервера **dev** - эталонный общий сервер команды разработчиков. На нем развернут последний актуальный релиз ПО проекта. Именно на нем следует править содержимое системных таблиц.
@@ Строка 23: / Строка 26: @@
 ==== Внесение изменений в структуру базы данных ====
-Для внесения изменений в структуру базы данных используется технология версион-скриптов. Каждый скрипт оформляется в виде отдельного файла. Программисты обмениваются этими файлами через git.
+Для внесения изменений в структуру базы данных используется технология **версион-скриптов**. Каждый скрипт оформляется в виде отдельного файла. Программисты обмениваются этими файлами через git.
-В меню проекта: "Разработка/Утилиты" присутствует утилита "Актуализация базы данных". При ее запуске последовательно, в алфавитном порядке, выполняются файлы версион-скриптов, ранее не выполнявшиеся на этой базе данных. Имя каждого выполненного файла запоминается в БД (таблица **sysdbversion**), и потом файлы с такими, сохраненными именами, больше не запускаются.
+В меню проекта: "Разработка/Утилиты" присутствует утилита "Актуализация базы данных". При ее запуске последовательно, в алфавитном порядке, выполняются файлы **версион-скриптов**, ранее не выполнявшиеся на этой базе данных. Имя каждого выполненного файла запоминается в БД (таблица **sysdbversion**), и потом файлы с такими, сохраненными именами, больше не запускаются.
-После выполнения всех новых версион-скриптов структура БД становится актуальной.
+После выполнения всех новых **версион-скриптов** структура БД становится актуальной.
 Помимо актуальной **структуры**, база данных должна быть наполнена актуальным **содержимым** системных таблиц. Содержимое системных таблиц правится на сервере **dev**, затем с помощью утилиты "Экспорт системных справочников в виде SQL скрипта" формируется скрипт, актуализирующий содержимое системных таблиц. Для гарантии его корректной работы структура БД должна быть актуальна. Соответственно, сначала необходимо выполнить утилиту "Актуализация базы данных", а затем скрипт, обновляющий содержимое системных таблиц.
-==== Требования к версион-скриптам ====
+==== Написание версион-скриптов ====
   * версион-скрипты это **файлы**, содержащие **sql запросы** по внесению изменений в структуру и содержимое БД
-  * важен **порядок** выполнения версион-скриптов, скрипты выполняются в алфавитном порядке. Имена файлов стандартизированы из соображений того, что-бы позже написанные скрипты выполнялись позже. Таким образом файлы именуются как: <script>YYYY-MM-DD-HH-II-<команда разработчиков>-<разработчик>.sql</script>.
+  * важен **порядок** выполнения версион-скриптов, скрипты выполняются в алфавитном порядке. Имена файлов стандартизированы из соображений того, что-бы позже написанные скрипты выполнялись позже. Таким образом файлы именуются: <code>YYYY-MM-DD-HH-II-<команда разработчиков>-<разработчик>.sql</code>
+  * нельзя вносить изменения в версион-скрипт после того, как он откинут в ветку git, предназначенную для совместной работы
+  * SQL код версион-скриптов выполняется в **режиме репликации**, при этом отключены все constraint, в том числе проверка ссылочной целостности и каскадные удаления.
+  * Для **PostgreSQL** удаление или изменение типа существующих полей таблицы в версион-скрипте может не сработать из-за наличия связанного с таблицей view представления. Для решения проблемы служит вызов процедуры: <code>call cmd_dropviews('имя таблицы');</code> эта процедура удаляет все автоматически формируемые представления view для заданной таблицы. Для **SQlite** такой проблемы нет.
 ==== Подведем итоги ====
 В режиме **локальной разработки**: