リレーショナルデータベースと反復開発

アジャイル手法、ドメイン駆動設計、オブジェクト指向分析および設計など、ソフトウェア開発への多くのアプローチでは、開発への1つの反復アプローチを採用することをお勧めします。

そのため、プロジェクトでの作業を初めて開始したときにドメインモデルを正しく実行することは想定されていません。代わりに、時間が経つにつれてモデルをリファクタリングします。なぜなら、時間とともに問題の領域をより深く理解できるからです。

それとは別に、完璧なモデルを事前に取得しようとしても、私はすでに非常に難しいと確信していますが、要件は変わる可能性があります。ソフトウェアがそのようにした後にしている生産に配備され、エンドユーザーは、一定の要件を完全に理解していなかったことに気づくかもしれない、あるいは悪化し、いくつかの要件が欠落していました。

ここでのポイントは、ソフトウェアの展開後にモデルの変更が必要になる場合があるということです。これが発生した場合、問題が発生します。本番データベースには重要なユーザーデータがあり、古いモデルの形式に既に適合しています。

コードが適切に設計されておらず、システムが大きい場合、コードの更新は困難な作業になる可能性があります。しかし、それは時間とともに実行できます。Gitのようなツールを使用すると、本番対応バージョンを損傷することなくそれを実行できます。

一方、モデルが変更された場合、クラスのプロパティが消失した場合など、データベースも変更される必要があります。しかし、問題があります。そこには、失われないデータが既にあり、古いモデル用にフォーマットされています。

ここのリレーショナルデータベースは、エンドユーザーの要求に応じて反復的な開発を行ったり、ソフトウェアを更新したりすることを妨げる障壁になっているようです。

私がすでに使用したアプローチの1つは、古いデータベーステーブルを新しいテーブルにマップする特別なクラスをコーディングすることでした。したがって、これらのクラスは古い形式のデータを選択し、新しいモデルで使用される形式に変換して、新しいテーブルに保存します。

このアプローチは最良の方法ではないようです。ここでの私の質問は次のとおりです。リレーショナルデータベースで反復開発を調整するためのよく知られた推奨アプローチはありますか。

特別なクラスである必要はありませんが、はい、以前の形式のデータベースを現在の形式に変換するものが必要です。

ここで重要なのは、これらのスクリプトを作成およびテストするためのプロセスを開発し、手動でテストデータベースと運用データベースに触れるのではなく、常に移行スクリプトによって訓練する必要があるということです。

データベースを変更する必要があるたびに、SQLまたはORMレイヤーを使用して、それを行うスクリプトを作成し、新しいスキーマを必要とする変更とともにバージョン管理にコミットします。次に、シーケンスでまだ適用されていないすべての移行スクリプトを適用してデータベースをアップグレードする制御スクリプトがあります。

また、スクリプトを適用し、動作しない場合は以前のバージョンにロールバックすることにより、共有開発、テスト、およびQA環境のみを変更するようにします。したがって、本番環境でそれらを解放するときに、意図したとおりに動作することを合理的に確信できます。

新規インストールは、すべてのスクリプトを適用するだけで簡単に実行されます。しばらくすると、数百台になり、非常に効率が悪いと思うかもしれませんが、最適化を試みるというtrapに陥らないでください。インストールは1回限りの作業であり、信頼性を維持することは迅速になります。

@Docブラウンはすでにリンクされ進化データベースの設計：Martin Fowler氏をして/programming/334059/agile-development-and-database-changes、と私は追加したいアレックスPapadimoulis：右を完了データベースの変更、短いですいくつかの例があります。

そのようなプロセスを実装するツールの適切な例として、Alembicをお勧めします。Python SQLAlchemyフレームワークに基づいていますが、独自の移行サポートがない場合は、他の言語やフレームワークで使用できます。スキーマの移行に関するウィキペディアのページには、このようなツールがリストされています。

奇妙なことに、これは現在の開発チームが直面しているまさに問題です。質問にはいくつかのサブ質問が含まれているため、個別に対処します。

