ამ სტატიის მიზანია ბიბლიოთეკის მაგალითის გამოყენება სქემის მეკარე აჩვენეთ ინსტრუმენტები, რომლებსაც შეუძლიათ მნიშვნელოვნად გაამარტივონ მონაცემთა ბაზების შემუშავების პროცესი PHP პროექტებში PostgreSQL DBMS-ის გამოყენებით.

ამ სტატიიდან მიღებული ინფორმაცია, უპირველეს ყოვლისა, სასარგებლო იქნება დეველოპერებისთვის, რომლებსაც სურთ PostgreSQL შესაძლებლობების მაქსიმალურად გამოყენება, მაგრამ მონაცემთა ბაზაში განთავსებული ბიზნეს ლოგიკის შენარჩუნების პრობლემების წინაშე დგანან.

ეს სტატია არ აღწერს ბიზნეს ლოგიკის მონაცემთა ბაზაში შენახვის უპირატესობებსა თუ ნაკლოვანებებს. ვარაუდობენ, რომ არჩევანი მკითხველმა უკვე გააკეთა.

განიხილება შემდეგი კითხვები:

1. რა ფორმით უნდა იყოს შენახული მონაცემთა ბაზის სტრუქტურის ნაგავსაყრელი ვერსიის კონტროლის სისტემაში (შემდგომში VCS)
2. როგორ აკონტროლოთ ცვლილებები მონაცემთა ბაზის სტრუქტურაში ნაგავსაყრელის შენახვის შემდეგ
3. როგორ გადავიტანოთ ცვლილებები მონაცემთა ბაზის სტრუქტურაში სხვა გარემოში კონფლიქტებისა და გიგანტური მიგრაციის ფაილების გარეშე
4. როგორ მოვაწყოთ რამდენიმე დეველოპერის პროექტზე პარალელური მუშაობის პროცესი
5. როგორ უსაფრთხოდ განათავსოთ მონაცემთა ბაზის სტრუქტურაში მეტი ცვლილებები საწარმოო გარემოში
   

   SchemaKeeper შექმნილია ენაზე დაწერილ შენახულ პროცედურებთან მუშაობისთვის PL/pgSQL. სხვა ენებზე ტესტირება არ ჩატარებულა, ამიტომ გამოყენება შეიძლება არ იყოს ეფექტური ან შეუძლებელი.

როგორ შევინახოთ მონაცემთა ბაზის სტრუქტურის ნაგავსაყრელი VCS-ში

ბიბლიოთეკა სქემის მეკარე უზრუნველყოფს ფუნქციას saveDump, რომელიც ინახავს ყველა ობიექტის სტრუქტურას მონაცემთა ბაზიდან ცალკე ტექსტურ ფაილებად. გამომავალი არის დირექტორია, რომელიც შეიცავს მონაცემთა ბაზის სტრუქტურას, დაყოფილია დაჯგუფებულ ფაილებად, რომლებიც ადვილად შეიძლება დაემატოს VCS-ს.

მოდით შევხედოთ ობიექტების მონაცემთა ბაზიდან ფაილებად გადაქცევას რამდენიმე მაგალითის გამოყენებით:

ობიექტის ტიპი
სქემა
სახელი
ფაილის შედარებითი გზა

მაგიდა
საჯარო
ანგარიშები
./public/tables/accounts.txt

შენახული პროცედურა
საჯარო
auth (ჰეშ ბიგიტი)
./public/functions/auth(int8).sql

შესავალი
დაჯავშნა
ტარიფები
./booking/views/tariffs.txt

ფაილების შინაარსი წარმოადგენს მონაცემთა ბაზის კონკრეტული ობიექტის სტრუქტურის ტექსტურ წარმოდგენას. მაგალითად, შენახული პროცედურებისთვის, ფაილის შინაარსი იქნება შენახული პროცედურის სრული განმარტება, დაწყებული ბლოკით. CREATE OR REPLACE FUNCTION.

როგორც ზემოთ მოყვანილი ცხრილიდან ჩანს, ფაილის გზა ინახავს ინფორმაციას ობიექტის ტიპის, სქემისა და სახელის შესახებ. ეს მიდგომა აადვილებს მონაცემთა ბაზაში ცვლილებების ნაგავსაყრელისა და კოდის მიმოხილვის ნავიგაციას.

გაფართოება .sql შენახული პროცედურების წყაროს კოდის მქონე ფაილებისთვის, ეს შეირჩა ისე, რომ IDE ავტომატურად უზრუნველყოფს მონაცემთა ბაზასთან ურთიერთქმედების ინსტრუმენტებს ფაილის გახსნისას.

როგორ აკონტროლოთ ცვლილებები მონაცემთა ბაზის სტრუქტურაში ნაგავსაყრელის შენახვის შემდეგ

მონაცემთა ბაზის მიმდინარე სტრუქტურის ნაგავსაყრელის VCS-ში შენახვით, ჩვენ ვიღებთ შესაძლებლობას შევამოწმოთ, განხორციელდა თუ არა ცვლილებები მონაცემთა ბაზის სტრუქტურაში ნაგავსაყრელის შექმნის შემდეგ. ბიბლიოთეკაში სქემის მეკარე მონაცემთა ბაზის სტრუქტურაში ცვლილებების აღმოსაჩენად, მოცემულია ფუნქცია verifyDump, რომელიც აბრუნებს ინფორმაციას განსხვავებების შესახებ გვერდითი ეფექტების გარეშე.

