データベースを設計するのはプログラマの仕事ですか？
私は過去6年間プログラマーでした。私のキャリアを通じて、多くのWebアプリケーションに取り組んできました。
ほとんどの場合、データベースが必要な場合、それは私たち（プログラマー）に提供されました。そうでなければ、私たち自身でデータベースを作成して設計する必要がありましたが、それほど難しくありませんでした。
しかし、プログラマーとして、データが非常に重要で、複雑なデータモデルで厄介な要件がある新しいアプリケーションを構築する必要がある場合、データベース全体を最初から作成することになっていますか？
専門家がそれを成し遂げることは、アプリと会社の最善の利益ではないですか？
私はデータベースの設計から逃げようとはしていませんが、正しく理解することは非常に重要です。
まず、プロジェクトマネージャーからの指示があれば、それはあなたの仕事です。中小企業には、専任のDBエキスパートがいないことがよくあります。いずれにしても、開発者とDBの専門家の間には明確な区別はありません（すべきではありません）。優れた開発者はDBについてかなりの知識を持ち、優れたDBAは、少なくともストアドプロシージャのDB言語でコーディングする方法を知っています。 。
DBの設計はアプリケーションのかなり中心的な部分ですが、他の多くのコードが依存する他の中心的な部分よりも「正しくなる」ことが重要です。
そして、コードと同じように、スーパーエキスパートに1週間座って考えてから、変更する必要のない完璧なデザインを書き留めるというのは幻想です。 DB設計は、アプリケーションの開発中に変更される可能性があり、今後も変更されます。
したがって、プログラマー（DBをよく理解しているプログラマー）がDBを設計することは実際に有益です。それは、両側を知っている誰かがいるからです。これは、DBを理解しているだけで、残りの開発作業とは何の関係もない人が行うよりも確かに優れています。
プログラマーがデータベースを作成することは一般的です。ごく普通。残念ながら、多くのプログラマーはDBの経験がありません。彼らは、ビッグデータ、データマートの概念、スタースキーマなどに対するレポートの方法を理解していません。正規化の基本さえ理解していない人もいます。
一人の男が専門家レベルですべてを行うスキルを持っている場合、それは非常に良い製品になります。 1人の軍隊は、10人のチームができる時間をほんの一瞬で1000倍の品質で実行できます。誇張ではありません。
プログラマーが何をしているのかをプログラマーが知っていると想定して、それを行うこと（人が少ない）はプログラマにとって最善の利益になります。もちろん、指摘しなければならない失敗は何千もあります。
その興味深い質問-ほとんどのまともな開発者は、リレーショナルデータベースを適切に構造化する方法を理解する必要があるという強い議論があります。つまり、正規化されたスキーマを作成でき、経験と一般的なパターンに基づいて、合理的なデータをどのように構造化して格納するかに関する決定（私にとってはほとんど自明ですが、誰もがそのように見ているわけではないことを知っています）。
さらに、Entity Framework Code-firstを見ると、低レベルのデータモデルを構築するのと同じ考え方が妥当なスキーマを生成する-または少なくとも1つのヒントになることが示唆されています。
ですから、データベーススキーマを設計するのにデータベースの専門家が必要だとは特に思いません。少なくとも、中小規模のデータベース（私が取り組んできたもの）の場合はそうではありません。
問題は、優れた（または少なくとも適切な）スキーマの設計がすべてではないことです。特に、データベースをスケーリングする必要がある場合はそうではありません。 DBAによってもたらされる「付加価値」は、基本的なスキーマ以外のものを正しくすることです-インデックス、ストレージの構成、データベースのメンテナンス（ファイルサイズのチェック、インデックスの再構築など）、よりスマートにユーザーやロールなどを使用します。
優れたプログラマーは、多様なスキルのポートフォリオをもたらす必要があります。[選択した言語を挿入]コーダー以上である必要があり、そのポートフォリオにはデータベースの理解も含めます。
合理的なリレーショナルデータベースを設計する機能は、ジュニアプログラマ以外のプログラマにとって本質的に必要だと思います。
そうは言っても、特に大規模なアプリケーションの場合、データベースを最初に「正しく」取得することが重要です（スキーマ、インデックス付けなど）。会社が熟練したDBAにアクセスできる場合、そのタスクは自分たちの責任にあてはまるはずです。一般的に、彼らはより資格があります。予想外の結果が出ないように、クライアント側でデータベースにアクセスして作業するリード開発者と潜在的にレビュー/ディスカッションを行う必要があります。 DBAがいない場合、プログラマはデータベースを設計します。
ここに2つの質問があります。
- データベース開発者はビジネスロジックをモデル化する必要がありますか？
- データをデータベースに永続化する方法を知っている必要がありますか？
ビジネスロジック
ビジネスロジックはデータベースに存在しません。これは、システム内の他のレイヤーから独立している必要がある概念モデルです。
常に1つのデータベースを別のデータベースに置き換えることができます。または、潜在的なパフォーマンスの問題に対処するためにNoSQLソリューションを使用することもできます。
データベース開発者はモデリングプロセスに関与することができますが、通常、これは問題のあるドメインを完全に理解している人が行います。私たちの組織では、これはサーバー側の開発者によって行われます。
多くの人は、データベースがアプリケーションの基盤であると考えています。貧弱な基盤を作ると、システムが落ちます。私はこれに同意しません。私はデータベースをいつでも交換できる記憶媒体と考えています。
永続データ
SQLおよびNoSQLソリューションを含むさまざまなストレージメディアにデータを永続化する方法を知っている必要があります。
必要な専門知識のレベルは、作業しているシステムのサイズによって異なります。
中小企業は、通常、大企業がパフォーマンス、スケーラビリティ、およびセキュリティ関連の要件に対処するために専門家を雇うときに、その知識を持っていることを期待します。
要約するには：
ドメインモデルは、データベースではなくシステムの基盤です。
比較的小さなプロジェクトで小さな会社で働いている場合は、おそらく自分でデータベースを設計する必要があります。
大企業でエンタープライズシステムを使用している場合は、ドメインの専門家に仕事を渡す方が理にかなっています。