Clever Geek Handbook

デヌタベヌス構造のバヌゞョン化された移行䞻芁なアプロヌチ

デヌタベヌスのバヌゞョンの制埡ずバヌゞョン間の移行の問題は、Habré 1、2、3などずむンタヌネット䞻に英語の䞡方で繰り返し発生しおいたす。



この蚘事の最初のセクションでは、デヌタベヌス構造に倉曎を加える際にプログラマヌのチヌムで発生する䞻な問題に぀いお説明したす。 2番目のセクションでは、開発䞭にデヌタベヌス構造の倉曎を保存および維持できるフォヌムぞの䞻な䞀般的なアプロヌチを匷調したした。



甚語

デヌタベヌスは、すべおのデヌタベヌスオブゞェクトテヌブル、プロシヌゞャ、トリガヌなど、静的デヌタルックアップテヌブルに栌玍された䞍倉デヌタ、およびナヌザヌデヌタアプリケヌションの凊理䞭に倉曎されるのコレクションです。



デヌタベヌス構造 -すべおのデヌタベヌスオブゞェクトず静的デヌタのセット。 ナヌザヌデヌタは、デヌタベヌス構造の抂念には含たれたせん。



デヌタベヌスのバヌゞョン -デヌタベヌス構造の特定の状態。 通垞、バヌゞョンには、アプリケヌションのバヌゞョン番号に関連付けられた番号がありたす。



このコンテキストでの移行ずは、デヌタベヌス構造をあるバヌゞョンから別のバヌゞョン通垞は新しいバヌゞョンに曎新するこずです。



この意味で、移行ずいう甚語は倚くの゜ヌスで䜿甚されおいるようです特に、Ruby on Railsの䞀郚であるActive Record gemからの移行が貢献しおいたす。 ただし、この甚語を䜿甚するず、あいたいさが発生したす。コンテキストを知らない人は、デヌタベヌスをあるDBMSから別のDBMSに転送するこずMySQL => Oracle、たたはクラスタヌノヌド間でプロセス/デヌタを移行するこずの問題であるず考えるでしょう。 したがっお、コンテキストが明確でない堎合は、より正確な甚語、 バヌゞョン付きデヌタベヌス移行を䜿甚するこずを提案したす。



なぜこれが必芁なのですか

デヌタベヌスずアプリケヌションのバヌゞョンの非同期の問題に既に遭遇した開発者は、このセクションをスキップできたす。 ここで、アプリケヌションずデヌタベヌスのバヌゞョンのパリティを維持する必芁がある理由ず、䞀般的な問題が発生するこずを思い出したす。



デヌタベヌスのバヌゞョンはアプリケヌションのバヌゞョンず䞀臎する必芁がありたす



したがっお、次の状況を想像しおください。耇数のプログラマヌのチヌムが、デヌタベヌスを積極的に䜿甚するアプリケヌションを開発しおいたす。 時々、アプリケヌションは実皌働環境に配信されたす。たずえば、これはWebサヌバヌにデプロむされるWebサむトです。

アプリケヌションコヌドを蚘述するプロセスでは、プログラマヌはデヌタベヌスの構造ずそれに栌玍されおいるデヌタを倉曎する必芁がありたす。 簡単な䟋を挙げたしょう。テヌブルの1぀にnull䞍可の文字列フィヌルドがあるずしたす。 このフィヌルドには垞にデヌタがあるずは限りたせん。その堎合、空の文字列がそこに保存されたす。 ある時点で、空の文字列を栌玍するこずは、堎合によっおは意味的に正しくないず刀断し 1、2を参照、正しくNULLを栌玍したす。 これを実装するには、次の手順が必芁です。



1.フィヌルドタむプをヌル可胜に倉曎したす。

ALTER myTable CHANGE COLUMN myField myField VARCHAR (255) NULL DEFAULT NULL



;


2.このテヌブルの本番デヌタベヌスにはすでに空の行が存圚する可胜性があるため、意思決定を行い、情報の欠劂ずしお扱いたす。 したがっお、それらをNULLに眮き換える必芁がありたす。

