問題タブ [denormalization]

私はデータベース駆動型システムの開発の初期段階にあり、システムの大部分は継承タイプの関係を中心に展開しています。約 10 列の親エンティティがあり、親から継承する約 10 の子エンティティがあります。各子エンティティには、約 10 列があります。親エンティティに独自のテーブルを与え、それぞれの子エンティティに独自のテーブル (サブクラスごとのテーブル構造) を与えることは理にかなっていると思いました。

今日、ユーザーから、私が作成したシステムの構造を見せてほしいというリクエストがありました。彼らは、table-per-subclass 構造のアイデアに難色を示しました。独自のカスタム クエリを実行しやすいため、100 列までの大きなテーブルを 1 つ好むでしょう。

ユーザーのためにデータベースの非正規化を検討する必要がありますか?

仕事で繰り返し発生するテーマとなる問題への答えを見つけていただければ幸いです。これには、RDBMSテーブルからのデータを、列間でグループを繰り返す（ドメインと意味を共有する）フラットファイル形式に非正規化することが含まれます。残念ながら、これは避けられません。

これが私が必要とする変換の非常に単純化された例です：

これは次のようになります。

からの各エントリTABLE Aには、出力フラットファイルに1つの行があり、からの関連フィールドごとに1つの列がありますTABLE B。出力ファイルの列には、から取得したフィールドの値を空にすることができますTABLE B。

これにより非常に幅の広いファイルが作成されることはわかっていますが、これは必須です。MapForceとApatarを見てきましたが、この問題はあまりにも奇妙であるか、正しく使用できないと思います。

私の質問：これを実現するツールはすでにありますか、それとも最初から開発する必要がありますか（車輪の再発明はしたくない）？

わかりました、この db スキーマ (リレーション) があるとします:

テーブル User は Authlogic によって生成されます。

私には2人の登録ユーザーがいて、それぞれに顧客がいます。Authlogic を使用すると、認証されたユーザーのみがコントローラー/ビューにアクセスできるようになります。それは問題ありません。それが Authlogic の目的です。

ここで、user#1 が user#2 の顧客に属する情報にアクセスしないようにする必要があります。

つまり、ユーザー #1 がhttp://myapp.com/carsにアクセスすると、ユーザー #1 の顧客に属する車のリストが表示されます。

id=131 の車が user#1 の顧客に属している場合、user#1 だけがこの情報 ( http://myapp.com/car/1 ) にアクセスできる必要があります。ユーザー#2 がブラウザに同じリンクを挿入した場合、この情報を見ることができる必要はありません。

レコードが current_user に関連付けられているかどうかを確認するために、ユーザーと各 db テーブルの間に関係を作成することを提案する人もいました。

どう思いますか？最善のアプローチ/ソリューションは何ですか?

POCOクラスとDBの間にLinqからSQLへのマッピングがあります。単純なscalr値よりも少し複雑な構成を表すプロパティをクラスに追加できるようにしたいと思います。

たとえば、2つの単純なスカラー値を保持するカスタム構造体タイプがあります。これを別のテーブルにしてから、プロパティとしてFKを追加したくありません。LinqからSQLへのXMLマッピングファイルを使用して、この構造体のプロパティをマッピングすることは可能ですか？

例えば、

Blah、、Yada.AおよびYada.BすべてがFooテーブルの列として永続化されるように指定するにはどうすればよいですか？

これもできますか？

私の Rails アプリケーションには、ユーザー データを含むさまざまなデータベース テーブルがあります。これらのテーブルの中には、多数の行 (場合によってはユーザーごとに 500,000 行) があり、頻繁にクエリが実行されます。テーブルに何らかのクエリを実行するたびに、現在のユーザーの user_id がクエリのどこかにあります。テーブルがユーザーと直接関係がある場合は直接、または他のテーブルを介して関係している場合は結合を介してです。

パフォーマンスを向上させるために、user_id を非正規化してすべてのテーブルに含める必要がありますか?

