私はこれまでRubyORRailsを使用したことがない開発者と一緒にプロジェクトに取り組んでいます。
私の意見では、彼らは複雑すぎるスキーマを作成しました。スキーマには117個のテーブルがあり、最も単純な情報を取得するには、7つのテーブルをトラバース/結合する必要があります...もちろん、それらの間の一種のキーとして機能する「メイン」テーブルはありません。スキーマは、「find」メソッドのような多くのrailsツールをレンダリングし、has_many/belongsの関係の多くはほとんど役に立たないものになります。そして、これらすべての関係のコーディングは、コーディングするお金よりも時間がかかる可能性があります。
質問：
スキーマが理想的ではないと非常に確信していて（IMHO ... hehe）、ドメインを表す方法が複数あると仮定すると、スキーマを単純化するためにどのように主張しますか（私がすでに言ったことは別として）？
ここで2つの役割で立ちます
DBAは、データベースのすべてのトリックを本当に知っている人だと思います。本当に知っています。
DBA：
データベースはアプリケーションの鍵であり、その目的を十分に果たし、最高のパフォーマンスを発揮するために、事前定義された構造を持っている必要があります。
ランダムスキーマ（適度に正規化されていて適切）を使用できない場合は、ツールが間違っています。
開発者：データベースは単なるデータストア
であるため
、データベースをシンプルに保ち、アプリケーションに集中する必要があります。
DBA：
データベースはストアではなく、アプリケーションの中核です。データベースのないアプリケーションはありません。
開発者：
いいえ。アプリケーションがコアです。フロントエンドとそれに適用されるビジネスロジックがなければ、アプリケーションはありません。
そして戦争が始まる...
両方のポイントが有効であり、常にトレードオフになります。
データベースがRoRによってのみ使用される場合は、単純なストアのように使用できます。DBを他のアプリケーション
で使用できる場合、または大量のデータと大量のトラフィックで使用される場合は、いくつかのベストプラクティスを適用する必要があります。
一般的に、DBAに異議を唱える方法はありません。
しかし、彼らはあなたの状況を理解することができ、あなたがより生産的になることができるようにあなたが基準を少し緩めることを可能にするかもしれません。
ですから、一緒に緊密に協力する必要があります。
そして、データベースがこのようなものである必要がある理由を説明し、証明するために、お互いに話し合う必要があります。
そうしないと、チームが壊れて、プロジェクトが失敗する可能性が高くなります。
ActiveRecordは非常に便利なツールです。しかし、それはあなたのためにすべてを行うことはできません。デフォルトでは、正確に期待されるデータベース構造は提供されません。したがって、調整する必要があります。
反対側。DBAがすべてのPKが自動インクリメントされた整数であることを受け入れることができる場合、開発者の作業が楽になります（ActiveRecordはデフォルトでそれを行います）。
一方、開発者がDBAの制約の一部を受け入れると、DBAの作業が楽になります。
今あなたの質問に答えるために：
スキーマを単純化するためにどのように主張しますか
議論しないでください。チームに会い、メッセージを伝え、なぜそれを行うべきかを指摘します。
多分それは本当にすべきではなく、あなたはすべてのことを知らないでしょう、多分彼らは何かに気づいていません。
データベースの一般的な構造に同意し、メタ言語としてRoR移行を使用してデータベースを記述してみることができます。
このように、彼らは全体像を見るでしょう、そしてあなたはあなたの素晴らしいActiveRecordsを使うでしょう。また、全員が同じページに表示されます。
DBスキーマは、ドメインとその関係を反映している必要があります。
非正規化は、パフォーマンスの問題があることを測定した場合にのみ実行する必要があります。
適切なインデックスが設定されていれば、7つの結合は過度でも悪いものでもありません。
この議論を連鎖的に行う一般的な方法は、コストに基づいています。単純に行うと、コードとバグが少なくなります。システムは、より迅速に、またはより多くの機能を使用して構築できるため、より多くのROIが得られます。あなたがそのアプローチでマネーマネージャーを参加させることができれば、彼または彼女はあなたにチームに条件を指示させるかもしれません。極端な過剰正規化は不良データを防ぐという反論がありますが、それが引き起こす複雑さは一般により多くのエラーとより多くのデータベースコードにつながる傾向があるため、そうではないことがわかりました。
ここでのアーキテクチャと技術の議論は単純です。RubyonRailsを使用することにしました。したがって、ActiveRecordパターンを使用することにしました。ActiveRecordパターンは、データベーステーブルをオブジェクトモデルと一致させることによって駆動されます。これは、ここや他の多くの場所で使用されているパターンであるため、極端なデータ正規化に適用しようとしているベストプラクティスは単純に適用されません。エンタープライズアプリケーションアーキテクチャのパターンのコピーを購入し、160ページに小さな赤いブックマークを付けて、アーキテクチャの観点からパターンがどのように機能するかを理解できるようにします。
DBAタイプが気付かない傾向があるのは、クエリ生成、カスケード削除、楽観的ロック、自動入力列、バージョン管理（acts_as_versionedを使用）、ソフト削除（acts_as_paranoidを使用）など、ActiveRecordが実行する作業の量です。十分にテストされ、コミュニティでサポートされているライブラリ関数を使用してこれらの操作を実行することと、DBAが保守する必要のあるカスタムコードを使用することを強く主張します。
DBAの本当の問題は、実行するためにいくつかの作業が必要になることです。パフォーマンスの監視、コード内の遅いクエリの検索、インデックスの作成、バックアップの実行に集中してもらいます。
正気のスキーマをめぐる政治的戦いに負けることになった場合は、DataMapperへの切り替えを検討することをお勧めします。これはPoEAAの次のパターンです。それらに実行させることができる他のことは、オブジェクトモデルに対応するビューをデータベースに作成することです。このように、ビューに基づいてActiveRecordモデルの検索機能の多くを使用できますが、カスタムの挿入、更新、および削除メソッドがあります。