問題タブ [natural-key]

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]があります
- これらはもう変更されないテーブルです (挿入なし)

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

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

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

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

お知らせ下さい。

モデル化の方法に関する情報はたくさんありますが、JPA (2) では、1 対 1 の関係 または自然キーを持つエンティティーについて、モデル化の方法に対する明確で単純な答えを見つけることができませんでした。両方が存在する状況、つまり、親テーブルが自然キーを持つ 1 対 1 の関係です。そのようなチュートリアルを見逃した可能性があることは明らかです。もしそうなら、私に1つを指摘することも答えかもしれません.

そして、JPA と私のような初心者の場合、最も基本的なモデルよりも少し多くのことが必要になった瞬間に、すぐに壁にぶつかることがよくあります。

したがって、次の DB モデルを検討してください。

対応する JPA アノテーション付きオブジェクト モデルは何でしょうか? （答えに影響を与えたくないので、試したことは割愛します...）

パフォーマンスに関する推奨事項も歓迎します (たとえば、「1 対多の方がパフォーマンスが向上する」など)。

ありがとう、

私は単純なものを持っています

自然なIDは一意のキーを作成し（良い！）、owner休止状態から不変になります。これも良いことですが、ブルー ムーンになると、管理者は所有者を変更する必要があります。そのため、変更可能にすることを余儀なくされているようです。これは本当に嫌いです。

単純な SQL を使用してそれを克服することもできますが、これは嘘をつくことを意味し、休止状態を騙して何か間違ったことをさせる可能性があるため、これも嫌いです。

「私が言うときを除いて不変」のようなことを述べるためのきれいな方法を探しています（可能性については悲観的ですが）。また、代替案の欠点は何ですか。