私のデータベースには、さまざまな質問に関するユーザー統計が保存されています。質問タイプのテーブルがないため、質問タイプで結合テーブルを使用する代わりに、ユーザーが行った各タイプの質問のユーザー統計をユーザーテーブルのシリアル化されたハッシュマップに保存しました。明らかに、これはいくつかのまともなサイズのユーザー行につながりました-私自身のユーザーのシリアル化された統計は約950文字であり、パワーユーザーでは簡単に5kbに成長すると想像できます。
私はどの本でもこれほど大きなコラムの例を読んだことがありません。テーブルにこのような大きな/可変の列があると、パフォーマンスが大幅に低下しますか？質問タイプのテーブルを追加し、ユーザー統計も別のテーブルにする必要がありますか？
必要に応じて、現在PostgreSQLを使用しています。
このシリアル化されたアプローチは、WebワークフローやBPMアプリであり、データをシリアル化された方法で保存するProcessMakerなどのシステムで見たことがあります。パフォーマンスは非常に優れていますが、このデータに基づいてレポートを作成するのは非常に困難です。
データベースを正規化することができます（そしてそうすべきです）。これは、情報モデルがそれほど頻繁に変更されない場合は問題ありません。
それ以外の場合は、RavenDB、MongoDBなどの非リレーショナルデータベースを試してみることをお勧めします。
大きな欠点は、select*で何が起こるかと関係があります。特定のフィールドリストがある場合、大きな問題は発生しない可能性がありますが、TOASTされた列が多いselect *では、すべてがメモリに収まらない限り、余分なランダムディスクI/Oがたくさんあります。選択する列の数を減らすと、状況が改善されます。
PostgreSQLのようなオブジェクトリレーショナルデータベースでは、データベースの正規化は、純粋なリレーショナルモデルとは異なるトレードオフをもたらします。一般に、それはまだ良いことです（私が言うように、DBでORを実行する前に、リレーショナルモデルを快適に実行できる範囲でプッシュします）が、それが純粋にリレーショナルデータベース。さらに、正規表現を使用してそのデータを処理したり、JSONから要素を抽出したりする関数を追加して、それらをリレーショナルクエリに戻すことができます。したがって、快適に正規化できないデータの場合、大きなアモルファス「docdb」フィールドはそれほど大きな問題ではありません。
必要な主なクエリによって異なります。
もちろん、これはすべて、シリアル化されたデータがデータベースの観点から「ブラックボックス」として動作することを前提としています。そのデータを何らかの方法で検索または制約する必要がある場合は、ダミーのバイト配列を格納するだけで原子性の原則に違反するため、1NFに違反するため、データの正規化を検討する必要があります...
1つまり、めったに使用されない列を、元のテーブルと1：1の関係にある2番目のテーブルに移動します。BLOBを使用している場合は、BLOBのどの部分を「インライン」に保つ必要があるかを宣言することで、同様の効果を得ることができます。その制限を超えるBLOBの残りは、テーブルの「コア」とは別のページのセットに格納されます。 "ページ。
2 DBMSは通常、ページレベルでキャッシュを実装するため、行が広いほど、ディスク上の1つのページに収まる行は少なくなり、したがって、キャッシュ内の1つのページに収まります。
シリアル化された配列を検索することはできません。