Целта на тази статия е на примера на библиотека пазач на схема показват инструменти, които могат значително да улеснят процеса на разработване на бази данни в PHP проекти с помощта на СУБД PostgreSQL.

Информацията от тази статия, на първо място, ще бъде полезна за разработчиците, които искат да използват максимално възможностите на PostgreSQL, но са изправени пред проблемите с поддържането на бизнес логиката, поставена в базата данни.

Статията няма да описва предимствата или недостатъците на съхраняването на бизнес логика в база данни. Предполага се, че изборът вече е направен от читателя.

Ще бъдат разгледани следните въпроси:

1. В каква форма да се съхранява дъмпът на структурата на базата данни в системата за контрол на версиите (наричана по-нататък VCS)
2. Как да проследите промените в структурата на базата данни след запазване на дъмпа
3. Как да прехвърлите промените в структурата на базата данни в други среди без конфликти и огромни файлове за миграция
4. Как да настроите процеса на паралелна работа по проект на няколко разработчици
5. Как безопасно да внедрите повече промени в структурата на базата данни в производствената среда
   

   SchemaKeeper заточени за работа със съхранени процедури, написани на езика PL/pgSQL. Тестване с други езици не е провеждано, следователно използването може да не е толкова ефективно или невъзможно.

Как да съхранявате дъмп на структура на база данни във VCS

Библиотека пазач на схема осигурява функция saveDump, който запазва структурата на всички обекти от базата данни като отделни текстови файлове. Резултатът създава директория, съдържаща структурата на базата данни, разделена на групирани файлове, които лесно се добавят към VCS.

Помислете за конвертиране на обекти от база данни във файлове, като използвате няколко примера:

Тип обект
Схемата
Име
Относителен път на файла

маса
обществен
сметки
./public/tables/accounts.txt

Съхранена процедура
обществен
auth (хеш bigint)
./public/functions/auth(int8).sql

идея
резервация
тарифи
./booking/views/tariffs.txt

Съдържанието на файловете е текстово представяне на структурата на конкретен обект на база данни. Например, за съхранени процедури, съдържанието на файла ще бъде пълната дефиниция на съхранената процедура, започваща с блока CREATE OR REPLACE FUNCTION.

Както се вижда от горната таблица, пътят до файла съдържа информация за типа, схемата и името на обекта. Този подход улеснява навигацията през дъмпа и прегледа на кода на промените в базата данни.

разширение .sql за файлове с изходен код на съхранени процедури е избрано така, че IDE автоматично да предоставя инструменти за взаимодействие с базата данни, когато файлът бъде отворен.

Как да проследите промените в структурата на базата данни след запазване на дъмпа

Като запазим дъмпа на текущата структура на базата данни във VCS, получаваме възможност да проверим дали са направени промени в структурата на базата данни след създаването на дъмпа. В библиотеката пазач на схема за откриване на промени в структурата на базата данни е предвидена функция verifyDump, който връща информация за разликите без странични ефекти.

Алтернативен начин за проверка е повторно извикване на функцията saveDump, като посочите същата директория и проверете VCS за промени. Тъй като всички обекти от базата данни се съхраняват в отделни файлове, VCS ще покаже само променени обекти.
Основният недостатък на този метод е необходимостта от презаписване на файлове, за да се видят промените.

Как да прехвърлите промените в структурата на базата данни в други среди без конфликти и огромни файлове за миграция

Благодарение на функцията deployDump Изходният код на съхранената процедура може да се редактира точно по същия начин като изходния код на обикновеното приложение. Можете да добавяте/изтривате нови редове в кода на запомнената процедура и незабавно да изпращате промени в системата за контрол на версиите или да създавате/изтривате запаметени процедури, като създавате/изтривате съответните файлове в директорията за дъмп.

Например, за да създадете нова съхранена процедура в схемата public просто създайте нов файл с разширение .sql в указателя public/functions, поставете изходния код на съхранената процедура в него, включително блока CREATE OR REPLACE FUNCTION, след това извикайте функцията deployDump. По същия начин има промяна и премахване на съхранена процедура. По този начин кодът едновременно влиза както във VCS, така и в базата данни.

Ако се появи грешка в изходния код на която и да е съхранена процедура или несъответствие между имената на файла и съхранената процедура, тогава deployDump не успее, показвайки текста за грешка. Несъответствието на запомнените процедури между дъмпа и текущата база данни не е възможно при използване deployDump.

Когато създавате нова съхранена процедура, няма нужда да въвеждате ръчно правилното име на файл. Достатъчно е файлът да има разширение .sql. След обаждането deployDump текстът за грешка ще съдържа правилното име, което може да се използва за преименуване на файла.

deployDump ви позволява да промените параметрите на функция или тип връщане без допълнителни стъпки, докато с класическия подход ще трябва да
изпълни първо DROP FUNCTION, и едва тогава CREATE OR REPLACE FUNCTION.