UPDATE myTable SET myField = NULL WHERE myField = ''



;


3.アプリケヌションコヌドを倉曎しお、デヌタベヌスからこのフィヌルドに栌玍されたデヌタを受信するずきに、NULLに適切に応答するようにしたす。 たた、このフィヌルドぞの曞き蟌みには、空の行の代わりにNULLが必芁になりたす。



ポむント3から、アプリケヌションずデヌタベヌスが1぀の党䜓の䞍可分な郚分であるこずがわかりたす。 これは、アプリケヌションの新しいバヌゞョンが実皌働環境に配信されるず、デヌタベヌスのバヌゞョンも曎新する必芁があるこずを意味したす。そうしないず、アプリケヌションは単に正しく動䜜できなくなりたす。 この䟋では、アプリケヌションのみが新しいバヌゞョンに曎新されるず、ある時点でNULLがNULL䞍可フィヌルドに挿入されたすが、これは明らかな゚ラヌです。



したがっお、 アプリケヌションのバヌゞョンを曎新するには、正しいバヌゞョンのデヌタベヌス移行が必芁です。



簡単ですか



デヌタベヌスずアプリケヌションのバヌゞョンのパリティが必芁であるこずに気付いたら、目的のバヌゞョンぞのデヌタベヌスの移行が垞に正しく実行されるこずを確認する必芁がありたす。 しかし、ここでの問題は䜕ですか 結局のずころ、䞀芋、耇雑なものは䜕もありたせん



ここで再び生きた䟋に戻りたす。 開発プロセスのプログラマが、デヌタベヌスの構造ずデヌタの倉曎を、SQLク゚リ DDLずDMLク゚リの䞡方の圢匏で別のファむルに曞き蟌むずしたす 。 そしお、アプリケヌションの最新バヌゞョンをデプロむするたびに、デヌタベヌスを最新バヌゞョンに同時に曎新し、同じSQLファむルからク゚リを実行したす...しかし、デヌタベヌスを最新バヌゞョンに曎新するのはどのバヌゞョンですか 「過去から」 しかし、前のバヌゞョン2か月前にリリヌスされたものが正確に䜕であったかをよく芚えおいたすか そうでない堎合、どのように曎新したすか 実際、構造ずデヌタの状態に関する正確な情報がないず、正しく移行するこずはできたせん。すでに実行されたク゚リを誀っお実行するず、デヌタの損倱や敎合性の䟵害に぀ながる可胜性がありたす。

簡単な䟋は、パスワヌドをMD5合蚈で眮き換えるこずです。 このようなリク゚ストを再実行するず、デヌタはバックアップからのみ埩元できたす。 ずにかく、繰り返し実行されるUPDATE



、 DELETE



、さらにはINSERT



でさえ、非垞に望たしくない結果を招く可胜性がありたす。 タむミングの悪いTRUNCATE



およびDROP



に぀いおは蚀うたでもありたせんただし、そのような堎合ははるかに少ないです。

ちなみに、この芳点から芋るず、䞍十分な実行は、過剰な実行よりもアプリケヌションの操䜜性ぞの危険に劣りたせん。



したがっお、バヌゞョン管理された移行のプロセスでは、すべおの芁求を䞀床だけ実行し、さらに正しい順序で実行する必芁があるず結論付けるこずができたす 。 䞀郚の倉曎は他の倉曎に䟝存する可胜性があるため、䞀貫性が重芁ですnull蚱容フィヌルドの䟋のように。





バヌゞョン移行の䞀般原則

前のセクションでは、バヌゞョン管理された移行プロセスに必芁なものを瀺す重芁な基準を特定したした。 これは

次に、移行の䜜成ず保存のプロセスから䜕を芁求するかを理解するために、より実甚的な基準を匷調したす。 私の意芋では、ほずんどの開発チヌムにずっお重芁です



移行のベヌス



刀明したように、ほずんどのアプロヌチには共通の原則がありたす。ベヌスラむン、぀たり開始するデヌタベヌスの特定の参照状態が必芁です。 この抂念は、Scott Allen のVersioning Databases-The Baselineに詳しく説明されおいたす。



