コードでは、通常、新しいクラスを追加して追加機能などを提供するのは非常に簡単です。私はコードのリファクタリングとその内容についてかなりよく理解しているので、YAGNIは一般的に私にとって理にかなっています。
私がよく知らないのは、デプロイされたリレーショナル データベースの操作と更新です。早期リリース、頻繁にリリースを実践することを計画している小さなペットプロジェクトを開発しています。初期リリースでは使用されないが、計画された機能リストにあるデータを検討する必要があるかどうか疑問に思っています? 新しいクラスを追加するのと同じくらい簡単に、テーブルを追加してスキーマを微調整できますか? それとも、おそらく使用できるものの、当面は計画していないもののためにテーブルをセットアップする必要がありますか?
これは素晴らしい質問です。個人的には、データベース スキーマを変更してすべてのデータを新しい表現に変換することは、コードをリファクタリングするよりもはるかに難しいことに気付きました。実際、新しいデータベースを使用するプロジェクトを開始するときはいつでも、腰を下ろしてコードを記述し、仕様をできるだけ完全なものにする前に、常に時間をとっています。これには多くの場合、機能を予測し、それらのサポートをデータベースに組み込むことが必要です (たとえすぐに実装する予定はありません)。
データベースを変更するためのメカニズムを提供するフレームワークまたは他の同様のレイヤーを使用している場合は、データベースのリファクタリングをもう少し機敏にできるかもしれませんが、単純な SQL を書いている場合は、適度な量の投資をお勧めします。将来変更が必要になる可能性が低いスキーマを設計および実装する時間。
データベースの設計と実装については、アジャイルな考え方がたくさんあります。この件に関する Scott Ambler の考えの一部については、www.agiledata.org でベストプラクティスに目を通すことに興味があるかもしれません。私自身は、通常、アプリケーションの開発に合わせてデータベースの設計を拡張します。事前にテーブルを作成することはめったにありません。これに対する例外は、監査やパーミッションなど、設計全体を横断するものです。実際に事前にテーブルを作成しなくても、これらを実装する方法を考えます。分野横断的な側面は、それらの機能が常に最初に出てくるとは限らない場合でも、テーブルの設計に影響を与えます。
私の意見では、YAGNI はすべて、コーディング、データベース設計、家事 (妻はこれについては激しく反対しています) などに適用されます。
私がこれまで取り組んできたすべての DBMS ベースのアプリケーションでは、scema が定期的に更新されていたので、これはプロセスで計画する必要があります。DBA は、あなたの提案の「頻繁にリリースする」部分を好まないでしょう。それは、DBA にとってより多くの作業になるからです (DBA 以外のデータベースの場合はあなたも)。
しかし、それが彼らの目的です。
データベースにヒットする優れたテストがある場合は、YAGNI をデータベース設計に拡張します。
一般に、列とテーブルを追加するのは簡単ですが、それらを大幅に削除または変更するのはそれほど簡単ではありません。テーブルを設計するときは、この点を考慮してください (つまり、顧客が複数のユーザーを持つことができる場合は、顧客テーブルにユーザー ID を追加しないでください。最初から正しく行ってください)。
データベース設計には概念的な基礎があります。
従来のデータベース設計には、概念、論理、および物理の 3 つのモデルがあります。
概念モデルは要件分析から生まれ、基礎となる主題が発展するか、主題の理解が発展するにつれて発展します。概念モデルは、形式とセマンティクスに関して基本データを突き止めますが、表の構成などの問題は扱いません。
論理モデルは、データのリレーショナル モデルを使用します。これは概念モデルから導き出すことができますが、関係の構成も扱います。ここで正規化やその他の構成の問題が発生します。論理モデルは、テーブルの設計を予測し、アプリケーションが行うクエリと更新も予測します。
物理モデルはリレーションをテーブルとして実装し、実際にデータベースを構築するために必要なインデックス、テーブルスペースなどの他のすべての機能も追加します。これは論理モデルから派生したものですが、データ ボリューム、負荷、パフォーマンス、およびディスク容量がすべて影響します。
これは長くて退屈に思えますが、方法を知っていれば実際には高速です。チームの残りの部分がまだ機能仕様について議論している間、全体は数週間で完了することができます. 非常に小さなプロジェクト (6 つのテーブル、50 列) の場合、鉛筆と紙だけで数日で完了します。大規模なプロジェクトの場合、設計をより自動化し、エラーを起こしにくく、図を簡単に作成できるツールがあります。
しかし、概念モデルが不正確または不完全であり、他の 2 つのモデルとデータベース自体を変更する必要があることに気付いた場合はどうなるでしょうか? そこで、データの独立性が役に立ちます。カプセル化がオブジェクト設計にもたらすのと同じように、データ独立性はデータベース設計に役立ちます。つまり、1 か所の小さな調整がアプリケーション オブジェクト全体に伝播するのを防ぎます。オブジェクトは、使用するデータのみに依存します。
新しいテーブルをスキーマに追加する必要がある場合、アプリケーションが壊れる可能性はほとんどありません。既存のテーブルを変更する必要がある場合でも、古い列のみを使用するクエリでは違いがわかりません。オブジェクトが変更に依存している場合でも、変更されたテーブルに新しい名前を付けて、古いテーブルがまだそこにあるように見せる古い名前でビューを作成できます。
また、優れた DBMS では、物理的なデータの独立性はほぼ完全です。データの再編成、インデックスの追加と削除などを行うことができ、アプリケーションを変更する必要はありません。
つまり、変更管理は、本当に優れた DBMS 製品を使用して見事に行うことができます。残念ながら、DBA やプログラマーの多くは、これらの DBMS 機能が何年も使用されているにもかかわらず、それらの機能を十分に活用する方法を知りません。
データベースの設計は、他の種類の設計と同様です。理解は徐々に深まり、理解が深まるとスキーマが進化します。
リレーショナル データベース スキーマ設計の概念的な基礎が実際にどのように存在するかを簡単に説明できればと思います。それを実際にモデル化する唯一のツールは、長い間登場してきたオブジェクト ロール モデリングです。最も馴染みのあるツールは Visiomodeler でした。それを理解するために、ここにScott AmblerとScot Beckerへのリンクをいくつか示します。したがって、概念モデルが変更されると、スキーマを変更する必要があります。
実際には、変換式に慣れている場合、rdbms はかなり柔軟に処理できます。そして、それを上手にすることは価値があります。
注: LINQ やオブジェクト リレーショナル モデルなどの SQL 回避手法は、進化する設計の障害になるだけだと思います。私は間違っているかもしれません。Microsoft の Entity Framework に Object Role Modeling が含まれることを期待するには、いくつかの理由があります。しかし、私はその可能性への斜めの言及しか見たことがありません。
原則は引き続き適用されます。大量のデータが得られるまで、テーブルなどへのフィールドの追加について心配する必要はありません。かなりのデータ。そのため、実際のデータを確認せずにインデックス作成やクエリ プランの詳細についてあまりにも早い段階で心配すると、多くの場合時間が無駄になり、後でアーキテクチャの問題につながることさえあります。
残念ながら、本番リリース後にデータベース設計をいじるのは、適切なテスト/リリース プロセスに従わなければ、非常に恐ろしいことです。したがって、コードよりもさらに、データベースを初めて正しく使用する必要があります。
データベースでは、データを入れて保存するだけでなく、データを取り出すことも計画したいので、「計画された」機能にレポートが含まれている場合、それはデータベースの設計に大きく影響するので、おそらくそれを計画してください。
スキーマを微調整するのは、クラスを追加するほど簡単ではありませんが、実行可能です。
したがって、全体として、YAGNI は引き続き適用されます。
まだ必要のないテーブルをセットアップしないでください。YAGNI の背後にある理由の 1 つは、必要になる正しいものを前もって予測しないことです。新しいテーブルを追加したり、既存のテーブルを変更したりする必要がある場合は、それらを簡単に変更できます。
優れたフレームワークには、移行を実行するためのツールが必要です。これにより、データベースを簡単かつ自動的にアップグレードおよびダウングレードできます。これが整っていて、設計にかなり注意を払っている場合は、必要なすべてを前もって考え出そうとするのではなく、必要な場所にリファクタリングできるはずです。