一部のテーブルのデータベースにセカンダリ主キーを作成する

いくつかのテーブルに、「second_primary_key」を追加します。これは、uuidまたはランダムな長いキーになります。一部のテーブルでは整数をWebアプリケーションに公開したくないため、必要です。つまり、「/ invoices」ページには、請求書のリストと「/ invoices /：id」へのリンクがあります。ここで、：idは整数です。ユーザーにシステム内の請求書の数を知らせたくないので、「/ invoices / 123」の代わりに「second_primary_key」を使用して、URLが「/ invoices / N_8Zk241vNa」になるようにします。

同じことが、実際のIDを非表示にする他のテーブルにも当てはまります。

これは一般的な慣習ですか？これを実装する最良の方法は何ですか？

結局のところ、この手法は何と呼ばれていますか？

UUID列を追加することもできますが、実際には必要ありません（する必要はありません）。これは、プレゼンテーション層の問題です。たとえば、1999年だけでなく1,999ドルの通貨値を格納することも夢ではありません。

アプリケーションの実行中に値を不明瞭にする何らかの方法が必要です。これは、アプリケーション自体で行うことも、データベースビューとして行うこともできます。

単一の値についてのみ説明しているため、AESなどの2方向の暗号化を検討することをお勧めします-軽量であるほど良いでしょう。

ハッシュは別の可能性もあります-ハッシュは一方向であるため、請求書番号を取り戻すかどうかに依存します。

「代替主キー」を持つことは、リレーショナルデータベースモデリングでよく知られている概念であり、「代替キー」または「副キー」とも呼ばれます。「潜在的な主キー」のセットは「候補キー」と呼ばれます。https://beginnersbook.com/2015/04/alternate-key-in-dbms/を参照してください

これをどのように実装するかは、特にレコードの総数を非表示にする場合は完全にユーザー次第です。「最善の方法」はありません。IDで大文字と小文字を区別するかどうか、印刷された請求書で読み取り可能にする場合、許可されているまたは有用な文字セット、最大長などの要件を確認してくださいエラーなしで電話でそれらを再スペルできる必要があります。

ほとんどの請求書には請求書番号があります。ほとんどの会計規則では、会計結果が年の結果にサインオフしなかったり、IRS（または同様の国）がタブで完全な監査を行いたい場合があります。

ユーザーは、請求書番号から、サービスを提供した顧客の数、または請求書の番号付​​け戦略を変更するまでの期間を推測できます。

データベースに保存されている請求書の数は、請求書の総計の測定値ではありません。商工会議所に年度報告書を要求するなど、それを見つける他の方法があります。

ただし、ユーザーのログイン画面の背後で請求書をロックするため、誰もがリクエストできるわけではありません。その後、ユーザーのログイン時に、ajax方法論を使用して未処理の請求書などを要求できます。これにより、データが保護され、URLがajaxで隠されます（通常、ajaxリクエストの作成方法の詳細を確認することはできません） 、データの表示方法と提供方法を​​制御します。

このためにハッシュIDを使用できる場合がありますが、これはまさにこのシナリオを解決するように設計されています。

データベースIDを短いハッシュにエンコードし（YouTubeビデオのURLと同様）、テーブルにセカンダリキーを追加する必要はありません。

別の一意のキーを作成できますが、作成しないでください。指定された理由ではありません。テーブルサイズを非表示にするより簡単な方法があります。

格納にN_8Zk241vNaは、テーブルの行ごとに12バイト、さらにインデックスにコストがかかります。それはあなたが必要とするものにとってはかなり無駄です。

整数を暗号化するidと、実行時にスペースが不要になり、ほとんどゼロになります。その方法は、プログラミング言語やデータベースによって異なります。

AESを使用すると128ビット整数が得られることに注意してください。これは、おそらくbase64の22文字を意味します。DESや3DESのようなブロックサイズが64の暗号は、希望どおりに11文字を提供します。

テーブルごとに異なるキーを使用します。