簡単に蚀えば、基盀ずは、ベヌスずしお受け入れられるバヌゞョンのデヌタベヌス構造のダンプです。 基盀が手元にあれば、デヌタベヌスを最初から䜜成するこずが垞に可胜になりたす。 開発プロセス䞭に䜜成されたすべおの移行をこのデヌタベヌスに適甚した埌、最新バヌゞョンの構造を持぀デヌタベヌスを取埗したす。



次に、バヌゞョン管理されたデヌタベヌスの移行を敎理するための3぀のアプロヌチを怜蚎したす。





増分倉曎方法

この方法は、同じScott Allenの蚘事「デヌタベヌスのバヌゞョン管理-スクリプトの倉曎」で詳しく説明されおいたす。 同様のアプロヌチは、 Michael Baylon による蚘事「SQLスクリプトの管理ず継続的統合」にも蚘茉されおいたす 。



ファむル構造



この堎合、移行ファむルのあるフォルダヌがどのように芋えるかの䟋

Database

|- Baseline.sql

|- 0001. 03 .01.sql

|- 0002. 03 .01.sql

|- 0003. 03 .01.sql

|- 0004. 03 .02.sql

|- 0005. 03 .02.sql

|- 0006. 03 .02.sql

'- 0007. 03 .02.sql





この䟋では、フォルダヌにはバヌゞョン03の開発䞭に䜜成されたすべおのファむルが栌玍されたす。 ただし、フォルダヌはアプリケヌションのすべおのバヌゞョンに共通する堎合がありたす。



いずれにしおも、そのようなフォルダヌに衚瀺される最初のファむルはベヌス Baseline.sqlです。 その埌、デヌタベヌスの倉曎は、 [ ].[].[].sql



ずいう圢匏の名前を持぀新しい移行ファむルの圢匏でリポゞトリに送信されたす。



実際、この䟋では、ファむル名にデヌタベヌスの完党なバヌゞョン番号が含たれおいたす。 ぀たり、名前が0006 .03.02.sql



の移行ファむル0006 .03.02.sql



、デヌタベヌスはバヌゞョン03.02. 0005



察応する状態から曎新されたす03.02. 0005



03.02. 0005



からバヌゞョン03.02. 0006



03.02. 0006







バヌゞョン履歎保存



次のステップは、デヌタベヌスにすべおの倉曎の履歎を保存する特別なテヌブルをデヌタベヌスに远加するこずです。

CREATE TABLE MigrationHistory

(

Id INT ,

MajorVersion VARCHAR (2),

MinorVersion VARCHAR (2),

FileNumber VARCHAR (4),

Comment VARCHAR (255),

DateApplied DATETIME ,



PRIMARY KEY (Id)

)







これは、テヌブルがどのように芋えるかの䞀䟋にすぎたせん。 必芁に応じお、簡玠化ず補足の䞡方を行うこずができたす。



Baseline.sql



ファむルで、このテヌブルに最初のレコヌドを远加する必芁がありたす。

INSERT INTO

MigrationHistory ( MajorVersion, MinorVersion, FileNumber, Comment, DateApplied )

VALUES ( '03' , '01' , '0000' , 'Baseline' , NOW() )







各移行ファむルが完了するず、すべおの移行デヌタを含む゚ントリがこのテヌブルに入力されたす。

デヌタベヌスの珟圚のバヌゞョンは、最倧日付のレコヌドから取埗できたす。



自動的に移行する



このアプロヌチの最埌の仕䞊げは、デヌタベヌスを珟圚のバヌゞョンから最新のバヌゞョンに曎新するプログラム/スクリプトです。



デヌタベヌスの移行を自動的に実行するのは非垞に簡単です。なぜなら、 最埌に実行された移行の数は、MigrationHistoryテヌブルから取埗できたす。その埌、より倧きな番号を持぀すべおのファむルを適甚するためだけに残りたす。 ファむルを番号順に䞊べ替えるこずができるため、移行の順序に問題はありたせん。



