コードファーストとデータベースファースト

作業するソフトウェアを設計および作成するとき、通常、最初にバックエンドSQLテーブルを設計および作成してから、実際のプログラミングに進みます。私が現在取り組んでいるプロジェクトは、私を困惑させます。これはおそらく、適切で堅実な要件が不足しているためですが、残念ながら今度はそれについてできることはほとんどありません。それは「それを実現させるだけ」のような状況です。しかし、私は脱線します。

ワークフローを頭に入れ、最初にUIクラスとデータモデルクラスを作成して、データベーススキーマが最終的にどのように見えるかを明確にすることを考えています。これはいい考えですか？私はUIになり、dbをどのように構成するのかまだわかりません。

好奇心anyone盛な方は、SQL Serverをバックエンドとして、MS Accessをフロントエンドアプリケーションとして使用しています。（アクセスも私の選択ではありません...だから、あまりにも嫌いにしないでください。）

最初に来たのは、プロセス、またはそのプロセスで使用されるデータですか？これは一種の「鶏または卵」の質問であることは知っていますが、ソフトウェアの場合、それがプロセスだと思います。

たとえば、メモリ内の永続性（または実装が簡単なもの）を使用して、一度に1つのユースケースを実装することにより、データモデルを段階的に構築できます。基本的なエンティティの概要を説明するのに十分なユースケースを実装していると感じたら、メモリ内の永続性を実際のデータベースに置き換えて、一度に1つのユースケースごとにスキーマを改良し続けることができます。

これにより、データベースからフォーカスが外れ、問題の中心であるビジネスルールに移動します。ビジネスルールを実装することから始めた場合、最終的に（方法によっては、Natural Selectionに非常に類似したプロセスによって）どのデータがビジネスに本当に必要かがわかります。そのデータが本当に必要かどうか（またはその形式、またはそのレベルの正規化など）のフィードバックなしにデータベースのモデリングから始めると、最終的に多くの遅延調整を行うことになります。スキーマ（ビジネスで既に実行されている場合は、重い移行手順が必要になる場合があります）、またはビジネスルールに「回避策」を実装して、不適合データモデルを補う必要があります。

TL; DR：データベースはビジネスに依存します-それは彼らによって定義されます。データを操作するプロセスがない限り、データは必要ありません（レポートもプロセスです）。最初にプロセスを実装すると、必要なデータが見つかります。最初にデータをモデル化すると、最初にモデル化したときに間違っていた仮定の数を数えることができる場合があります。

トピックから少し外れていますが、非常に重要です。説明するワークフローは、「動作する可能性のある最も単純なもの」、テスト駆動開発、アーキテクチャを詳細から切り離すことに焦点を当てるなど、非常に重要なプラクティスとともに使用されることがよくあります邪魔になります（ヒント：データベース）。最後の話については、この講演ではその考えをかなりうまくまとめています。

根本原因分析により、この問題は方法の1つではなく、仕様の欠如が示唆されています。それなしでは、最初に何を書くかは重要ではありません-とにかくそれを捨てます。

さまざまなレベルでいくつかのユーザーを特定し、簡単で汚れたアンケートを作成してからマシンの電源を切り、コーヒーとクッキー/ドーナツ（または車輪に油を塗る）をつかんで歩いてください彼らの机、彼らが何をしているか、彼らが仕事をするために知っている/記録する必要があることを彼らに尋ねてください。彼らがどれほど重要であるかを心配する必要はありません。忙しすぎる場合は、別の時間に戻ってくるか、そのままにしておくように手配してください。

それができたら、最良の結果が得られると思うものは何でも構築を開始でき、仕様の残りが入ってくるのを待つことができるはずです。

私の経験は次のとおりです。

