આ લેખનો હેતુ પુસ્તકાલયના ઉદાહરણનો ઉપયોગ કરવાનો છે સ્કીમા-કીપર ટૂલ્સ બતાવો કે જે PostgreSQL DBMS નો ઉપયોગ કરીને PHP પ્રોજેક્ટ્સમાં ડેટાબેઝ વિકસાવવાની પ્રક્રિયાને નોંધપાત્ર રીતે સરળ બનાવી શકે.

આ લેખની માહિતી, સૌ પ્રથમ, એવા વિકાસકર્તાઓ માટે ઉપયોગી થશે જેઓ PostgreSQL ક્ષમતાઓનો મહત્તમ ઉપયોગ કરવા માગે છે, પરંતુ ડેટાબેઝમાં મૂકવામાં આવેલા વ્યવસાયના તર્કને જાળવવામાં સમસ્યાઓનો સામનો કરી રહ્યા છે.

આ લેખ ડેટાબેઝમાં બિઝનેસ લોજિક સ્ટોર કરવાના ફાયદા અથવા ગેરફાયદાનું વર્ણન કરશે નહીં. એવું માનવામાં આવે છે કે પસંદગી વાચક દ્વારા પહેલેથી જ કરવામાં આવી છે.

નીચેના પ્રશ્નો ધ્યાનમાં લેવામાં આવશે:

1. વર્ઝન કંટ્રોલ સિસ્ટમમાં ડેટાબેઝ સ્ટ્રક્ચર ડમ્પ કયા સ્વરૂપમાં સંગ્રહિત થવો જોઈએ (ત્યારબાદ VCS તરીકે ઓળખવામાં આવે છે)
2. ડમ્પ સેવ કર્યા પછી ડેટાબેઝ સ્ટ્રક્ચરમાં થતા ફેરફારોને કેવી રીતે ટ્રૅક કરવા
3. સંઘર્ષો અને વિશાળ સ્થળાંતર ફાઇલો વિના ડેટાબેઝ માળખામાં ફેરફારોને અન્ય વાતાવરણમાં કેવી રીતે સ્થાનાંતરિત કરવું
4. કેટલાક વિકાસકર્તાઓ દ્વારા પ્રોજેક્ટ પર સમાંતર કાર્યની પ્રક્રિયા કેવી રીતે ગોઠવવી
5. ઉત્પાદન પર્યાવરણમાં ડેટાબેઝ સ્ટ્રક્ચરમાં વધુ ફેરફારોને સુરક્ષિત રીતે કેવી રીતે જમાવવું
   

   સ્કીમકીપર ભાષામાં લખેલી સંગ્રહિત પ્રક્રિયાઓ સાથે કામ કરવા માટે રચાયેલ છે 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 સંગ્રહિત પ્રક્રિયાઓનો સ્રોત કોડ નિયમિત એપ્લિકેશન સ્રોત કોડની જેમ બરાબર એ જ રીતે સંપાદિત કરી શકાય છે. તમે સંગ્રહિત પ્રક્રિયા કોડમાં નવી રેખાઓ ઉમેરી/કાઢી શકો છો અને તરત જ સંસ્કરણ નિયંત્રણમાં ફેરફારોને દબાણ કરી શકો છો, અથવા ડમ્પ ડિરેક્ટરીમાં અનુરૂપ ફાઇલો બનાવી/ડીલીટ કરીને સંગ્રહિત પ્રક્રિયાઓ બનાવી/કાઢી શકો છો.

ઉદાહરણ તરીકે, સ્કીમામાં નવી સંગ્રહિત પ્રક્રિયા બનાવવા માટે 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. કાર્ય પૂર્ણ કર્યા પછી, વિકાસકર્તા ફંક્શનને કૉલ કરે છે saveDumpVCS માં ડેટાબેઝમાં કરેલા ફેરફારો કરવા માટે
4. વિકાસકર્તા ફરીથી લોંચ કરો refresh.shપછી verifyDumpજે હવે સ્થાનાંતરણમાં સમાવવા માટેના ફેરફારોની યાદી બતાવે છે
5. ડેવલપર તમામ સ્ટ્રક્ચર ફેરફારોને સ્થળાંતર ફાઇલમાં સ્થાનાંતરિત કરે છે, ફરીથી ચાલે છે refresh.sh и verifyDump, અને, જો સ્થળાંતર યોગ્ય રીતે સંકલિત થયેલ છે, verifyDump સ્થાનિક ડેટાબેઝ અને સાચવેલ ડમ્પ વચ્ચે કોઈ તફાવત બતાવશે નહીં

