コードファーストとデータベースファースト
作業するソフトウェアを設計して作成するときは、通常、最初にバックエンドSQLテーブルを設計して作成してから、実際のプログラミングに移ります。私が現在取り組んでいるプロジェクトは、私を戸惑わせています。これはおそらく、適切で確実な要件が不足しているためですが、残念ながら今回はそのためにできることはほとんどありません。それは「それを実現させるだけ」という状況ですが、私は余談です。
最初にワークフローを裏返してUIとデータモデルクラスを作成することを考えています。これを実行すると、データベーススキーマが最終的にどのように見えるかが明確になります。これは良い考えですか？最終的にはUIになってしまい、dbをどのように構成するかわからないことに不安を感じています。
好奇心旺盛な方は、SQL Serverをバックエンドとして、MS Accessをフロントエンドアプリケーションとして使用しています。 （アクセスも私の選択ではありません...あまり悪くないで嫌いにしないでください。）
何が最初に来ましたか、プロセス、またはそのプロセスで使用されるデータ？これは「鶏肉か卵か」という質問だと思いますが、ソフトウェアの場合はそのプロセスだと思います。
たとえば、メモリ内の永続性（または実装が容易なもの）を使用して一度に1つのユースケースを実装することで、データモデルを段階的に構築できます。基本的なエンティティの概要を示すのに十分なユースケースを実装したと感じたら、メモリ内の永続性を実際のデータベースで置き換え、次に、1つずつユースケースを進めながら、スキーマの改良を続けることができます。
これにより、データベースからフォーカスが外され、問題の核心であるビジネスルールに移動します。ビジネスルールを実装することから始めると、最終的に（Natural Selectionと非常によく似たプロセスによって）、ビジネスで本当に必要なデータがわかります。データベースのモデリングから始めて、そのデータが本当に必要であるか（またはその形式で、またはそのレベルの正規化などで）フィードバックがない場合、最終的には多くの遅い調整を行うことになります。スキーマ（ビジネスで既に実行されている場合は、大規模な移行手順が必要になる場合があります）、またはビジネスルールに「回避策」を実装して、調整されていないデータモデルを補う必要があります。
TL; DR：データベースはビジネスに依存します-それは彼らによって定義されます。データを操作するプロセスがない限り、データは必要ありません（レポートもプロセスです）。最初にプロセスを実装すると、必要なデータが見つかります。最初にデータをモデル化すると、最初にモデル化したときに間違っていた仮定の数を数えることができる場合があります。
トピックから少し外れていますが、非常に重要です。私が説明するワークフローは、「機能する可能性のある最も単純なもの」、テスト駆動開発、およびアーキテクチャを詳細から切り離すことに焦点を当てたものなど、非常に重要なプラクティスとともによく使用されます邪魔になります（ヒント：データベース）。最後の1つについて、 この講演 はアイデアをかなりうまくまとめています。
根本原因分析は、この問題が方法の1つではないことを示唆していますが、仕様の欠如です。 1つがなければ、最初に何を書いてもかまいません-とにかくそれを捨てます。
自分自身を支持し、いくつかの基本的なシステム分析を行います-さまざまなレベルで一部のユーザーを特定し、簡単で汚いアンケートを作成してから、マシンの電源を切り、いくつかのコーヒーとクッキー/ドーナツ（またはホイールに油を差すもの）をつかみ、散歩します彼らのデスク、彼らが何をしているのか、そしてそれが明白に思われるとしても彼らが仕事をするために知っている/記録する必要があることを彼らに尋ねます-それでも尋ねます。彼らがどれほど重要であるかについて心配する必要はありません。もし彼らが忙しすぎるなら、別の時間に戻ってくるか、彼らと一緒にそれを残すように手配をしてください。
それができたら、最良の結果が得られると思うものを何でも構築し始め、残りの仕様が入力されるのを待つことができるはずです。
私の経験は次のとおりです：
- 私が取り組んだほとんどのプロジェクトでは、最初にデータベースを設計しました。
- 多くの場合、データはスプレッドシート、レガシーデータベース、紙などにすでに存在します。そのデータは、保持する必要のあるテーブルについてのヒントを提供します。
- 多くの場合、プロセスはすでに使用されていますが、手動で、または自動化されていない、相互運用されていない、または標準に準拠していない複数の異なるツールを使用しています。
- ある程度成熟したデータベースモデルを作成したら、そのデータベースに対して読み書きするプロトタイプフォームやウィンドウなどの設計を開始できます。
- 続行するにつれ、最初は考えていなかったことに対応するために、いくつかの変更が必要になります。
次も覚えておいてください：
- もはや、1つのアプリから<-> 1つのデータベースの世界ではありません。アプリが複数のデータベースからデータを読み書きする必要がある場合や、ソリューションが同じデータベースを使用する複数のアプリで構成される場合があります。
結論：最初にデータベースを設計することをお勧めします。
大規模なプロジェクトで多くの経験があり、多くの開発者が並行して作業している場合は、確かなデータモデルが本当に必要なので、データベースファーストと言います。
しかし、それについてもう少し考えましたが、成功した大規模プロジェクトで実際に行っているのは「要件が最初」であることに気付きました。
適切に指定されたビジネス要件のセットは、機能要件の適切なセットにつながります。機能要件のセットが適切な場合、データモデルとモジュールの仕様は、それほど労力を費やすことなく適切に配置されます。
これは流動的/詳細不明のように見えるので、最初にフロントエンドGUIを実行します。これは、利害関係者からの応答、サポート、時間、およびフィードバックを取得するために必要なことのように聞こえますか？彼らはあなたの見事な正規化されたテーブルと外部キー制約とカスケード削除について気にしません。しかし、光沢のある色がたくさんあるクールなGUI-まあ、それは最高です！
最初のバックエンド「データベース」には、非常にシンプルなものを使用します。ファイルに格納されているキー/値だけを使用する場合があります。私はMS Accessに慣れていないので、「最も軽量な」バックエンドが何であるかを知りません。 （スプレッドシードテーブル？）速くて汚いものは何でも、それを捨てることを計画してください。
可能であれば、GUIで 面白いルックアンドフィール を使用して、それがプロトタイプであることを明確にします。他のすべてが失敗した場合は、インデックスカードを使用します。
さて、おそらくあなたの利害関係者はDBの専門家です-それは時々私にも当てはまります！ -その場合、いくつかのDB設計を行います。