За съжаление има ситуации, в които deployDump не може автоматично да приложи промените. Например, ако се изтрие тригерна функция, която се използва от поне един тригер. Такива ситуации се решават ръчно с помощта на миграционни файлове.

Ако самият той отговаря за прехвърлянето на промените в съхранените процедури пазач на схема, тогава за да прехвърлите останалите промени в структурата, трябва да използвате файловете за миграция. Например добра библиотека за работа с миграции е доктрина/миграции.

Миграциите трябва да се приложат преди стартирането deployDump. Това ви позволява да правите всички промени в структурата и да разрешавате проблемни ситуации, така че промените в съхранените процедури да се прехвърлят по-късно без проблеми.

Работата с миграции ще бъде описана по-подробно в следващите раздели.

Как да настроите процеса на паралелна работа по проект на няколко разработчици

Необходимо е да се създаде пълен скрипт за инициализация на базата данни, който ще бъде стартиран от разработчика на неговата работна машина, привеждайки структурата на локалната база данни в съответствие с дъмпа, записан във VCS. Най-лесният начин е да разделите инициализирането на локалната база данни на 3 стъпки:

1. Импортиране на файл с основна структура, която ще се нарича напр. base.sql
2. Прилагане на миграции
3. повикване deployDump

base.sql е началната точка, върху която се прилагат миграциите и deployDumpТова означава, че base.sql + миграции + deployDump = актуальная структура БД. Можете да генерирате такъв файл с помощта на помощната програма pg_dump. използвани base.sql само при инициализиране на базата данни от нулата.

Нека извикаме пълния скрипт за инициализация на базата данни refresh.sh. Работният процес може да изглежда така:

1. Разработчикът работи в своята среда refresh.sh и получава текущата структура на базата данни
2. Разработчикът започва работа по задачата, модифицирайки локалната база данни, за да отговори на нуждите на новата функционалност (ALTER TABLE ... ADD COLUMN и т.н.)
3. След като задачата е изпълнена, разработчикът извиква функцията saveDumpза да ангажира промените, направени в базата данни към VCS
4. Програмистът стартира отново refresh.sh, тогава verifyDumpкойто сега показва списъка с промени за включване в миграцията
5. Разработчикът прехвърля всички структурни промени във файла за мигриране, стартира отново refresh.sh и verifyDumpи, ако миграцията е компилирана правилно, verifyDump няма да покаже разлики между локалната база данни и запазения дъмп

Процесът, описан по-горе, е съвместим с принципите на gitflow. Всеки клон във VCS ще съдържа своя собствена версия на дъмпа и когато клоновете се слеят, дъмповете ще бъдат обединени. В повечето случаи не са необходими допълнителни действия след сливане, но ако са направени промени в различни клонове, например в една и съща таблица, може да възникне конфликт.

Помислете за конфликтна ситуация, като използвате пример: има клон разработване на, от който се разклоняват два клона: feature1 и feature2, които нямат конфликти с разработване нано имат конфликти помежду си. Задачата е да обедините двата клона в разработване на. За такъв случай се препоръчва първо да обедините един от клоновете разработване наи след това се слеят разработване на към останалия клон, като същевременно разрешава конфликти в оставащия клон и след това обединете последния клон в разработване на. По време на стъпката за разрешаване на конфликти може да се наложи да коригирате файла за мигриране в последния клон, за да съответства на крайния дъмп, който включва сливанията.

Как безопасно да внедрите повече промени в структурата на базата данни в производствената среда

Поради наличието на дъмп на текущата структура на базата данни във VCS, става възможно да се провери производствената база данни за точно съответствие с необходимата структура. Това гарантира, че всички промени, които разработчиците възнамеряват, са успешно прехвърлени в производствената база.

Като DDL в PostgreSQL е транзакционни, се препоръчва да се придържате към следния ред на разгръщане, така че в случай на неочаквана грешка да бъде „безболезнено“ изпълнението ROLLBACK:

1. Започнете транзакция
2. Изпълнете всички миграции в транзакция
3. В същата транзакция изпълнете deployDump
4. Без да завършите транзакцията, изпълнете verifyDump. Ако няма грешки, стартирайте COMMIT. Ако има грешки, стартирайте ROLLBACK

Тези стъпки са сравнително лесни за интегриране в съществуващите подходи за внедряване на приложения, включително нулев престой.

Заключение

Благодарение на горните методи можете да извлечете най-голяма производителност от проектите "PHP + PostgreSQL", като същевременно жертвате относително малко количество удобство за разработка в сравнение с внедряването на цялата бизнес логика в основния код на приложението. Освен това обработка на данни PL/pgSQL често изглежда по-прозрачен и изисква по-малко код от същата функционалност, написана на PHP.

Източник: www.habr.com