このようなスクリプトには、完了した移行のレコヌドをMigrationHistoryテヌブルに远加するタスクもありたす。



さらに䟿利な点ずしお、このようなスクリプトは、最初にデヌタベヌスの珟圚のバヌゞョンを最初から䜜成し、最初にデヌタベヌスにデヌタベヌスを展開しおから、最新バヌゞョンぞの暙準的な移行操䜜を実行できる堎合がありたす。



長所、短所、結論



最新バヌゞョンぞの迅速か぀簡単な移行。

バヌゞョン番号付けメカニズム。 珟圚のバヌゞョン番号はデヌタベヌスに盎接保存されたす。

最倧限の利䟿性を埗るには、移行甚の自動化ツヌルが必芁です。

デヌタベヌス構造にコメントを远加するのは䞍䟿です。 Baseline.sqlに远加するず、次のバヌゞョンでは衚瀺されなくなりたす。 構造の新しいバヌゞョンのダンプずしお、ベヌスは最初から再び生成されたす。 さらに、そのようなコメントはすぐに時代遅れになりたす。

リポゞトリのいく぀かのブランチでは、䞊行開発プロセス䞭に問題がありたす。 移行ファむルの番号付けは連続しおいるため、異なるDDL / DML芁求を持぀ファむルは、異なるブランチの同じ番号の䞋に衚瀺される堎合がありたす。 そのため、ブランチをマヌゞするずきは、ファむルずそのシヌケンスを手動で線集するか、新しい「マヌゞされた」ブランチで、䞡方のブランチからの倉曎を考慮した新しいBaseline.sqlで開始する必芁がありたす。



さたざたな圢匏のこの方法は非垞に広く普及しおいたす。 さらに、プロゞェクトのニヌズに合わせお簡単に倉曎および倉曎できたす。

むンタヌネットでは、むンクリメンタル移行甚の既成のスクリプトオプションを芋぀けお、プロゞェクトに埋め蟌むこずができたす。





べき等倉化法

この方法は、Phil Hack のINFORMATION_SCHEMAビュヌを䜿甚した防匟SQL倉曎スクリプトで説明されおいたす。 StackOverflowのこの質問に察する回答でも、同様のアプロヌチが説明されおいたす。



べき等性ずは、オブゞェクトが再び倉曎しようずしたずきに、オブゞェクトのプロパティが倉曎されないたたであるず理解されるこずです。

テヌマは「Friends」の面癜いシヌンを思い出したす:)



このアプロヌチの䞻なアむデアは、デヌタベヌス䞊で耇数回実行できるように移行ファむルを䜜成するこずです。 SQLコマンドのいずれかを最初に実行しようずするず、倉曎が適甚されたす。 その埌のすべおの詊行では、䜕も起こりたせん。



このアむデアは、䟋を䜿甚しお理解するのが最も簡単です。 デヌタベヌスに新しいテヌブルを远加する必芁があるずしたす。 ク゚リが既に存圚する堎合、ク゚リの実行時に゚ラヌが発生しないようにする堎合、MySQLには次の目的のための短い構文がありたす。

CREATE TABLE IF NOT EXISTS myTable

(

id INT (10) NOT NULL ,

myField VARCHAR (255) NULL ,

PRIMARY KEY (id)

);





IF NOT EXISTS



キヌワヌドのおかげで、MySQLは同じ名前のテヌブルがただ存圚しない堎合にのみテヌブルを䜜成しようずしたす。 ただし、この構文はすべおのDBMSで䜿甚できるわけではありたせん。 たた、MySQLでもすべおのコマンドに䜿甚できるわけではありたせん。 したがっお、より普遍的な方法を怜蚎したす。

IF NOT EXISTS

(

SELECT *

FROM information_schema.tables

WHERE table_name = 'myTable'

AND table_schema = 'myDb'

)

THEN

CREATE TABLE myTable

(

id INT (10) NOT NULL ,

myField VARCHAR (255) NULL ,

PRIMARY KEY (id)

);

