問題タブ [surrogate-key]

現在、独自の Varnish サーバーを管理するか、Fastly のようなホスティング サービスを使用するかを決定しています。ここで最も重要な決定要因の 1 つは、効率的なタグベースのキャッシュの無効化です。これは、Varnish を API の前に配置する予定であり、多くの関連ページを無効にするパージ リクエストを頻繁に発行する必要があるためです。

Fastly はSurrogate Keysを提供しており、Varnishは Hashtwo、Hashninja、XKey など、さまざまな名前で呼ばれる個別のモジュールを提供しているようです。これらの機能は同じように見えます。それらは実際には同じですか、それとも 2 つの機能についてのブログ投稿からは明らかではない重要な技術的または効率的な違いがありますか?

データ ウェアハウス ディメンションで代理キーを使用する正当な理由があることは理解しています。それでも、それらをファクト テーブルの外部キーにリンクする方法がわかりません。ファクト テーブルには、ETL 中に抽出された自然キーのみがあります。代理キーは、元のデータベース テーブルには存在しません。これに関する提案はありますか？ありがとうございました

ライセンスの使用状況を記録するテーブルがあります。各ライセンスの使用状況は、ユーザーとホスト マシンに関連付ける必要があります。テーブル定義は次のようになります。

このテーブルを正規化して、反復的なユーザー/ホストの値がこのような新しいテーブルに移動されるようにします。

user_hostテーブルの場合、自然または代理のどの種類の主キーを選択する必要がありますか? 以下の支配要因が考えられます。

1. 主キーが自然な場合、つまりユーザー名とホスト名の合成である場合、親テーブルper_user_factは、ユーザー名とホスト名を見つけるために追加の結合を必要としません。
2. 主キーが自然な場合、ユーザー名とホスト名の値が両方のテーブルで重複するため、ストレージが無駄になります。
3. 主キーがサロゲートの場合、親テーブルがユーザー名とホスト名の値を取得するには、追加の結合が必要になります。
4. 主キーがサロゲートの場合、user_host テーブルのインデックス作成は高速になります。

お知らせ下さい。

Pig でカスタム代理キーを作成する方法はありますか?

例：以下のようなデータがあります

このデータについては、以下のように代理キーを作成する必要があり、結果は以下のようになります。

ランダムな一意のキーを作成する代わりに?

前もって感謝します！！。

私は DW モデリングについて読んでいて、なぜ代理キーが使用されるのか疑問に思い始めました。

ビジネス キーが整数でない場合があることを理解しています。しかし、私が理解していないのは、一意の識別子を管理するための追加の列を追加して、DW または RDBMS のちょっとした制限を解決する理由は何ですか?

この種の機能が DW/RDBMS ユーザーに対して透過的であり、エントリがシステムから内部識別子を自動的に取得する方が適切ではないでしょうか? たとえば、行全体またはそのサブセット (ある種のテキスト形式で表すことができるフィールド) の SHA-1 ダイジェストを作成します。

製造会社のさまざまな施設の住所を含む住所テーブルがあるとします。外部キーにより、住所が属する会社を知ることができますが、各施設を区別するために代理 ID が必要です。この ID は、外部キーの値に基づいて自動的に増加します。注：キーには単純な整数値が必要です。

例えば：

私のテーブルには次の列があり、ORGANIZATION_ID は外部キーです。FACILITY_ID は、外部キーに依存する 2 番目の代理キーです。

組織IDに応じて施設IDを1から自動で増やしたい。すなわち

新しい組織のデータを挿入するとき、施設は 1 から開始する必要があります

次に同じ組織のデータを挿入すると、それに応じて施設 ID が増加するはずです。

DB2でこれを実現する方法はありますか? 現在、DB2 V 10.5.6 を使用しています