ઉપર વર્ણવેલ પ્રક્રિયા ગિટફ્લો સિદ્ધાંતો સાથે સુસંગત છે. VCS માં દરેક શાખામાં ડમ્પનું પોતાનું સંસ્કરણ હશે, અને જ્યારે શાખાઓ મર્જ કરવામાં આવશે, ત્યારે ડમ્પ્સ મર્જ કરવામાં આવશે. મોટા ભાગના કિસ્સાઓમાં, મર્જ કર્યા પછી કોઈ વધારાના પગલાં લેવાની જરૂર નથી, પરંતુ જો વિવિધ શાખાઓ પર ફેરફારો કરવામાં આવ્યા હોય, ઉદાહરણ તરીકે સમાન ટેબલ પર, તો સંઘર્ષ ઊભો થઈ શકે છે.

ચાલો ઉદાહરણનો ઉપયોગ કરીને સંઘર્ષની પરિસ્થિતિને ધ્યાનમાં લઈએ: ત્યાં એક શાખા છે વિકાસ, જેમાંથી બે શાખાઓ શાખા: લક્ષણ 1 и લક્ષણ 2, જેની સાથે કોઈ તકરાર નથી વિકાસ, પરંતુ એકબીજા સાથે તકરાર છે. કાર્ય બંને શાખાઓને મર્જ કરવાનું છે વિકાસ. આ કિસ્સામાં, પ્રથમ શાખાઓમાંથી એકને મર્જ કરવાની ભલામણ કરવામાં આવે છે વિકાસઅને પછી મર્જ કરો વિકાસ બાકીની શાખામાં, બાકીની શાખામાં તકરાર ઉકેલવા, અને પછી છેલ્લી શાખાને તેમાં મર્જ કરવી વિકાસ. સંઘર્ષના નિરાકરણના તબક્કા દરમિયાન, તમારે છેલ્લી શાખામાં સ્થાનાંતરણ ફાઇલને ઠીક કરવી પડી શકે છે જેથી કરીને તે અંતિમ ડમ્પ સાથે મેળ ખાય, જેમાં મર્જના પરિણામોનો સમાવેશ થાય છે.

ઉત્પાદન પર્યાવરણમાં ડેટાબેઝ સ્ટ્રક્ચરમાં વધુ ફેરફારોને સુરક્ષિત રીતે કેવી રીતે જમાવવું

VCS માં વર્તમાન ડેટાબેઝ માળખાના ડમ્પની હાજરી માટે આભાર, જરૂરી માળખા સાથે ચોક્કસ પાલન માટે ઉત્પાદન ડેટાબેઝ તપાસવું શક્ય બને છે. આ સુનિશ્ચિત કરે છે કે વિકાસકર્તાઓ દ્વારા ઇચ્છિત તમામ ફેરફારો સફળતાપૂર્વક ઉત્પાદન આધાર પર સ્થાનાંતરિત થયા હતા.

ત્યારથી ડીડીએલ PostgreSQL માં છે વ્યવહારિક, નીચેના ડિપ્લોયમેન્ટ ઓર્ડરનું પાલન કરવાની ભલામણ કરવામાં આવે છે, જેથી કરીને, અણધારી ભૂલના કિસ્સામાં, તમે "પીડા વિના" એક્ઝિક્યુટ કરી શકો ROLLBACK:

1. વ્યવહાર શરૂ કરો
2. વ્યવહારમાં તમામ સ્થળાંતર કરો
3. સમાન વ્યવહારમાં, એક્ઝિક્યુટ કરો deployDump
4. વ્યવહાર પૂર્ણ કર્યા વિના, ચલાવો verifyDump. જો ત્યાં કોઈ ભૂલો નથી, તો ચલાવો COMMIT. જો ત્યાં ભૂલો હોય, તો ચલાવો ROLLBACK

શૂન્ય-ડાઉનટાઇમ સહિત, એપ્લિકેશન જમાવટ માટેના હાલના અભિગમોમાં આ પગલાં સરળતાથી સંકલિત કરી શકાય છે.

નિષ્કર્ષ

ઉપરોક્ત વર્ણવેલ પદ્ધતિઓનો આભાર, મુખ્ય એપ્લિકેશન કોડમાં તમામ વ્યવસાયિક તર્કને અમલમાં મૂકવાની તુલનામાં પ્રમાણમાં ઓછી વિકાસ સુવિધાને બલિદાન આપતી વખતે, "PHP + PostgreSQL" પ્રોજેક્ટ્સમાંથી મહત્તમ પ્રદર્શનને સ્ક્વિઝ કરવું શક્ય છે. વધુમાં, ડેટા પ્રોસેસિંગમાં PL/pgSQL ઘણીવાર વધુ પારદર્શક દેખાય છે અને PHP માં લખેલી સમાન કાર્યક્ષમતા કરતાં ઓછા કોડની જરૂર પડે છે.

સોર્સ: www.habr.com