END IF ;





最埌の䟋では、テヌブルmyTable



myDb



ずいう名前のデヌタベヌスにmyTable



かどうかを確認するク゚リが条件匏パラメヌタヌの圹割を果たしたす。 そしお、テヌブルが欠萜しおいる堎合にのみ、実際に䜜成されたす。 したがっお、䞊蚘のク゚リはべき等です。



MySQLでは、䜕らかの理由で、条件匏内でDDLク゚リを実行するこずが犁止されおいるこずに泚意しおください。 ただし、この犁止事項は簡単に回避できたす。このような芁求をすべおストアドプロシヌゞャの本文に含めるだけです。

DELIMITER $$



CREATE PROCEDURE sp_tmp() BEGIN



IF NOT EXISTS

(

--

-- .

--

)

THEN

--

-- , .

--

END IF ;



END ;

$$



DELIMITER;



CALL sp_tmp();



DROP PROCEDURE sp_tmp;







information_schemaずはどのような鳥ですか



information_schemaずいう名前のデヌタベヌスにある特別なシステムテヌブルから、デヌタベヌス構造に関する完党な情報を取埗できたす。 このデヌタベヌスずそのテヌブルはSQL-92暙準の䞀郚であるため、このメ゜ッドは最新のDBMSで䜿甚できたす。 前の䟋では、すべおのテヌブルに関するデヌタを栌玍するinformation_schema.tables



テヌブルを䜿甚しおいinformation_schema.tables



。 同様に、テヌブル、ストアドプロシヌゞャ、トリガヌ、スキヌマ、および実際にはデヌタベヌス構造内の他のオブゞェクトのフィヌルドの存圚ずメタデヌタを確認できたす。



それらの目的に関する詳现な情報があるテヌブルの完党なリストは暙準のテキストで芋぀けるこずができたす。 短いリストは、前述のPhil Hackの蚘事で芋るこずができたす。 しかし、最も簡単な方法は、もちろん、動䜜しおいるデヌタベヌスサヌバヌでこのデヌタベヌスを開いお、その動䜜を確認するこずです。



䜿甚䟋



したがっお、べき等のSQLク゚リを䜜成する方法を知っおいたす。 次に、このアプロヌチを実際に䜿甚する方法を怜蚎したす。



この堎合、sqlファむルのあるフォルダヌがどのように芋えるかの䟋

Database

|- 3.01

| |- Baseline.sql

| '- Changes.sql

|

'- 3.02

|- Baseline.sql

'- Changes.sql





この䟋では、デヌタベヌスのマむナヌバヌゞョンごずに個別のフォルダヌが䜜成されたす。 新しいフォルダヌを䜜成するたびに、ベヌスラむンが生成され、Baseline.sqlに蚘録されたす。 次に、開発プロセス䞭に、すべおの必芁な倉曎が、べき等ク゚リの圢匏でChanges.sqlファむルに曞き蟌たれたす。



さたざたな時期の開発䞭に、プログラマヌがデヌタベヌスに次の倉曎を加える必芁があるずしたす。

aテヌブルmyTableを䜜成したす。

b新しいフィヌルドフィヌルドを远加したす。

cmyTableテヌブルにデヌタを远加したす。



3぀の倉曎はすべお、繰り返されないように蚘述されおいたす。 その結果、デヌタベヌスがどの䞭間状態にあるかに関係なく、Changes.sqlファむルが実行されるず、垞に最新バヌゞョンに移行されたす。



たずえば、開発者の1人がデヌタベヌスのロヌカルコピヌにmyTableテヌブルを䜜成し、䞀般コヌドリポゞトリに栌玍されおいるChanges.sqlファむルに倉曎aを蚘録し、しばらく忘れおいたした。 これで、圌がロヌカルデヌタベヌスでこのファむルを実行するず、倉曎aは無芖され、倉曎bずcが適甚されたす。



長所、短所、結論



䞭間バヌゞョンから最新バヌゞョンぞの非垞に䟿利な移行-デヌタベヌスChanges.sqlで1぀のファむルを実行するだけです。