必要なのがテーブルのサイズを隠すことだけであれば、すべてのテーブルに共通のシーケンスを使用できます。テーブルの多くに頻繁に挿入がある場合、ボトルネックになる可能性があることに注意してください。HibernateとHi-Loアルゴリズムのようなものを使用すると、この問題はなくなります。

2つの異なるプライマリキーを作成することはできません。もちろん、そのuuidをDBに入れて、現在の主キーの「エイリアス」として使用することができます。一意制約を使用してその列の上にインデックスを配置できますが、主キーは（本質的に）単一のテーブル内の単一のキーです。複合主キーを使用できますが、それはあなたが探しているものではありません。

そこで、それをそこに置くことをお勧めしますが、それはインデックスでのみ持つことです。PKおよび他の一意の列によってデータをクエリするための処理コンポーネントを作成できます。「/ invoices / ...」のリクエストを処理するときは、パラメータを確認するだけです。整数の場合はIDを検索し、そうでない場合はuuidを検索します。または、ID検索で何も見つからなかった場合の代替としてuuid検索を使用できます。

そして、いくつかの「ランダムな」UUIDの生成について：「IDを取得し、定数を追加し、16進数に変換する」などの理由はありません。IDの一意性はuuidの一意性を提供し、16進数は通常の人間にとって読みにくい+定数を追加すると、0000001のようなuuidが回避されます。

両方のキーが同じ事実を指しており、それらが衝突しない場合。元のキーのカスタムハッシュコードを作成するスカラー関数を使用して、元のキーから他のキーを派生しないのはなぜですか。

または、別のマッピングテーブルを作成して、両方のバージョンのキーを保存することもできます。このテーブルは、セカンダリキーを検索するための辞書として機能します。

私の理解では、キーは暗黙的なインデックスであり、インデックスを追加するほど挿入が遅くなります。

特定のユースケースのもう1つのアプローチは、データベースとアプリケーションを変更する代わりに、請求書へのカスタムルートを作成して、/ invoices /：f（id）を作成することです。f（id）はidの関数です。

カスタムルートは、リクエストを正しいアクションサーバー側にマッピングする役割を果たします。

これは、「代替キー」（AK）とも呼ばれる、完全に受け入れられる方法です。基本的に、AKは別の一意のインデックスまたは一意の制約です。

AKに基づいて外部キー制約を作成することもできます。

可能なユースケースは、説明したようなものです。増え続けるID番号にクラスター化されたPKがありますが、この番号を表示したり、検索条件として使用したりしたくないのです。それに加えて、ランダムな一意の識別子またはAKとしての参照番号があり、それがユーザーに提示するIDです

キー/インデックスにはいくつかの種類があります。主キーは特別な一意のインデックスであり、答えが言うように、確かに別の一意のキーを作成できます。そして、非常に正当な理由がない限り、データベース内部を公開しないことが最善であることに同意します。

質問は請求書と番号のコンテキストにあるので、会計業界が請求書番号がどのように見えるかを調査する価値があるかもしれません：http : //smallbusiness.chron.com/assign-invoice-numbers-52422.html

主キーである内部IDと、アプリケーション/顧客に見える請求書番号を持つ別の一意のフィールドを持つのは面倒に思えるかもしれません。しかし、たとえば1年先に、顧客が新しい請求書番号付けスキームを採用することを望むとき、それはそれほど汚くないわけではありません。その場合、他のテーブルの内部IDとその関係を乱すことなく、ワックスのボール全体の番号を付け直します。内部IDをそのままにして、非内部請求書番号の番号を付け直します。

理想的には、変更される可能性のあるキー/外部キーでテーブルを結び付けないように努力し、内部テーブルとリレーションをアプリレイヤーに対して透過的にします。

頑張れ。

これは、ブログ記事などによくある「スラッグ」フィールドとは異なりません。URLでの使用に適した主キーとは別にデータベースレコードを参照するユニークな方法です。私は誰もがそれらに反論するのを聞いたことがない。