何よりもまず、リレーショナルデータベースはデータモデルを過度に制約し、変更を非常に難しくしていますか？

最も確かに、しかし必ずしも引用された理由のためではない。残念ながら、リレーショナルデータベース管理システムの汎用性も、その衰退につながります。RDBMSは元々、大きなデータセットを受け入れて比較的小さなサイズに縮小する比較的単純なデータストレージプラットフォームを提供するために開発されました。これは、データモデルの複雑さと、必要な計算能力を犠牲にして行われました。データベースの複雑さが増すにつれて、データベース管理者が一貫性のあるスケーラブルな方法で複雑さに対処できるように、ストアドプロシージャ、ビュー、関数、およびトリガーが登場しました。

残念ながら、リレーショナルデータベースモデルはオブジェクト指向ではなく、データモデルのように実際のエンティティに自然にマッピングされません。そのため、オブジェクトリレーショナルマッパーなどの仲介者ツールが必要になります。残念ながら、これらのツールは明らかに今日の開発の世界での位置を占めていますが、その使用は、データモデルの実際の世界への不整合である根本的な原因ではなく、リレーショナルデータの複雑さの問題の症状を対象としています。

それは質問の2番目の部分につながります。これは実際にはより多くの仮定でしたが、質問と見なされるべきです。最初にドメインモデルを正しく実行することになっていますか？

はい、ある程度。質問が指摘したように、設計プロセスを開始するときに問題を完全に理解することはほとんど不可能です。ただし、ドメインの理解が深まるにつれて微調整される可能性があるものとは対照的に、完全に不正確なデータモデルの違いは、現実世界に一貫してマッピングされるモデルです。 これは、現実世界のエンティティに関する問題の理解と一致する初期データモデルを作成するためにあらゆる努力をする必要があることを意味します。 間違ったエンティティで正規化を開始すると、データモデルが2つの点で間違ってしまい、回復が困難になります。

多くの点で、「No SQL」データベースソリューションへの移行は、データモデルの一貫性の問題の結果です。オブジェクト指向のNo SQLアプローチを使用すると、コード内のオブジェクトと現実世界のオブジェクトとの間のマッピングについてより深く考えることができます。データベース。これにより、全体的な設計が改善されます。

それが最後の質問につながります：リレーショナルデータモデルはアジャイルアプローチと矛盾していますか？

いいえ、しかしより多くのスキルが必要です。 No-SQLの世界では、フィールドを追加したり、プロパティを配列に変換したりするのは簡単ですが、リレーショナルの世界でこれらのことを行うのは決して簡単ではありません。少なくとも、リレーショナルデータモデルとそれらが表す実世界のエンティティの両方を理解できる人が必要です。この人は、実世界のモデルの理解が変化したときにリレーショナルモデルの更新を促進する個人です。この問題を解決する特効薬はありません。

主なポイントは、モデルがすべての認識を超えて変化するほどリファクタリングしないことです。反復的な開発であっても、実際に既存のものの上に構築し、リファクタリングしないでください。

これにより、大きな変更を処理する2つの主なオプションが提供されます。1つ目は、DBレイヤーをAPIとして構築し、ストアドプロシージャを使用して、基になるデータスキーマを変更せずにクライアントに合わせて変更できるようにすることです。

もう1つの方法は、テーブルを少しのデータ移行で置き換えることです。大規模な変更が必要な場合は、新しいスキーマを作成し、一連のスクリプトを実装して古いデータを取得し、新しい形式にマッサージします。これを行うには時間がかかります。そのため、最初の選択肢として、データへのアクセスを変更するより安価な方法（SP経由など）にもっと頼るのです。

だから：1.物事を変える必要がないように、デザインを先に考えてみてください。

2. ラッパーまたはAPIに依存しているため、変更は制限されているか、隔離されたコンポーネント内に隠すことができます。

3. 必要に応じて、適切にアップグレードするために時間をかけてください。

これらの手順は、データベースだけでなくすべてに適用されます。