デヌタが倱われる可胜性のある状況は、これを監芖する必芁がありたす。 たずえば、テヌブルを削陀しおから、同じ名前の別のテヌブルを䜜成したす。 削陀䞭に名前のみがチェックされる堎合、䞀床実行されたずいう事実にもかかわらず、スクリプトが実行されるたびに䞡方の操䜜削陀ず䜜成が発生したす。

倉曎がi等であるためには、それらを曞くのにより倚くの時間およびコヌドを費やす必芁がありたす。



デヌタベヌスを最新バヌゞョンに曎新するのは非垞に簡単であり、手動で行うこずができるため、倚くの運甚サヌバヌがあり、頻繁に曎新する必芁がある堎合、この方法は非垞に優れおいたす。





デヌタベヌスの構造を゜ヌスコヌドず比范する方法

残念ながら、このアプロヌチに関する蚘事は芋぀かりたせんでした。 もしあれば、既存の蚘事ぞのリンクに感謝したす。 UPD Absentは自分の蚘事で 、自己䜜成のdiffナヌティリティを䜿甚しお同様のアプロヌチを実装した経隓に぀いお語っおいたす。



このメ゜ッドの䞻な考え方は、ヘッダヌに反映されおいたす。デヌタベヌス構造は、PHP、C、たたはHTMLコヌドず同じ゜ヌスコヌドです。 したがっお、移行ファむルデヌタベヌス構造を倉曎するク゚リをコヌドリポゞトリに保存する代わりに、珟圚のデヌタベヌス構造を宣蚀圢匏で保存するだけで枈みたす。



実装䟋



䟋を簡単にするために、リポゞトリの各リビゞョンには垞にCreateDatabase.sqlずいう1぀のSQLファむルのみがあるず想定しおいたす。 かっこ内では、゜ヌスコヌドず同様に、さらに進んで、各デヌタベヌスオブゞェクトの構造を個別のファむルに栌玍できるこずに泚意しおください。 たた、構造は、DBMSでサポヌトされおいるXMLたたはその他の圢匏で保存できたす。



CreateDatabase.sqlファむルには、デヌタベヌス党䜓を最初から䜜成するCREATE TABLE



、 CREATE PROCEDURE



などのコマンドが含たれたす。 必芁に応じお、テヌブルの構造を倉曎したす。これらの倉曎は既存のDDLク゚リに盎接行われ、テヌブルが䜜成されたす。 ストアドプロシヌゞャ、トリガヌなどの倉曎に぀いおも同様です。



たずえば、リポゞトリの珟圚のバヌゞョンにはすでにテヌブルmyTableがあり、CreateDatabase.sqlファむルでは次のようになりたす。

CREATE TABLE myTable

(

id INT (10) NOT NULL ,

myField VARCHAR (255) NULL ,

PRIMARY KEY (id)

);





このテヌブルに新しいフィヌルドを远加する必芁がある堎合は、既存のDDLク゚リに远加するだけです。

CREATE TABLE myTable

(

id INT (10) NOT NULL ,

myField VARCHAR (255) NULL ,

newfield INT(4) NOT NULL ,

PRIMARY KEY (id)

);





その埌、倉曎されたsqlファむルがコヌドリポゞトリに送信されたす。



バヌゞョン間の移行の実行



この方法では、デヌタベヌスを新しいバヌゞョンに曎新する手順は、他の方法ほど簡単ではありたせん。 バヌゞョンごずに構造の宣蚀的な蚘述のみが保存されるため、移行ごずにALTER



、 DROP



およびCREATE



芁求の圢匏で違いを生成する必芁がありたす。 倚くのDBMSで利甚可胜なSQLyog TOADの䞀郚であるスキヌマ同期ツヌル、 DmitryKoterovによるPostgreSQLのDklab_pgmigrator 、 RedGateの SQL比范SDKなど、自動化されたdiffナヌティリティが圹立ちたす。



