問題タブ [surrogate-key]

MySQL に、SK (代理キー) として POST_ID を持つ単純な posts テーブルがあります。元の投稿 ID への返信は同じテーブルの PARENT_POST_ID 列に保存されますが、次のロジックを実行したいと考えています。

挿入する前に（私は思う...）

INSERT でPARENT_POST_IDが定義されていない場合は、行の値を (auto-int シーケンスから) 新しく生成された POST_ID にデフォルト設定します。

PARENT_POST_IDがINSERT で定義されている場合は、渡されたものに設定します。

例

ここでの答え: https://stackoverflow.com/a/11061766/1266457は、それが何をしているのかわかりませんが、私がする必要があるように見えます。

ありがとう。

私は倉庫業に慣れていないので、代理キーの実装に問題があります。たとえば、特定の地域の各顧客の代理キーを持つ顧客ディメンション テーブルがあります。このように: (SK_ NK_ Customer_ Region) ( 1 , 10022 , 22 , 100) (2 , 10162 , 62 , 101) ( 3 , 10322 , 22 , 103) , . . . これらは顧客ディメンション テーブルに保存されます。私の質問は、トランザクションが発生したときにファクト テーブルに外部キーとして登録される代理キーを計算するにはどうすればよいかということです。

2 つの load ステートメントAとB. それぞれに代理キーがあります。両方のキーが格納されたデータと一致する場合、代理キー列を一致させたいと考えています。

次のコードを試しました。

上記のコマンドは、すべてのデータを出力します。

リレーショナル データベースで人工/代理キーを使用している人をよく見かけます。考えてみると、これは結合クエリを単純化する一方で、新しいタプルの挿入を複雑にしているように思えます。次の例を見てください。

R1(a, b, c) R2(c, d, e) c は、R1(c) によって参照される、R2 の代理主キーです。R1 と R2 にデータを挿入する場合、最初に、挿入する R2 タプルが R2 に既に存在するかどうかを確認する必要があります。存在する場合は、対応する人工キーを取得して、タプルで参照できるようにする必要があります。 R1用。

自然キーの使用: R1(a,b,d,e) R2(d,e) 属性 d および e は、R1(d,e) によって参照される R2 の自然主キー セットです。R1 と R2 に新しいタプルを挿入したい場合は、単純に挿入できます。これは、R1 タプルの場合、参照する外部キー (つまり、R2 プライマリ キー セットの値) がわかっているためです。

私の仮定は正しいですか、それとも何か不足していますか?

データベースに属性 A1、A2、A3...An およびA1、A2 と A3 が一緒に複合キーを形成できる場合、複合キーの代わりに代理キーを使用する方がよいでしょうか?

サロゲート キーを使用すると、レコードの挿入実行速度が向上します(これは、複合キーよりもサロゲートをサポートします) 。代理キーに対する複合キー)。

このような条件を考えると、どちらがパフォーマンスの面で優れていますか? 代理キーまたは複合キー?

MySQL/MariaDB データベースにインポートしたい 5 つのテキスト フィールドがあります。しかし、次の 2 つの問題があります。

(1) ファイルが非常に大きい: 0.5 GB から 10 GB
(2) 関連するキーはすべて 40 文字

ポイント(1) ありのままを受け入れなければならず、変えられない。ポイント2は私の懸念です。インターネットにはたくさんの提案があります。たとえば、varchar に enum を使用したり、数値サロゲートを使用したりします。テーブルに代理キーを追加しても問題ありません。ただし、同じ代理キーを他のテーブルに追加する必要があります。そして、これが私が立ち往生したポイントです。

ファイル/テーブルに関する特定の情報は次のとおりです。

• 表の請求書には、3 つの列と 20 Mio 行があります。

  • 個別の値を持つinvoice_id (主キー) = 行数
  • 4,000 個の異なる値を持つ praxis_id
  • 4 Mio の個別の値を持つ患者 ID すべての列は CHAR(40) であり、固定長は 40 です。

• テーブルdiagnosticには、3 つの列と 25 Mio 行があります。

  • Invoice_id CHAR(40) 1.4 Mio の個別の ID
  • 診断タイプ
  • 診断コード

