アプリケーションコードを記述する前にデータベースを設計する必要がありますか？

データベースを設計する最も簡単で効率的な方法は何ですか？私の観点から、アプリケーションのデータストア設計にはいくつかのオプションがあります。

1. アプリケーションコードを記述する前に、できる限りデータベースを最適に設計します。これにより、基本的なデータ構造を利用できるという利点が得られます。私の意見では、この欠点は、アプリケーションの開発サイクル全体でデータの内容/場所/方法が変化するため、アプリケーションの仕様として多くの変更が加えられることです。
2. アプリケーションが実を結ぶようにデータベースを設計します。アプリケーションの作成時にデータベースオブジェクトが必要な場合は、アプリケーションと並行して（年代順に）データベースを開発します。利点は、データベース構造の変更が少ないことです。欠点は、アプリケーションコードとデータベース開発の間で時間と開発の労力が分割されることです。

あなたの経験では、最も生産的で効率的な方法は何だと思いますか？

他の答えに加えて...

最初に概念モデルをキャプチャすると、範囲と要件が定義されます。これから、論理および物理データモデルを導出できます。

これがほとんど静的になったら、アプリケーションを構築するための安定したデータベースができました。これは最初のオプションに反します。

2番目のポイントは、汚い、維持できない泥のボールで終わります。データモデルは修正されません。前もって設計しなかった場合、出荷する前に修正する時間はありません。あなたは物事を一緒にハッキングするのに忙しすぎるでしょう。

スキーマのわずかな変更、テーブルの結合または分割、関係の変更などが発生しますが、ローカライズされた「アイランド」では、モデルと基本設計は変更されません。

アジャイルのバリアントを運用していない最新のソフトウェア部門を見つけるのは難しいでしょう。それに比べて、DBAは@RobPallerの答えにはまだ一般的な場所が含まれていると考えて、暗黒時代に立ち往生しています。

データベーススキーマの変更は、コードの変更ほど簡単ではありませんでした。そのため、データベースの開発と保守にアジャイルなアプローチを採用することに抵抗がありました。開発者と同様の方法で操作するためのツールとテクニックが揃ったので、間違いなくそうすべきです。スキーマを変更するのは簡単ではないからといって、それができないということではなく、そうすべきではないということでもありません。

私は、データベース設計に対する無計画なアプローチ（コメントを参照）を支持するのではなく、アジャイル開発チームのアプローチをより厳密に反映したアプローチにすぎません。アジャイルプロジェクトに参加している場合、将来発生する可能性のある（または発生しない可能性のある）作業の要件はないので、知っていることを設計する必要があります。

私はそれであなたの選択肢2に票を投じることになると思います。

論理データモデルは、アプリケーションのビジネス要件を効果的にキャプチャする必要があります。物理データベースの設計は、RDBMSの効率を最大化するためにDBAが感じる必要がある必要な変更と組み合わせた論理データモデルに基づいている必要があります。

アプリケーションのソフトウェア開発ライフサイクル全体を通して、基礎となるデータベース設計に多数の変更を加える必要があることに気づいた場合、次の2つのことを示しています。

1. スコープクリープ -不適切なときに新しい要件を導入することを許可しています。
2. 不十分なビジネス要件 -データモデラー（またはシステムアナリスト）がビジネスアナリストからの要件を十分に翻訳していません。これにより、アプリケーションの要件をサポートするためのデータモデルが不完全または不正確になりました。

アプリケーションが本番に引き継がれた後、アプリケーションまたは基盤となるビジネスプロセスの自然な進化をサポートするために、戻ってデータモデルを繰り返し変更する必要があることは珍しくありません。

お役に立てれば。

私は、Web、Access、C＃などのさまざまなフロントエンドで、すべてビジネスで使用されるいくつかの中程度の複雑さのデータベースを設計する贅沢を経験しました。

通常、私は事前に座ってデータベーススキーマを作成しました。これは常に私にとって最も意味がありました。ただし、変更を行ったり、新しいテーブルを追加したり、基本的に修正するには遅すぎた面を抱えて生活したりすることはありませんでした。