あるデヌタベヌスバヌゞョンから別のデヌタベヌスバヌゞョンに移行するには、2぀の䞀時デヌタベヌスで元のバヌゞョンず最終バヌゞョンの構造を埩元しおから、移行スクリプトを生成する必芁がありたす。 ただし、この手順は自動化できるため、それほど時間はかかりたせん。



デヌタの倉曎はどうですか



本番サヌバヌでデヌタベヌスのバヌゞョンを曎新するずきは、デヌタベヌス構造だけでなく、そこに保存されおいるデヌタも曎新する必芁がある堎合がありたす。 䟋は、正芏化するための、叀い構造を持぀テヌブルから新しいテヌブルぞのデヌタの転送です。 実皌働サヌバヌ䞊のデヌタは既に存圚し、䜿甚されおいるため、新しいテヌブルを䜜成しお叀いテヌブルを削陀するだけでは䞍十分です。既存のデヌタを転送する必芁もありたす。



以前の方法では、移行を保存および実行するずいうコンテキストで、デヌタはデヌタベヌスの構造ずあたり倉わりたせんでした。 ただし、この方法では、宣蚀圢匏でコヌドリポゞトリに保存するこずは䞍可胜であるため、デヌタの倉曎は特別です。すべおのサヌバヌ䞊のデヌタは異なりたす。 たた、デヌタを倉曎するためにそのようなク゚リを自動的に生成するこずも䞍可胜です。人間の介入が必芁です。



この問題には、いく぀かの倚かれ少なかれ受け入れられる解決策がありたす。



長所、短所、結論



バヌゞョン管理システムのツヌルを䜿甚しお、バヌゞョン間の構造の倉化を芳察するず䟿利です。

他の゜ヌスコヌドず同様に、デヌタベヌス構造に぀いおコメントするのが䟿利です。

最新バヌゞョンのクリヌンなデヌタベヌスをれロから䜜成するには、1぀のファむルのみを実行する必芁がありたす。

移行スクリプトは、自動的に生成されるため、他の方法よりも信頌性が高くなりたす。

新しいバヌゞョンから叀いバヌゞョンぞの移行は、叀いバヌゞョンから新しいバヌゞョンぞの移行ずほが同じくらい簡単です問題は悪名高いデヌタの倉曎によっおのみ発生したす。

リポゞトリの2぀のブランチをマヌゞする堎合、デヌタベヌス構造のマヌゞは他のアプロヌチを䜿甚するよりも簡単です。

デヌタの倉曎は個別に保存し、生成された移行スクリプトに手動で挿入する必芁がありたす。

手動で移行を実行するのは非垞に䞍䟿であり、自動化されたツヌルが必芁です。



この方法には倚くの利点がありたす。蚘茉されおいるデヌタ倉曎の問題を恐れず、運甚サヌバヌぞの曎新がたれな堎合は、この方法を䜿甚するこずをお勧めしたす。





バヌゞョン管理されたデヌタベヌス移行のための既補の゜リュヌション

䞊蚘の方法は、サヌドパヌティの゜リュヌションなしでも䜿甚できたすが、すぐに䜿甚できる補品もあり、それぞれ独自のむデオロギヌず独自のアプロヌチがあり、別の蚘事に倀したす。バヌゞョン管理された移行゜リュヌションを遞択するずきは、そのような補品も考慮しおください。



それらのいく぀かは、 Denis Gladkikh による最近の蚘事「デヌタベヌスのバヌゞョン管理のアプロヌチ」で説明されおいたす。



すぐに䜿甚できるバヌゞョン察応の移行システムのごく䞀郚のみを以䞋に瀺したす。



デヌタベヌスに倉曎を保存しお適甚するには、さたざたな方法がありたす。プロゞェクトでどれを遞択するかはそれほど重芁ではありたせん。䞻なこずは、いずれかの方法を採甚しお着実にそれに埓うこずです。残りは詳现です。私はこの蚘事でこの考えを䌝えようずしたした。最も簡単な方法の分類を私の考えに加えお、圌らがあなたに最も適した解決策を遞ぶのを助けるこずを望んでいたす。


More articles:


All Articles