• テーブルの患者には、5 つの Mio 行を含む 5 つの列があります。

  • Patient_id CHAR(40) 一意ではありません (4 Mio の個別の pat_id)
  • praxis_id CHAR(40)
  • 生年月日、性別など

たとえば、請求書を診断と患者に結合したいとします。キーにインデックスを付けることは理にかなっています。1 つの方法は、invoice.invoice_id を主キーとして定義し、invoice テーブルの他のすべてのキーに対してインデックスを追加することです。テーブルの診断 (INDEX を含む invoice_id) と患者 (主キーとしてのpatient_id) と同じです。
問題は、以下を使用して、invoice.invoice_id を主キーとして定義するのに長い時間がかかったことです。

1時間後、プロセスを強制終了しました。テーブルinvoiceのinvoice_idのデータ型の種類から、パフォーマンスの問題が1つ生じると思います。1 つのアイデアとして、テキスト ファイルをロードするときに自動インクリメント サロゲート キー Invoice_id_surr を追加することが考えられます。しかし、外部キーとして代理キーinvoice_id_surrを持たないテーブルdiagnosticのinvoice_idに参加する必要があるため、テーブルdiagnosticに参加したい場合は問題が残ります。diagnostic.invoice_id にインデックスを追加することもできますが、その場合、invoice テーブルに代理キーを持つ利点が失われます。

この問題に対処する方法に興味があります。結合できる既存のテーブルがいくつかありますが、キーは CHAR(40) であり、インデックスはありません。

手伝ってくれてありがとう。

更新 1: テーブル仕様
- キーには 40 文字 [0-9][AZ]があります
- これらはもう変更されないテーブルです (挿入なし)

リモートデータを格納するためのテーブルを設計する必要があります。Web サービス経由で取得しているデータには、2 つの列の組み合わせである候補キーがありますが、代理キーの使用を推奨する代わりに、休止状態での複合キーの使用を思いとどまらせる投稿をほとんど見ませんでした。複合キーを使用してテーブルを設計すると、データを直接更新できますが、代理キーを使用する場合は、更新する前に最初に主キーをフェッチする必要があります。私の質問は、複合キーまたは代理キーのどちらを使用する必要があるかです。

銀行データベースを作成していますが、ここで次の問題があります。

CustomerA がアカウント番号 4444 を持っていて、これを介して顧客に関連するすべての詳細にアクセスするとします。別の主キーがありますが、通常はこのアカウント番号でクエリを実行します。

ここで、何らかの理由で CustomerA の口座番号が 4444 から 5555 に変更され、新しい CustomerB には口座番号 4444 が与えられます。

データベースでこのような変更を処理したいのですが、どのようなアプローチを適用すればよいですか?

私が開発したアプローチは次のとおりです。アカウント番号にタイムスタンプを割り当てると、現在のアカウント番号に関連する顧客名を効率的に検索するのに役立ちます。

しかし、次のクエリを設計することはできません。

• 4444 を使用して CustomerB にアクセスすると、B に関連する現在の詳細のみが表示され、その 4444 は CustomerA を指していません。
• CustomerA が 5555 によってアクセスされると、4444 によってデータベースに保存されているものを含むすべての詳細が表示されます

ハイブ テーブルの代理キーを作成したいのですが、データがテーブルに配置されるたびに複製できるものです。他のテーブルは代理キーを介してこのテーブルを参照し、テーブルを再生成して行を追加することができ、その関連付けは壊れません。私の考えは、基本的にテーブル内のすべての列の複合キーを持つことです。

すべての列を連結し、その文字列の md5 ハッシュを取得して、その行の簡単なルックアップとして使用することは合理的ですか?

このソリューションで見られる問題は次のとおりです。

• 行内のデータが変更された場合でも、関連付けは解除されます
• ハッシュ値が一意であるという実際の保証はありません (ただし、私の数値では、衝突はほとんどありません)

データに関する注意事項:

• データは日ごとに分割され、1 日あたり約 10 万行あります。
• 2 つの行がまったく同じデータを持つ場合があり、最終的に同じキーになっても問題ありません。