0

私は、どこかで読んだ別の概念に基づいて、頭の中でじっくり考えてきたこの考えを持っています。基本的に、フィールドが非常に少ない単一の「プライマリ」テーブルがあり、他のテーブルは外部キーを介してそのプライマリテーブルを継承します。これは以前に行われたことがあるので、ニュースはありません。私がやりたいのは、データベース内の実質的にすべてのテーブルがそのプライマリテーブルから継承するようにすることです。このように、すべてのオブジェクト、すべてのレコード、すべてのテーブルのすべてのエントリは、完全に一意の主キーを持つことができ（PKは実際にはプライマリテーブルに格納されているため）、テーブルではなくIDで簡単に参照できます。

もう1つの利点は、複数のテーブルにアクセスできる関係を簡単に作成できることです。例：トランザクションテーブルがあり、このテーブルは、トランザクションの対象（在庫、アカウント、連絡先、注文など）にFKを設定したいと考えています。トランザクションはプライマリテーブルへのFKを持つことができ、必要なデータはそれを介して参照されます。

私の頭に浮かぶ問題は、そのプライマリテーブルがボトルネックになるかどうかです。ある時点で文字通り何百万ものレコードが存在することになります。巨大なレコードセットは優れたテーブルデザインで処理できることを知っていますが、制限は何ですか？

誰かがこれに似た何かを試みましたか、そしてあなたの結果はどうでしたか？

4

3 に答える 3

2

このテーブルには大量の外部キー関係があることを考慮する必要があります。ルートテーブルから行を削除する場合、これらはパフォーマンスの問題を引き起こす可能性があります。（これにより、削除時に厄介な実行プランが発生する可能性があります）

したがって、行を削除する場合は、パフォーマンスに影響を与える可能性があります。私は最近、このようなセットアップで問題が発生し、それをクリーンアップするのは苦痛でした（120の他のテーブルを参照していました-地獄のように遅い場所で削除します）。

このパフォーマンスの問題を克服するには、制約を適用しない（悪い計画）か、パフォーマンスに制約を使用しない（悪い計画）か、1つのエンティティに属するすべてのデータを1行にグループ化して、通常の正規化の方法に固執することを検討してください（悪い計画）。いい計画）

于 2010-11-23T15:43:11.590 に答える
2
  1. はい、プライマリテーブルはほぼ確実にボトルネックになります。
  2. 実際の参照整合性をどのように実施しますか？
    たとえば、トランザクションのFKが、リンゴ、オレンジ、パイナップルではなく、実際に在庫、アカウント、連絡先、または注文にリンクされていることをどのように確認できますか？
于 2010-11-23T15:40:00.517 に答える
1

これは恐ろしいボトルネックになると思います。それだけでなく、実際のP​​K/FK関係を強化することははるかに困難になります。データ整合性の悪夢を生み出す可能性があります。どこで利益が得られるのか、まったくわかりません。

于 2010-11-23T15:40:03.450 に答える