一例を次に示します。

• アドレスはユーザーに属し、user_id を持っています
• エンベロープはユーザーに属し、user_id を持っています
• AddressesEnvelopes は Address と Envelope を結合するため、envelope_id と address_id があります。user_id はありませんが、envelope または address (同じユーザーに属している必要があります) のいずれかを介してアクセスできます。

一般的な高価なクエリの 1 つは、特定のユーザーのすべての AddressesEnvelopes を選択することです。これは、Address または Envelope のいずれかと結合することで実現できますが、これらのテーブルからは何も必要としません。または、このテーブルでユーザー ID を複製することもできます。

別のシナリオを次に示します。

• レターはユーザーに属し、user_id を持っています
• 受信者は Letter に属し、letter_id を持っています
• RecipientOption は Recipient に属し、recipient_id を持っています

レターを介してアソシエーションを経由することでいつでもアクセスできますが、受信者と受信者オプションの両方で user_id を複製することは理にかなっていますか?

いくつかのメモ:

• ユーザー間で共有されるオブジェクトはありません。関連オブジェクトの階層全体は、常に同じユーザーに属します。
• オブジェクトのユーザー所有者が変わることはありません。
• データベースはデータ集約型のアプリケーションであるため、データベースのパフォーマンスは重要です。多くのクエリと多くのテーブルがあります。

では、インデックスを作成するときに使用できるように、すべてのテーブルに user_id を含める必要がありますか? それとも設計が悪いのでしょうか？

パフォーマンスのためにトランザクション データベース内のデータを非正規化する場合、(少なくとも) 3 つの異なるアプローチがあります。

1. 正規化されたトランザクション データと非正規化されたレポート/分析データの両方を更新するストアド プロシージャを介して更新をプッシュします。

2. セカンダリ テーブルを更新するトランザクション テーブルにトリガーを実装します。これは、ほとんどの場合、履歴を維持するときに取られるルートです。

3. 処理を夜間のバッチ プロセスに延期し、データ マート/ウェアハウスに ETL を実行する可能性があります。

この質問の目的のために、オプション 3 は実行できないと仮定しましょう。これは、ドメインでは非正規化されたデータが正規化されたデータと常に一致している必要があるためです。私が頻繁に扱う階層集計は、その一例です。

私は最初の 2 つのアプローチの両方をかなり使用してきましたが、最近はトリガーベースのアプローチに傾倒していますが、まだ発見していない「落とし穴」があるかどうか疑問に思っています。この質問をする価値があるので、将来長期的な決定を下すときに心に留めておくべきいくつかのアイデアがあります.

あなたの経験では、リアルタイムの非正規化データを維持するという特定の目的のために、どちらのツールの長所と短所は何ですか? どのような状況でどちらか一方を選択しますか?その理由は?

（PS「トリガーが複雑すぎる」や「すべての更新は常にストアドプロシージャを通過する必要があります」などの回答はしないでください-質問のコンテキストに適したものにしてください。）

お恥ずかしい話ですが、最近、相互に関連する 3 つの異なるタイプの銀行エンティティに対して 1 つのテーブルを作成する必要がある状況がありました。説明させてください。

統治銀行、地方の支店を運営する通常の銀行、またはこの銀行の下で運営されている地方の支店、またはこの階層には属さないが地方の支店とのみ取引するリテール銀行の支店の詳細を保持する BANK テーブルを想像してみてください。

以前は、FK 制約 (管理銀行、地方支店を運営する銀行、地方支店、リテール銀行支店にそれぞれ 1 つずつ) を使用して、これらに 4 つの異なるテーブルを用意することにしました。しかし、TRANSACTION テーブルの作成に移ったとき、これらのエンティティのいずれかの間でトランザクションが発生する可能性があるため (例: 地方の支店と小売店の間、地方の支店同士など)、当惑しました。これは、銀行エンティティの「ソース」と「宛先」ID の記録を保持するだけでなく、アプリケーション ロジックがクエリのためにどのテーブルに結合するかを決定するのに役立ついくつかのデータを保持する必要があることを意味しました。悪い。

