私はpostgresql dbを使用しています。 私のアプリケーションは、同じタイプの多くのオブジェクトを管理します。 私のアプリケーションは強烈なdbの書き込みを行います - 各オブジェクトには少なくとも30秒に1回dbが挿入されています。私はまた、オブジェクトIDでデータを取得する必要があります。 私の質問は、どのようにデータベースを設計するのが最適ですか？すべてのオブジェクト（より遅い挿入）に1つの巨大なテーブルを使用するか、オブジェクトごとにテーブルを使用します（より複雑な検索）。postgres多数のテーブル対1つの巨大テーブル
テーブルには、同じタイプの膨大な数のオブジェクトが格納されます。したがって、オブジェクトごとに1つのテーブルである2番目のオプションは、正しく見えていないようです。もちろん、より多くの情報が必要です。
ヒント：1つのテーブルから始めます。主にパフォーマンスに問題が発生した場合は、それを分割してください。それほど難しいことではありません。
すべてのオブジェクトが引き続き同じ属性を持つことが確実である場合は、おそらく単一のテーブルが最適なソリューションです。
INSERTテーブルの増加に伴い大幅に遅くなることはありません。–は、データ変更の速度を遅くするインデックスの数です。
私はむしろデータの増加について心配したいと思います。古いデータを取り除くためのデザインはありますか？大きなDELETEは痛いかもしれません。ときどきパーティション化が役立ちます。
論理的には、1つのテーブルを使用する必要があります。
しかし、PostgreSQLが示すいわゆる「書き込み増幅」の問題は、主な理由の1つであると思われます。Uber switeched from PostgreSQL to MySQL。 、
セカンダリインデックスの数が多いテーブルの場合」、これら 余分のステップは巨大な非効率性を引き起こす可能性があります例えば、 は、我々はそれに定義されたダース・インデックスを持つテーブルがある場合 への更新：見積もり1つのインデックスのみでカバーされているフィールドは、 に新しい行のctidを反映するために12のインデックスすべてを伝播する必要があります。
ワークロードに問題があるかどうかは、測定値のみでわかります。パフォーマンスを測定してから、マルチテーブルに切り替える（またはパーティションを分割する、またはDBMS全体を切り替える）ことをお勧めします。測定がそれを正当化する場合に限ります。
テーブルの構造は明確ではありませんが、一般的にテーブルにはレコードの挿入、取得、変更、削除などが含まれています。複数のテーブルを作成する特定の理由がない限り、あなたのインデックスを適切に作成してください。おそらく、あなたの質問のテーブルデザインを詳しく説明することができます。 – gmiley