2

分離されたテーブルを使用する Postgresql のようなリレーショナル データベースの場合はより効率的であることはわかっていますが、最も実行されるクエリは を使用して複数のテーブルから行をフェッチするため、パフォーマンスの問題が懸念されますUNION ALL。

この問題を処理するには、オプションを選択する必要があります。最初のものは次のとおりです。

table1 -> column1, column2
table2 -> column1, column2
table3 -> column1, column2, column3

このソリューションではUNION ALL、本番環境でマージされた 3 つの異なるクエリを使用する必要があり、このクエリはシステムにログインしているユーザー (システムで最も実行されたクエリ) によって実行されます。

もう1つは次のとおりです。

table -> column1, column2, typeColumn, extraColumnForTable3

このソリューションではtypeColumn、行のタイプを区別するために追加の列を作成する必要があります。また、型の列を作成する必要がextraColumnForTable3あり、型table3の場合は NULL になりtable2ますtable1。このソリューションでは、最も実行されるクエリには 1 つのSELECTステートメントのみが含まれます。

本番では数百万行になるので、パフォーマンスが心配です。NULL値はデータベース内の余分なスペースを占有する可能性がありますが、無視できると思います. NULL 値を排除する部分インデックスを使用するので、特定の型を取得する他のクエリには影響しないと思います。どちらが生産効率が高いと思いますか?

4

1 に答える 1

1

一般に、 を多用すると、UNIONデータベース設計が不適切であることがわかります。と が理にかなっている場合もありますがUNION、UNION ALL再帰的な共通テーブル式以外では比較的まれです。

PostgreSQL は、単一のテーブルのパフォーマンスを管理可能な状態に保つためのかなりの数のオプションを提供します。ご指摘のとおり、部分インデックスはこの問題を管理するための非常に優れた方法です。

UNIONこのようなステートメントが一般的になるようにテーブルを分割することの主な問題は、主キーと外部キーの管理が非常に問題になることです。一般に、ほとんどの場合、最適化について心配してから最適化されたソリューションを管理しやすくしようとするよりも、最初にデータ構造が明確で管理しやすいことを確認してから最適化について心配する方がはるかに優れています。

于 2013-04-26T14:13:40.797 に答える