Gitが普及したのと同じ頃、object-relational mapping(ORM)ライブラリを使用してwebベースのアプリケーションを作成する傾向もよく知られるようになりました。 開発者はGitを使用して簡単にロールバックできるコードを変更できるので、スキーマの変更に関して開発者が同じことを行うことができないのはなぜ 結局のところ、合理的な新機能にはコードとスキーマの変更が含まれます。 RailsやDjangoのような人気のあるフレームワークは、ormとデータベース移行（スキーマ移行とも呼ばれます）を提供の一部として追加しました。 しかし、概念としてのデータベース移行は、一般的なwebフレームワークに限定されません。 FlywayやLiquibaseのようなスタンドアロンのデータベース移行ソフトウェアライブラリもあります。 コードを書くときにスキーマに細かい変更をロールバックできると想像できますか？ あまりにも頻繁に、データベースの移行に関する記事では、開発者として積極的に行うことの意味について議論していないことがわかります。 私はここでそれを修正したい。 そのことを念頭に置いて、今日は、データベースの移行に伴うものと、アクティブな開発環境でそれを行う方法の全体像を説明します。 移行プロセス中に何が起こるか、使用される一般的なツール、およびデータベースの移行中にトリミングすることができます落とし穴をカバーし、三つのセクショ これにより、初心者の開発者は、データ移行の背後にある重要なアイデアをすばやく学習し、開発ツールボックスの一部としてデータベース移行を使用する際に避けなければならない潜在的な落とし穴を学習するためのツールを提供する必要があります。
データベースの移行中に何が起こりますか？
データベースの移行がどのように行われたかを知ったので、実際に何が必要なのかを説明しましょう。
詳細な変更は、個々のスクリプトファイルとして生成されます
データベースの移行は、基本的にデータベーススキーマ（および場合によってはデータにも）の詳細な変更を追跡する方法について説明しました。 これらの詳細な変更は、通常、個別のスクリプトファイルとして反映されます。 このようにして、細かいスキーマの変更は、任意のバージョン管理ソフトウェアでキャプチャできるコードとして反映されます。 これはRailsの移行ファイルの例です。
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
移行をスタンドアロンファイルとして持つことができるだけでなく、現在のデータベーススキーマを独自のファイルとして持つこともできます。 通常、これはスキーマファイルとして知られています。
データベース移行スクリプトはツールに依存しています
先ほどの例からRubyのデータベース移行スクリプトを思い出してください。 データベースソフトウェアLiquibaseの独立したソース管理からの別のデータベース移行ファイルを次に示します。
<?xml version="1.0" encoding="UTF-8"?><databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd"> <changeSet author="bob"> <createTable tableName="department"> <column name="id" type="int"> <constraints primaryKey="true" nullable="false"/> </column> <column name="name" type="varchar(50)"> <constraints nullable="false"/> </column> <column name="active" type="boolean" defaultValueBoolean="true"/> </createTable> </changeSet></databaseChangeLog>
今回はXML形式のファイルです。 実際には、Liquibaseは、XMLやJSONなどの複数の形式で移行の変更（またはそれらを呼び出すのが好きな変更セット）を生成することができます。 したがって、データベースの移行をSQL形式で手書きする場合を除き、移行ファイルの作成方法に関する実際の標準はありません。 もちろん、SQLファイルに独自のカスタムデータベース移行スクリプトを記述することもできます。 しかし、データベースの移行を自動生成するためのツールを使用できるときに、なぜ手書きして誤ってバグを導入するのですか？
データベースの移行を実行するにはどうすればよいですか。
これで、データベースの移行が何であるかがわかりました。 また、データベースの移行を実行する方法を（少なくとも概念的に）知っておく必要があります。 残念ながら、データベース移行ファイルにはまったく標準がないため、それらを作成する方法についてあまり詳細に説明することはできません。 つまり、データベースの移行を実行する方法は、タスクに使用する特定のツールに大きく依存します。 このセクションでは、データベースの移行を実行するための最も一般的な2つの方法について説明します。
オプション1：人気のある言語（Ruby、PHP、Pythonなど）を使用する場合は、フレームワーク/言語依存ライブラリ
を使用します。）またはフレームワーク（Rails、Djangoなど））、その後、選択されたフレームワーク/言語の宇宙内のデータ移行のための十分に文書化されたライブラリがあります。 人気のあるwebフレームワークは、当然のことながら、データベース移行機能にバンドルされています。 設定に応じて、選択した言語内の他のライブラリのネイティブデータベース移行を交換することもできます。 通常、このシナリオでは、コマンドラインを使用して移行ファイルを生成します。 場合によっては、データの移行や変更自体を元に戻す方法など、一部の変更に対してカスタムコードを手書きする必要がある場合があります。 それ以外は、フレームワーク/言語内で選択されたライブラリがあなたのためにこれをかなり処理します。
オプション2:独立したデータベース移行に焦点を当てたソフトウェアを使用する
場合によっては、データベースのソース管理として機能するFlywayやLiquibaseなどのソフ これを行うことで、特定のフレームワークや言語にロックされることを回避できます。 これは、ロックインがゼロであることを意味するものではありません。 たとえば、Oracle、MySQL、MariaDBなどのさまざまなデータベースでうまく動作するFlywayを考えてみましょう。 FlywayのJavaベースの移行（JavaとFlywayにロックされます）を使用しない場合、SQLベースの移行（選択したデータベースとFlywayにロックされます）を使用することになります。 良いニュースは、FlywayとLiquibaseの両方が比較的使いやすいことです。 また、移行を生成し、カスタムコーディングでデータベーススキーマの移行をキャプチャできるようにするためのコマンドライン方法も提供します。
あなたに最適なオプションを選択する
どちらのオプションを選択するかについての私の意見です。 私はほとんどの開発者がオプション1を選択する傾向があります。 通常、それは開発者がすでに好ましい言語/フレームワークを持っているので、認知的に言えば、彼らが（まだ）別のソフトウェアを学んでいるようには感じ そして、ロックイン（オプション1の場合、これはフレームワークと言語になります）は完全に自発的であり、望まれています。 チームが特定の言語やフレームワークに完全にコミットしていない場合は、オプション2のケースを作ることができます。 どちらにしても、開発の途中で不必要に選択を変更することは避けてください。 データベースの移行は、ツールを変更することで多大な利益をもたらす領域ではありません。 ほとんどの利点は、最初にデータベース移行をセットアップするだけで得られます。
データベース移行の危険性とその回避方法
前のセクションでは、データベース移行のためのツールの二つの主要なタイプについて説明しました。 どちらのタイプも使いやすいです。 ここでは、データベースの移行を実際に実行する際に、3つのベストプラクティスをお勧めします。 これらのヒントは、データベース移行の主な危険性に対処します。
一つのデータベース移行ツールを選択し、それに固執
私はこれを簡単に前に述べましたが、それは強調する価値があります：私はそれがクールだからといって、ツールセットに不必要な変更を加えないように警告したいと思います。 データベース移行スクリプトは、それらの生成に使用するツールに依存していることを思い出してください。 これらのスクリプトには適切な基準はありません。 本当にしたい場合は、独自のIN SQL文を作成することもできます。 たとえば、SQLスクリプトはデータベースに依存する可能性があります。 MysqlクエリはPostgreSQLでは動作しない場合があり、その逆もあります。 したがって、データベース移行ツールにロックされているか、選択したデータベースにロックされているか、場合によっては両方にロックされています。 ツールセットを頻繁に切り替えることに明らかな利点はないので、私の提案は1つのデータベース移行ツールを選択してそれに固執することです。 あなたの車輪を不必要に回すよりあなたの時間とするべきよりよい事がある。
行または列を削除する必要があることが確実な場合にのみ
移行に関しては、ほとんどの場合、必要なときにそれらを元に戻すことができます。 一般的なデータベース移行ツールでは、単純な可逆的な変更を処理できます。 また、できない場合でも、独自のカスタムコードを簡単に追加して逆転を助けることができます。 たとえば、Railsでは、リバーシブルの下にコードを追加するだけです。
class ChangeProductsPrice < ActiveRecord::Migration def change reversible do |dir| change_table :products do |t| dir.up { t.change :price, :string } dir.down { t.change :price, :integer } end end endend
reverseへの最も困難な変更は、ものの削除、特にデータの列または行の削除を伴う傾向があります。 データベースに大量のデータが含まれている場合は、変更を元に戻すためにかなりの量のカスタムコードを記述する必要が生じる可能性があります。 そのため、データベースからデータを削除することを検討している場合は、特に注意してください。 これらのタイプの変更は元に戻すのが難しいです。 逆になりにくいその他の変更には、列の名前を変更したり、既にデータが含まれている列のデータ型を変更したりすることが含まれます。 私が行くのが好きな経験則の1つはこれです：次のメジャーまで列を削除することはほとんどありません（あなたはsemverを知っていますよね？）をリリース。 このルールは、使用を停止したい列がある場合でも適用されます。 列を削除する代わりに、マイナーバージョンでは、今後どの列が非推奨になるかを発表します。 それはメジャーリリースのための時間が来るとき、私はその後、完全にそれらの列を削除します。 そうすれば、私は手で逆転するひどいプロセスである偶然の、不必要な変更を行うチャンスを減らす。
機能フラグの実装
データベース移行のもう一つの優れた戦略は、特に大規模なチームがあり、複数の人が同じコードベースに対して異なる機能を実装しようとしている場合に、機能フラグを実装することです。 Martin Fowler氏によると、機能フラグは”強力な技術であり、チームはコードを変更せずにシステムの動作を変更することができます。”実際には、あなたのチームが大きく、コードベースが複雑であればあるほど、より多くの機能フラグが輝きます。 機能フラグは、データベースの移行に関するリスクを軽減するのに役立ちます。 特定の機能をロールバックする必要があるときに変更を解こうとすると、本当の悪夢になる可能性があります。 機能フラグは、小規模または大規模なデータベーススキーマの変更を行うかどうかにかかわらず、同様に機能します。 機能フラグを使用する場合は、全体的に、より頻繁で詳細な変更を目指すことをお勧めします。 また、大規模なスキーマ変更を実行するときに、機能フラグが開発プロセスにどのように役立つかを実際に見ることができます。 この大規模なスキーマの変更をより小さく薄いスライスに分割することを目指してください。 あなたは一つの変更で絞ることができますどのくらいで誰を感動させる必要はありません。 このセクションで説明した3つの推奨事項をすべて実装することで、開発プラクティスに安全対策を追加することをお勧めします。
結論
開発者は、自分たちの生活を楽にするために得ることができるすべてのツールを必要としています。 データベースの移行は、開発者のツールボックスに必要なツールの1つです。 今後、データベースの移行を採用することは、開発のベストプラクティスから開発標準のプラクティスに進化すると予想しています。 データベースの移行をまったく使用していないため、人々はあなたを面白いと見ています。 それでも、データベースの移行がどのようにあなたに裏目に出ることができるか、特にスキーマの変更を逆にするのが難しい場合には、心に留めておくことが重要です。 あなたがそれらをライブにする前に、それらの変更を絶対に確実にしてください。 プロセスでデータベース移行をまだ使用していない場合は、何を待っていますか？ 開始するのは簡単で、開発サイクルの途中で追加することもできます。 あなたがしたことに感謝するでしょう。 変更をロールバックする必要があり、変更にデータベースが含まれる日が来たときは、ほんの数秒でそれを行うのに役立つ何かがあればいいのです。 データベースの移行は、あなたが持っていたことを望むものです。