შემოწმების ალტერნატიული გზაა ფუნქციის ხელახლა გამოძახება saveDump, მიუთითეთ იგივე დირექტორია და შეამოწმეთ VCS-ში ცვლილებებისთვის. ვინაიდან მონაცემთა ბაზიდან ყველა ობიექტი ინახება ცალკეულ ფაილებში, VCS აჩვენებს მხოლოდ შეცვლილ ობიექტებს.
ამ მეთოდის მთავარი მინუსი არის ფაილების გადაწერის საჭიროება ცვლილებების სანახავად.

როგორ გადავიტანოთ ცვლილებები მონაცემთა ბაზის სტრუქტურაში სხვა გარემოში კონფლიქტებისა და გიგანტური მიგრაციის ფაილების გარეშე

ფუნქციის წყალობით deployDump შენახული პროცედურების საწყისი კოდი შეიძლება რედაქტირდეს ზუსტად ისე, როგორც ჩვეულებრივი აპლიკაციის წყაროს კოდი. თქვენ შეგიძლიათ დაამატოთ/წაშალოთ ახალი სტრიქონები შენახულ პროცედურების კოდში და დაუყოვნებლივ დააყენოთ ცვლილებები ვერსიის კონტროლში, ან შექმნათ/წაშალოთ შენახული პროცედურები შესაბამისი ფაილების შექმნით/წაშლით dump დირექტორიაში.

მაგალითად, სქემაში ახალი შენახული პროცედურის შესაქმნელად 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-ში თითოეული ფილიალი შეიცავს ნაგავსაყრელის საკუთარ ვერსიას და ფილიალების გაერთიანებისას, ნაგავსაყრელები გაერთიანდება. უმეტეს შემთხვევაში, შერწყმის შემდეგ დამატებითი ქმედებები არ არის საჭირო, მაგრამ თუ ცვლილებები განხორციელდა სხვადასხვა ფილიალში, მაგალითად, იმავე მაგიდაზე, შეიძლება წარმოიშვას კონფლიქტი.

განვიხილოთ კონფლიქტური სიტუაცია მაგალითის გამოყენებით: არის ფილიალი შემუშავება, საიდანაც განშტოება ორი ტოტი: ფუნქცია 1 и ფუნქცია 2, რომელთანაც არანაირი კონფლიქტი არ არის შემუშავება, მაგრამ აქვთ კონფლიქტები ერთმანეთთან. ამოცანაა ორივე ტოტის გაერთიანება შემუშავება. ამ შემთხვევაში რეკომენდირებულია ჯერ ერთ-ერთი ტოტის გაერთიანება შემუშავებადა შემდეგ შერწყმა შემუშავება დანარჩენ ფილიალში, კონფლიქტების გადაწყვეტა დანარჩენ ფილიალში და შემდეგ შერწყმა ბოლო ფილიალში შემუშავება. კონფლიქტის მოგვარების ფაზაში შეიძლება მოგიწიოთ მიგრაციის ფაილის ბოლო ფილიალში დაფიქსირება ისე, რომ ის შეესაბამებოდეს საბოლოო ნაგავსაყრელს, რომელიც მოიცავს გაერთიანების შედეგებს.

როგორ უსაფრთხოდ განათავსოთ მონაცემთა ბაზის სტრუქტურაში მეტი ცვლილებები საწარმოო გარემოში

VCS-ში არსებული მონაცემთა ბაზის სტრუქტურის ნაგავსაყრელის არსებობის წყალობით, შესაძლებელი ხდება წარმოების მონაცემთა ბაზის შემოწმება საჭირო სტრუქტურასთან ზუსტი შესაბამისობისთვის. ეს უზრუნველყოფს, რომ ყველა ცვლილება, რომელიც დეველოპერებმა განიზრახეს, წარმატებით გადაიტანეს საწარმოო ბაზაზე.

როგორც DDL PostgreSQL-ში არის ტრანზაქციულირეკომენდირებულია დაიცვან შემდეგი განლაგების ბრძანება, რათა მოულოდნელი შეცდომის შემთხვევაში „უმტკივნეულოდ“ შეასრულოთ ROLLBACK:

1. გარიგების დაწყება
2. შეასრულეთ ყველა მიგრაცია ტრანზაქციაში
3. იმავე გარიგებაში, შეასრულეთ deployDump
4. ტრანზაქციის დასრულების გარეშე, შეასრულეთ verifyDump. თუ შეცდომები არ არის, გაუშვით COMMIT. თუ არის შეცდომები, გაუშვით ROLLBACK

ეს ნაბიჯები შეიძლება ადვილად იყოს ინტეგრირებული აპლიკაციის განლაგების არსებულ მიდგომებში, ნულოვანი შეფერხების ჩათვლით.

დასკვნა

ზემოთ აღწერილი მეთოდების წყალობით, შესაძლებელია „PHP + PostgreSQL“ პროექტებიდან მაქსიმალური ეფექტურობის გამორთვა, ხოლო განვითარების შედარებით მცირე მოხერხებულობის შეწირვა აპლიკაციის ძირითად კოდში ყველა ბიზნეს ლოგიკის დანერგვასთან შედარებით. უფრო მეტიც, მონაცემთა დამუშავება ქ PL/pgSQL ხშირად გამოიყურება უფრო გამჭვირვალე და მოითხოვს ნაკლებ კოდს, ვიდრე იგივე ფუნქციონირება დაწერილი PHP-ში.

წყარო: www.habr.com