最初にコードを書くのが治療法だとは思いません。そして、私は問題が「不十分なビジネス要件」であるとは思いません。少なくとも、完全に解決できた問題ではないと思います。ユーザーは何が必要なのかわからず、私は彼らがより難しいと思うか、頭が良くなるか、もっと気づくか、私の質問によく答えるようにする力がありません。または彼らは主張し、私は何か特定の方法を行うように命じられます。

私が構築するシステムは、通常誰も行ったことのない新しい領域にあります。私は、組織からの賛同、リソース、またはトップフライトデザインの専門家の開発チームがチームで物事を構築するために作ったものの10倍の報酬を得たような仕事をするためのツールを持っていません倍の時間。

私は自分の仕事が得意です。しかし、「開発を行わない」環境でそれをしているのは私だけです。

とは言っても、ビジネスルールを発見するのは上手になっています。そして、私は一種の第三のオプションを見ます：

データベースを設計する前、およびコードを記述する前に、アプリケーションがどのように機能するかを示す粗雑な画面を描画します。フォント、サイズ、または寸法について誰もコメントできないように、手描きにする必要があります。機能のみが必要です。

透明度と紙片を使用すると、1人をコンピューター、2人を非専門分野の専門家（2人は大声で話す）、もう1人をメモと描画のファシリテーターとして交換できます。思考プロセスと混乱についてユーザーに知らせます。ユーザーがボックスをクリックしてドラッグし、ボックスに書き込むと、コンピューターが画面を更新し、全員がデザインを体験できます。開発プロセスに至るまで習得できなかったことを学ぶことができます。

おそらく私は自分自身に矛盾しています-多分それはより良い要件発見です。ただし、コードを作成せずに、最初にアプリケーションを設計するという考え方です。私はこれを小規模で始めましたが、うまくいっています！私の環境には問題がありますが、データベースを最初からより良く設計するのに役立ちます。複数のタイプがあるため、列を新しい親テーブルに移動する必要があることを学びます。ワークリストには、統合注文システムからではない継続注文が必要であることがわかります。いろいろなことを学びます！

私の意見では、これは大きな勝利です。

ほとんどの場合、オプション2を選択します。他のコンポーネントと並行してデータベースを構築します。可能な限り反復アプローチを採用し、各ピースを構築しながらエンドツーエンドの機能を提供します。

これには、ある程度のプロジェクト規律が必要です。品質を維持し、アドホックで一貫性のないモデルにならないように、データベースを変更するたびに、正規化を厳密に適用します（Boyce-Codd / Fifth Normal Form）。ビジネスルールと付随するデータベースの制約をできるだけ積極的に使用します。疑わしい場合は、早い段階で制約を実施する方が良いでしょう-いつでもそれを取り除くことができます。技術的な負債を最小限に抑えるために、アーキテクチャコンポーネントを実装する順序についてインテリジェントにします。すべての開発チームが購入する優れたデータベース設計ガイドラインを用意してください。

もちろん、これらすべては、継続的な統合、テストの自動化、およびデータベースの観点からの重要なテストデータの作成など、他の優れた開発エンジニアリング手法と連携する必要があります。現実的なサイズのデータ​​のテストデータ作成は、反復ごとに必ず行う必要があります。

建築の世界では、「フォームは機能に従う」というフレーズが造語され、後に高層ビルを建設する際に遵守されました。DBインフラストラクチャとアプリケーション開発にも同じことが当てはまります。

ここでテーブルとそこにテーブルが必要であることをその場で決定するアプリを書くことを想像してください。アプリが完成すると、膨大な数のテーブルが配列として扱われます。すべてのテーブルを並べて見ると、テーブルには韻や理由がないように見えます。

残念ながら、一部のデベロッパーショップはmemcachedのようなものを選択し、RAMにデータをロードし（データコンジットのように扱う）、MySQLやPostgreSQLのようなデータベースを単にデータストレージユニットとして動作させます。