さらに、USER テーブルがあり、ユーザーはこれらのエンティティのいずれかに属している可能性があります。ここでも、銀行エンティティの 4 つの異なるテーブルがあると問題がありました。ユーザーが地方の支店、小売店、または管理銀行に属しているかどうかはどうすればわかりますか?

したがって、単一の BANK テーブルを作成しました (基本的に、これらは互いに取引できるため、類似したエンティティであるためです)。親機関の ID の値を保持する PARENT 列をテーブルに追加しました (別の方法で FK を使用して達成した関係)。したがって、地方の支店は、親列に営業銀行の ID を持ちます。小売店の支店には親がないため、値は NULL です。

私が今見ている問題は、循環参照である BANK テーブルに PK/FK 関係があることです。

私の質問は次のとおりです。これはどれほど悪いですか？そして、何が抜け道になるでしょうか？

私の質問はおそらく、以前にここで尋ねられた質問の反響かもしれません: How to design a User Object Model using MS Roles & Membership、しかし、まだ良い答えがなく、私の質問はデータモデルの設計を対象としているため、もう一度質問しますとりあえず：

とにかく、私のアプリケーションにはユーザーとグループがあります。ユーザーは多くのグループに属することができ、もちろんグループには多くのユーザーを含めることができます。問題は今のところ、ユーザー、ゲスト、管理者のいくつかの基本的なグループしかわかっていません。将来的には、can-do-X、can-do-Y グループが存在する可能性があり、管理者、ユーザー、およびゲストだけでなく、それ以上またはそれ以下になる可能性があります。だから私は簡単なアプローチを取るように誘惑されています. アプローチについての私の考えは次のとおりです。

必要最小限の User テーブルと Role テーブル、および多対多の関係をシミュレートする別のテーブルを用意しようとすると、少し過剰に設計されているように見えます。私が正しく理解していれば、これは正規化されたアプローチと見なされます。逆に、IsAdmin、IsGuest、CanDoX、CanDoY などの次の列を User テーブルに投入すると、これは非正規化されます。

複雑さと柔軟性、時間と空間などのバランスをとろうとしています。提案してください。

私の Web アプリは投票 (調査) を扱います。現在、データベース スキーマの一部として 2 つのテーブルがあります。

これに関する問題は、一部の投票で多くの回答 (>1000) があることです。人々は投票の結果を見ることができ、何人のユーザーが「はい」、「いいえ」、または「多分」と投票したか、また何人の匿名ユーザーが「はい」、「いいえ」、または「多分」と投票したかが表示されます。これに関する問題は、ユーザーが投票の結果を表示するたびに、すべての回答をループして、回答の総数、各選択肢の回答数、ユーザーが行った各選択の回答数、およびtracker_id (匿名ユーザー) が行った各選択に対する応答の数と、パーセンテージを計算して棒グラフで表示します。これにより、ページの読み込みが非常に遅くなります。データベースを非正規化してパフォーマンスを向上させて、このようなものにすることを考えていました

つまり、 の値の場合total_responses、10 は合計、3 は Choice の応答数、yes3 は Choice の応答数no、4 は Choice の応答数ですmaybe。user_responsesフィールドとフィールドにも同じフォーマットが適用されanon_responsesます。この方法について意見をいただければ幸いです。御時間ありがとうございます。

編集：MySQLを使用しています

特定のアプリケーションのパフォーマンスを向上させるために行われた非正規化についてよく耳にします。しかし、私は関連することを試みたことはありません。

ですから、正規化されたDBのどの場所がパフォーマンスを低下させるのか、つまり、非正規化の原則とは何ですか?

パフォーマンスを向上させる必要がある場合、この手法をどのように使用できますか?