web-dev-qa-db-ja.com

誰がウェブ開発でデータベースを設計していますか？

Web開発のコンテキストで、誰がデータベースを設計しますか？バックエンドのWeb開発者をサーバー側の処理、データモデリングなどに関連付ける情報のホスト全体にもかかわらず、方程式のデータベース設計の側面は神秘的に存在しないようです。

誰が物理データベースを設定するかということではありません。データベースの論理モデルを設計する人、ユーザーストーリーのインタビューを実施して、必要なフィールド、フィールドの仕様などに関する情報を取得することを指します。 。

（[〜＃〜] proper [〜＃〜]）データベースの設計は小さな作業ではないことに気づきました（私は読んでいます this 672ページャー）であり、簡単に職業全体になる可能性があります。ただし、インターネットを上下に検索しても、Web開発のコンテキストで誰がこのタスクを処理することが期待できるかについては、驚くほど少ない結果しか得られていません。

designweb-developmentdatabasedatabase-design
10
the_endian

あなたの質問は、ウェブアプリだけでなく、データベースバックエンドを使用するあらゆる種類のアプリに関連しています。

私の経験では

  • データベースの設計は、開発者とDBAの共同作業です。
  • 開発者は、大まかな、または多くの場合非常に優れたデータベース設計を行います。それはすべて、プログラマーの経験に依存します。
  • 多くの場合、開発者は開発データベースにテーブルを作成し、そこから概念モデルがリバースエンジニアリングされます。
  • 多くの場合、概念的なERダイアグラムは他のチームメンバー、多くの場合クライアントと話し合います。この段階では、明らかな概念上のエラーが検出され、うまくいけば、解決されます。
  • DBAの仕事は、そのような設計をレビューし、通常のフォームの違反を検出するように微調整することです。
  • また、DBAはテーブルと列の命名規則を実施します
  • また、DBAはパフォーマンスのボトルネックの可能性を想定し、後で適切なインデックスを作成するためにデータがどのようにクエリされるかを理解しようとします。
  • 開発者/アプリデザイナーとDBAの間の改訂/チェック/修正サイクルは、モデルが物理モデルを生成するのに十分成熟するまで、いくつかの反復を経ます。
  • 通常、データベース設計ツールは、このプロセスを支援するために非常に小さなデータベースを除くすべてで使用されます。

ボトムライン：

  • 開発者はDBAよりもビジネスと問題の領域をよく理解しているため、初期設計のほとんどを行い、開発者の経験によっては、このような設計は最終設計に非常に近い場合があります。
  • DBAの役割は、ほとんどの場合、NF、命名規則、パフォーマンスの考慮事項を確認し、明らかなエラーを修正し、最後に物理モデルを生成し、次にデータベース固有のスクリプトを生成して、これらを実行してデータベースを作成することです。
  • 80％の開発者と要件の分析作業、20％のDBA作業だと思います。

更新：

DBAには次の3種類があります。

  • データモデリングを理解し、SQLの専門家であり、ストアドプロシージャを記述できる開発DBAは、通常、元開発者です。
  • インストール、パフォーマンス調整、バックアップ、復元などを専門とする運用DBA
  • そして、これらすべてのことを実行してきて、ほとんどが実行できる（それらは非常に少数です）、あらゆる取引のDBAです。

ほとんどのDBAは本番のDBAです。これは、夜間の非常に短い時間に、障害が発生したディスクアレイから失われたデータベースを回復するためです。ただし、設計プロセスには積極的に参加していません。

17
Tulains Córdova

使用するデータベースの用途によって異なります。

多くのアプリケーション（Webアプリであるかどうかに関係なく）では、データベースはそのアプリケーションの永続ストアとして機能するため、そのアプリケーションに密接に関連付けられています。次に、データベースは概念的にはアプリケーションの一部であるため、一緒に設計されます（そして、他のプログラムがそのデータベースに大幅にアクセスまたは更新しないと仮定します）。ところで、 persistence は、データベース以外の方法で実現できます。プレーンテキストファイル、バイナリファイル（特にインデックス付きファイル [〜＃〜] gdbm [〜＃〜] ）、 git （または他のVCS）リポジトリ、ディレクトリ、またはファイルツリー、rawディスクパーティション、専用ハードウェア（フラッシュなど）、リモートファイルシステム、 チェックポイント テクニック。 1つのアプリケーション用に設計されたデータベースの場合、一般的な取得と更新のパターンに注意し、それらを念頭に置いてデータベーススキーマ（およびインデックス作成）を設計する必要があります。

状況によっては、データベース自体が主要で独立した資産であり、severalさまざまなアプリケーション（および将来のアプリケーション）で使用されるようにアプリオリに設計されています。次に、独立して（そしてより慎重に）設計する必要があります。

特に、一部のWebアプリは既存のデータベースへの単なるWebインターフェイスです。

多くの場合（いくつかのwikiを例として考えます）、データはそれを使用するアプリケーションよりも重要であり、より価値があります。あなたはそれを将来の証拠にして、それを簡単に進化させることができる方法に関心があるかもしれません（たとえば、それをバックアップおよび復元するために、テキストおよび多目的-できれば標準化され、文書化されたフォーマットを使用または定義することによって）。

データベースの（適切な）設計は簡単な作業ではないことに気づきました...

NoSQL 、 ドキュメント指向のデータベース 、 Key-Valueデータベース 、 知識管理 、 知識表現と推論 、 オントロジー 、 専門家システム 、 ビジネスルールアプローチ 、 [〜＃〜] erp [〜 ＃〜] 、 [〜＃〜] cms [〜＃〜] 。 [〜＃〜] redis [〜＃〜] 、 MongoDB などの使用を検討してください。

4
Basile Starynkevitch