データベースを使用する動機は、RDBMSとしてデータベースを適切に確認することです。はい、リレーショナルデータベース管理システム。RDBMSを使用するときの目標は、ストレージ用のテーブルを確立することだけでなく、取得することでもあるはずです。テーブル間の関係は、表示するデータとその表示方法をモデルにしてください。これは、既知のビジネスルールとともに、データの凝集性と整合性に基づいている必要があります。これらのビジネスルールは、アプリ（Perl、Python、Ruby、Javaなど）またはデータベースにコーディングできます。

結論

私は間違いなくオプション1を選択します。適切な計画、データモデリング、および継続的なデータ分析が必要です。ただし、これにより長期的にはデータベースの変更を最小限に抑えることができます。

アプリケーションの実際のコードを作成する前に実行する必要がありますが、アプリケーションを設計する前には実行しないでください。

単独で作業する場合の私の典型的なワークフローは次のとおりです。

1. アプリケーションが何をする必要があるかを決定する
2. 再利用可能なコンポーネントのタスクを分割できるかどうかを確認します
3. 各タスクがどのようにデータストレージとやり取りする必要があるかを決定します。どのような種類の質問をデータに要求するか、どのくらいの頻度で書き込むかなどです。
4. データベースを設計して、必要なすべての質問に回答できるようにし、最も頻繁に行われるタスクに対して適切に機能するようにします。
5. アプリケーションを作成します。

私はチームの一員として頻繁に仕事をしており、地理的に分散している（そしてタイムゾーンを越えて）ため、最初のキックオフミーティングを開催する傾向があります。

1. アプリケーションが何をする必要があるかを決定します。
2. アプリケーションを自己完結型のコンポーネントに分割するのに良い点を判断する
3. 各コンポーネントが他のコンポーネントと対話する方法を決定します。
4. 各対話のAPIに同意します。

次に、家に戻ってパーツを作成します。コンポーネントが独自のローカルストレージを必要とする場合は、そのパーツのメンテナーがモジュールのAPIの一貫性を維持している限りです。メインデータストレージは独自のAPIを備えたモジュールとして扱われ、人々はそれに書き込むことが期待されています。（DBの速度が重要な場合、APIはテーブル定義であり、変更が行われた場合、ビューまたは他のメカニズムを使用して、すべてのモジュールが更新されるまで古いバージョンを提示します）

次のルールを念頭に置いています：「データベースからは、生成するデータを持っている情報しか取得できません」。そこで、最初にデータベースを設計し、後でコードを設計します。

どうして？どの方法論/言語/ツールセットを使用しても、すべての関連データが適切に設計され、DBに保存されていれば、それを取得できます。C＃/ Delphi / FORTRAN / COBOL / Assembly / VBAまたはCrystal Reportsにあるかどうかは関係ありません。設計されたオブジェクト指向またはイベント/データ/なんでも駆動; アジャイルまたは滝。データがそこにある場合、使用するツールがデータベースに接続できる場合、データを取得できます。四半期の収益の注文を選択できる場合は、アセンブリでバイト単位で書き込む必要がある場合でも、販売レポートを作成できます。

関連するデータが存在しない場合、または存在する場合でも、必要な情報を取得できない方法で（非）構造化されている場合-コーディング方法

いつものように、それは依存します;）

たとえば、Pythonで開発され、フラットファイルを使用する小型の作業プロトタイプがあり、ユーザーがプロトタイプの機能に満足しているので、バックエンドとしてRDBMSを使用して、それをプロダクションするだけです。 。この場合、最初から正しく行うことを期待するのが妥当です。問題は小さく、明確に定義されています。そのような場合、事前に設計することが可能です。

一方、アジャイル環境で要件を発見するとき、それらをよりよく理解するためにいくつかの反復が必要です。そのような状況では、データベースはアプリケーションの他の部分とともに進化します。これは私たちが通常行うことです。ダウンタイムなしで低リスクでライブOLTPテーブルをリファクタリングできるため、データベースのリファクタリングの可能性に満足しています。