0

私は SQL の経験がほとんどないフロントエンド開発者です。私が勤務している組織のデータ クエリ システムの開発を検討しています。

現在、データの多くは一連のスプレッドシートにあります。同じテンプレート (国の列を含む) から派生した 100 近くのワークシート (テーブル) がありますが、ワークシートの計画シナリオ (「効率的」など) と経済部門 (「農業」など) に基づいて値が異なります。各ワークシートには約 8000 行あります。

これらのワークシートごとに個別のデータベース テーブルを作成する必要がありますか?テーブルを介しても同じCREATEステートメントが含まれますか? この場合、次の行に沿ってインデックスを作成すると思います。

CREATE INDEX sector_scenario_lower_country ON sector_scenario(lower(country));

このインデックスを 100 回 (sector_scenario テーブルごとに 1 回) 作成する必要があります。探しているデータ行を見つけたいときは、アプリを使用して正しいテーブルを識別し (これはそれほど面倒でも時間もかからないはずです)、クエリを作成する必要があります。

SELECT col4, col5, col6 FROM sector_scenario WHERE lower(country) = "brazil";

または、シナリオとセクターの列をデータベース テーブルに追加してから、すべてのワークシートをその 1 つのテーブルにコピーする必要がありますか?

この場合、次のインデックスを 1 回だけ作成します。

 CREATE INDEX main_table_idx ON  main_table(scenario, sector, lower(country));

次に、次のクエリをかなり定期的に作成します。

SELECT col4, col5, col6 FROM main_table WHERE scenario = "efficient" AND sector = "agriculture" AND lower(country) = "brazil";

明らかに、2 番目のオプションを使用すると、セットアップの手間が大幅に軽減されます。しかし、同等のパフォーマンスを期待できますか?

4

2 に答える 2

3

2 番目の解決策は正しい解決策です。つまり、すべての行を 1 つのテーブルに入れ、その 1 つのテーブルのインデックスを作成します。

非常にまれな状況でのみ、データを異なるテーブルに分割します。私が考えることができる唯一のものは、自分のデータを他のユーザーのデータとは別に保存するというユーザーの要件です。

問題の 1 つは、最初のシナリオのインデックスの全体的なサイズが 2 番目のシナリオのサイズに匹敵するかどうかです。最初のシナリオのインデックスが (最後に) 平均して空のページの半分を占めることを考えると、インデックスはより大きくなる可能性があると思います。シナリオを格納する追加のオーバーヘッドは、値ごとに 1 回だけ発生します。実際にサイズをテストしなくても、データ サイズは単一テーブルのアプローチに適していると思います。

各テーブルで大量のデータを操作すると、テーブルまたはインデックスで使用可能なメモリがオーバーフローする可能性があります。これが問題になる場合は、テーブルを分割することをお勧めします。ただし、適切なアプローチは、パーティショニングを使用して各セグメントを個別のテーブルに分割することです。多数のテーブルを個別に管理するのではありません。

于 2013-06-12T19:22:25.560 に答える