一部のテーブルのデータベースにセカンダリ主キーを作成する
一部のテーブルに、uuidまたはランダムな長いキーとなる「second_primary_key」を追加します。一部のテーブルでは整数をWebアプリケーションに公開したくないので、これが必要です。つまり、 "/ invoices"ページに、請求書のリストと "/ invoices /：id"へのリンクがあります。ここで、：idは整数です。ユーザーがシステム内の請求書の数を知りたくないので、「/ invoices/123」ではなく、「second_primary_key」を使用して、URLが「/ invoices/N_8Zk241vNa」になるようにします。
実際のIDを非表示にする他のテーブルにも同じことが言えます。
これはよくあることなのでしょうか。これを実装する最良の方法は何ですか？
そして、このテクニックは結局何と呼ばれるので、私はそれを検索しますか？
UUID列を追加することもできますが、実際には必要ありません（すべきではありません）。これはプレゼンテーション層の問題です。通貨の値を1999年と同様に1,999ドルとして保存することは夢にも思わないでしょう。
アプリケーションのオンザフライで値を不明瞭にする何らかの方法が必要なだけです。これは、アプリケーション自体で行うことも、データベースビューとして行うこともできます。
ここでは1つの値についてのみ説明しているため、AESなどの双方向暗号化を検討することをお勧めします。軽量であればあるほど良いでしょう。
ハッシュは別の可能性もあります。ハッシュは1つの方法であるため、請求書番号を取り戻すかどうかによって異なります。
「代替主キー」を持つことは、リレーショナルデータベースモデリングでよく知られている概念であり、「代替キー」または「副キー」と呼ばれることもあります。 「潜在的な主キー」のセットは「候補キー」と呼ばれます。 https://beginnersbook.com/2015/04/alternate-key-in-dbms/ を参照してください
これをどのように実装するかは、特にレコードの総数を非表示にする場合は、完全にあなた次第です。 「最善の方法」はありません。IDで大文字と小文字を区別するかどうか、または印刷された請求書で読み取り可能にする場合は、許可された文字セットや有効な文字セット、最大長などの要件を確認する必要があります。エラーなしで電話でそれらをはじくことができる必要があります。
ほとんどの請求書には請求書番号があり、ほとんどの会計ルールでは順次である必要があります。そうでない場合、会計士が年の結果を承認しないか、IRS（またはお住まいの国では同様のもの）がタブで完全な監査を実行する場合があります。
ユーザーは、請求書番号から、提供した顧客の数、または請求書の番号付け戦略を変更するまでの期間を推定できます。
データベースに保存されている請求書の数は、請求書の総計を表すものではありません。商工会議所に年報を要求することを含め、それを見つける他の方法があります。
ただし、請求書はユーザーのログイン画面でロックするので、誰もが請求できるわけではありません。次に、ユーザーログイン時に、ajax方法論を使用して未払いの請求書をリクエストできます。これにより、データが保護され、URLがajaxによって非表示になります（通常、ajaxリクエストの作成方法の詳細を確認する必要はありません）。 、およびデータの表示方法と提供方法を制御します。
hashids を使用できる場合があります。このシナリオを正確に解決するように設計されています。
データベースIDを短いハッシュにエンコードし（YouTube動画のURLと同様）、テーブルにセカンダリキーを追加する必要はありません。
別の一意のキーを作成できますが、作成しないでください。与えられた理由ではありません。テーブルサイズを非表示にする簡単な方法があります。
保存N_8Zk241vNaは、テーブルの行ごとに12バイト、インデックスではさらに多くのコストがかかります。それはあなたが必要とするものにはかなり無駄です。
整数idを暗号化すると、実行時にスペースがなく、ほとんど何もかかりません。方法は、プログラミング言語やデータベースによって異なります。
AESを使用すると、128ビット整数、つまりbase64で22文字を取得することに注意してください。 DESまたは3DESのような64のブロックサイズの暗号は、あなたが望むように11文字を与えます。
テーブルごとに異なるキーを使用します。
必要なのがテーブルサイズを非表示にすることだけであれば、すべてのテーブルに共通のシーケンスを使用できます。多くのテーブルで頻繁に挿入が行われると、ボトルネックになる可能性があることに注意してください。 HibernateやHi-Loアルゴリズムなどを使用すると、この問題は解消されます。
特定のユースケースのもう1つのアプローチは、データベースとアプリケーションを変更する代わりに、請求書へのカスタムルートを作成するだけで、/ invoices /：f（id）がf(id)になるようにすることです。 IDのいくつかの機能。
カスタムルートは、リクエストを正しいアクションのサーバー側にマッピングする責任があります。
「Alternate Key」（AK）とも呼ばれる、完全に受け入れ可能な方法です。基本的に、AKは別の一意のインデックスまたは一意の制約です。
AKに基づいて外部キー制約を作成することもできます。
考えられるユースケースは、あなたが説明したもののようなものです：増え続けるID番号にクラスター化されたPKがありますが、単に推測できるため、この番号を表示または検索基準として使用したくありません。そのため、AKとしてランダムな一意の識別子または参照番号があり、それがユーザーに提示するIDです。
キー/インデックスにはいくつかの種類があります。主キーは特別な一意のインデックスであり、答えが言うように、確かに別の一意のキーを作成できます。そして、非常に正当な理由がない限り、データベースの内部を公開しないことが最善であることに同意します。
質問は請求書と番号のコンテキストにあるので、会計業界が請求書番号がどのように見えると期待するかを調査することは価値があります： http://smallbusiness.chron.com/assign-invoice-numbers-52422。 html
主キーである内部IDと、アプリケーション/顧客に表示される請求書番号を含む別の一意のフィールドがあると、面倒に見えるかもしれません。しかし、たとえば1年後、顧客が新しい請求書番号付け方式を採用したいと思ったとしても、それほど不快ではありません。その場合、ワックスのボール全体の番号を付け直すために、他のテーブルの内部IDとその関係を変更する必要はありません。内部IDをそのままにして、非内部の請求書番号に番号を付け直します。
理想的には、変更される可能性のあるキー/外部キーにテーブルを結び付けないように努力し、内部テーブルとリレーションをアプリレイヤーに対して透過的に保ちます。
頑張れ。
これは、ブログ記事などによくある「スラグ」フィールドと同じです。主キーとは別にデータベースレコードを参照するユニークな方法で、URLでの使用に適しています。誰もがそれらに反対する議論を聞いたことがありません。
2つの異なる主キーを作成する私見は不可能です。もちろん、そのuuidをDBに入れて、現在の主キーの「エイリアス」として使用できます。一意の制約を使用してその列の上にインデックスを置くことができますが、主キーは（本質的に）単一のテーブル内の単一のキーです。複合主キーが存在する可能性がありますが、それはあなたが探しているものではありません。
だから私はそこに置くことをお勧めしますが、インデックスのみでそれを持っています。 PKおよびその他の一意の列でデータをクエリするための処理コンポーネントを作成できます。 「/ invoices/...」のリクエストを処理する場合は、パラメータを確認してください。整数の場合はIDを検索し、それ以外の場合はuuidを検索します。または、ID検索で何も見つからなかった場合の代替として、uuid検索を使用できます。
そして、いくつかの「ランダムな」uuidsの生成について：「IDを取得し、定数を追加し、16進数に変換する」のようにしないでください。 IDの奇妙さは、uuidの一意性を提供します。16進数は、通常の人間の場合、読み取りが困難です+定数を追加すると、00000001のようなuuidを避けることができます。
両方のキーが同じ事実を指している場合、それらは決して衝突しません。元のキーのカスタムハッシュコードを作成するスカラー関数を使用して、元のキーから他のキーを派生しないのはなぜですか。
または、両方のバージョンのキーを格納する別のマッピングテーブルを作成することもできます。このテーブルは、2次キーを検索するための辞書として機能します。
私の理解によると、キーは暗黙的なインデックスであり、インデックスを追加するほど、挿入は遅くなります。