• 私が取り組んだほとんどのプロジェクトでは、最初にデータベースを設計しました。
• 多くの場合、データはスプレッドシート、レガシーデータベース、紙などに既に存在します。そのデータは、保持する必要があるテーブルに関するヒントを提供します。
• 多くの場合、プロセスは既に使用されていますが、手動で、または自動化されていない、相互運用しない、および/または標準に準拠していない複数の異なるツールを使用しています。
• 半成熟したデータベースモデルを作成したら、そのデータベースの読み取りと書き込みを行うプロトタイプフォーム、ウィンドウなどの設計を開始できます。
• 続行すると、最初は考えられなかったことに対応するために、いくつかの変更が必要になります。

また覚えておいてください：

• もはや1つのアプリ<-> 1つのデータベースの世界ではありません。アプリが複数のデータベースからデータを読み書きする必要がある場合や、ソリューションが同じデータベースを使用する複数のアプリで構成される場合があります。

結論：最初にデータベースを設計することをお勧めします。

大規模なプロジェクトで多くの経験があり、多くの開発者が並行して作業している場合、確かなデータモデルが本当に必要なので、Database Firstと言いました。

しかし、それについてもう少し考えましたが、より成功した大規模なプロジェクトで私たちが本当にやっていることは、「最初に要件」であることに気付きました。

適切に指定されたビジネス要件のセットは、機能要件のセットにつながります。適切な機能要件がある場合、データモデルとモジュールの仕様は、それほど手間をかけずに適切な位置に収まります。

これは非常に流動的/不特定のように見えるので、最初にフロントエンドGUIを実行します。これは、利害関係者からの応答、サポート、時間、フィードバックを得るために必要なもののように聞こえますか？彼らはあなたの素晴らしい正規化されたテーブルや外部キーの制約、カスケード削除を気にしません。しかし、たくさんの光沢のある色のクールなGUI-それは最高です！

最初のバックエンド「データベース」には、ファイルに保存されたキー/値だけなど、非常に単純なものを使用します。私はMS Accessに不慣れなので、「最も軽量な」バックエンドが何であるかわかりません。（スプレッドシードのテーブルですか？）迅速で汚れているものは何でも、捨てることを計画してください。

可能であれば、GUIで面白い外観を使用して、それがプロトタイプであることを明確にします。他のすべてが失敗した場合、インデックスカードを使用します。

今、あなたの利害関係者はDBの専門家かもしれません。-その場合、いくつかのDB設計を行います。

要件は明確ではないため、必要なことがわかっている重要な要素、おそらくは基本的なテーブルとPKのみを含む非常に基本的なデータモデルから始めることができます。残りのデータは、バイナリまたはXMLにシリアル化し、最初にデータベースにBLOBを保存します。これにより、完全なリレーショナルモデルを使用せずにUIおよびビジネスレイヤー（中間層）を開発できますが、必要に応じて、キーのルックアップを保存および取得し、簡単にキーを参照できます。

例として、あなたは個人を持っているかもしれないので、個人IDのPKを持っています。残りの属性は不明であるため、PK Person IdとBlobを格納する別の列、すべての個人データを含むPersonテーブルから始めます。

要件が固まったら、Blobを取得し、必要なすべてのテーブルと列を抽出して、モデルをリレーショナルにします。次に、データアクセスレイヤーで永続性をBLOBからリレーショナルに変更するだけです。ただし、他のすべて、ビジネスルールUIなどは引き続き機能します。これにより、プロジェクトに時間がかかりますが、より強固になるまでリレーショナルモデルを変更せずに、必要に応じて完全に柔軟に追加および削除できます。

モデルが安定するにつれてBLOBをクエリできないため、検索が遅延する場合があります。リレーショナル列で検索する必要があるデータの保存を開始します。

基本的には、表形式のモデルから始めて、プロジェクトの進行に伴ってリレーショナルモデルに移行します。

または、作業を開始する前に要件を確定して、リレーショナルモデルを最初に開発できるようにします。

一般に、コードはデータを操作するため、コードはデータの後に来ると思います。

要件が明確でない場合は、要件の解釈のデータモデルを作成できます。最善の方法は、いくつかの要件を書き留めて雇用主に送信することです。そうすれば、彼らは何かを狙うことになります。または最初にGUIを作成します。これは雇用主のタイプに応じて最適に機能します:)