HStoreと継承のある複数のテーブル-HStoreの適切な使用例はありますか？
ここでの幅広い質問は、HStoreを使用するのが適切か、複数のテーブルを使用するのか、ドキュメントのようなオブジェクトを格納するために1つのテーブルを使用するのが適切かについてです。
さて、ローカライズした例として、実験結果を保持するためのデータベース構造を設計しています。私の最初のアイデアは、実験ごとに別々のテーブルを持つことでした。これは次のようになります。
ただし、エンドユーザーが複数の実験でデータを検索することはかなり一般的であるため、テーブル全体で多くのJOINsが必要になります。 （補足：継承の良いユースケースでしょうか？）このようなモノリシックな実験テーブルを用意することで、これを回避できると思いました。
それは確かにJOINsの必要性を排除しますが、個々の実験を何らかの方法で分離することは理にかなっていると思います。また、1つの実験全体が要求されることもよくあります。これが、次のようなHStoreの使用を検討している理由です。
個々の結果セットは非常にドキュメントに似ているので、これは私にとって魅力的ですが、複数のテーブルのアプローチがもたらすのと同じ問題に出くわすと思います。
関連する可能性のあるその他の考慮事項と考え：
- 個々の実験の個々のデータポイントに関連するメタデータ/注釈を格納するための追加のテーブルを用意することを検討しました。これの一部は、HStore実験テーブルに非常にうまく適合します。
- さまざまなユーザーが実験データを入力します。これにはスキーマを使用します
- 実験の種類はさまざまですが、これを処理する最善の方法は、まったく異なるデータベースに保存することです。
また、PostgreSQLの使用経験は非常に限られていることにも触れておきますが、MySQLに比べてPostgreSQLが何を提供できるかについてはすでに満足しています。
それは確かにJOINを持つ必要性を排除しますが、個々の実験を何らかの方法で分離することは論理的であると私は感じています。また、1つの実験全体が要求されることは非常に一般的です。
これらはどちらも、テーブルのパーティション分割を使用する場合の適切な引数です。 PostgreSQLは、継承と制約の除外によりこれを実装します。
個々の実験の個々のデータポイントに関連するメタデータ/注釈を格納するための追加のテーブルを用意することを検討しました。この一部は、HStore実験テーブルに非常にうまく適合します。
注釈用のhstoreフィールド、または注釈用のhstoreフィールドの個別の結合テーブルがあることを妨げるものは何もありません。
さまざまなユーザーが実験データを入力します。これにはスキーマを使用します
どうして？確かに同じ議論が当てはまり、クロスユーザー集約も行いたいと思いますか？
実験で分割し、テーブルのキーの一部としてユーザーIDを指定します。
実験の種類はさまざまですが、これを処理する最善の方法は、まったく異なるデータベースに保存することです。
どうして？
それらをクエリしたり、それらを集約したりする必要があると思ったことはありますか？その場合は、別のDBに保存しないでください。
類似の種類のデータが格納されている場合は、それらをメインテーブルに配置し、オプションの列をいくつか用意します。
主に異なる種類のデータ（ほとんどまたは完全に異なる列）を格納する場合は、同じDBで異なるテーブルを使用します。