2

最近、私が作成しているアプリケーションで使用される新しい Postgres テーブルのセットを DB チームに提案する必要がありました。私のテーブルには次のようにリストされたフィールドがあったため、設計に失敗しました。

my_table
    my_table_id : PRIMARY KEY, AUTO INCREMENT INT
    some_other_table_id, FOREIGN KEY INT
    some_text : CHARACTER VARYING(100)
    some_flag : BOOLEAN

some_text彼らは、 が の前に表示されるため、テーブルは最適ではないだろうと述べましたsome_flag。また、CHARACTER VARYINGフィールドの検索はBOOLEANs よりも遅いため、テーブル スキャンを実行するときは、列が最大精度から最小精度に順序付けられたテーブル構造を使用する方が高速です。だから、このように：

my_table
    my_table_id : PRIMARY KEY, AUTO INCREMENT INT
    some_other_table_id, FOREIGN KEY INT
    some_flag : BOOLEAN
    some_text : CHARACTER VARYING(100)

これらの DBA は Sybase のバックグラウンドを持っており、ごく最近 Postgres DBA に切り替えました。これはおそらく、Postgres には適用されない Sybase の最適化であると考えています (Postgres は、列の順序をどうにか気にしないほど賢いと思います)。

いずれにせよ、肯定または否定する Postgres のドキュメントが見つかりません。これが有効な主張なのか偽物なのか (または条件付きで有効なのか!) について検討するために、戦いに慣れた Postgres DBA を探してください。

4

3 に答える 3

3

メモリが機能する場合 (行内の列データを見つける際の CPU オーバーヘッドのため)、バージョン 9 と 10 (または 8 と 9) の間で動作に大きな変化があった、同様の問題に関する Oracle での私の経験から言えば、私はしません。実際の実験がかなり簡単で決定的である場合、このような問題については文書化された動作に依存する必要があると信じています。

そのため、このためのテスト ケースを作成することをお勧めします。まったく同じデータで列の順序が異なる 2 つのテーブルを作成し、さまざまなテストを繰り返し実行します。テスト全体を、開発システムまたはテスト システムで実行でき、答えを教えてくれる単一のスクリプトとして実装するようにしてください。DBA が正しく、「ねえ、これについてのあなたの考えを確認しました。どうもありがとうございました」と言うことができます。さもなければ、測定可能な重要な違いが見つからないかもしれません。後者の場合、テスト全体を DBA に渡し、問題を再現できない理由を説明できます。彼らにテストを実行させてください。

いずれにせよ、誰かが何かを学ぶことになり、将来 (または過去) のバージョンに適用できるテスト ケースが得られます。

最後に、見つけたものをここに投稿してください ;)

于 2012-10-26T12:56:38.180 に答える
1

DBAがおそらく参照しているのは、特定のタプル（/行）のブール値を「取得」するためのアクセス戦略です。

彼らが提案した設計では、システムはバイト9を調べることでその値に「到達」できます。

提案された設計では、システムは、ブール値が見つかるバイトオフセットを知る前に、まずすべての可変長列（ブール列の前にある）のLENGTHフィールドを検査する必要があります。それは常に「彼らの」方法よりも遅くなるでしょう。

彼らの考慮事項は、物理的設計の1つです（そしてそれは正しいものです）。ダミールの答えも正しいですが、論理設計の観点からの答えです。

DBAによる発言が本当に「「悪い」設計の批判」として意図されている場合、論理設計があなたの仕事であり（そして列の順序はそのレベルでは重要ではありません）、物理設計は彼らの仕事。そして、彼らがあなたが物理的な設計（彼らの仕事）もすることを期待しているなら、上司が彼らを雇用し続ける理由はもはやありません。

于 2012-10-26T22:17:14.517 に答える
1

データベース設計の観点からは、設計と DBA の提案に違いはありません。アプリケーションは気にする必要はありません。リレーショナル データベースには (論理的に) 列の順序などはありません。実際、列の順序が (論理的に) 重要な場合、1NF に失敗しました。

したがって、すべてのテーブル作成スクリプトを DBA に渡して、物理レベルで最適と思われる方法で DBA に実装 (列の並べ替え) を任せるだけです。アプリケーションを続行するだけです。

データベース設計は、列の順序で失敗することはありません。これは単に設計プロセスの一部ではありません。

大規模なデータバンクの将来のユーザーは、マシン内でデータがどのように編成されているかを知る必要がないように保護する必要があります...

... 扱われる問題は、データの独立性の問題です。アプリケーション プログラムと端末のアクティビティが、データの種類と変更の増加から独立していることです ...

EF コッド ~ 1979

物理レベルへの変更 ... アプリケーションへの変更を要求してはなりません ...

ルール 8: 物理データの独立性( EF Codd ~ 1985 )

33年後...

于 2012-10-26T13:21:52.867 に答える