現在、ユーザーログインのあるウェブサイトがあります。
userIdを持つユーザーテーブルがあります。
ここで、ユーザーに、メインプロファイルから完全に分離された重複プロファイルを持たせたいと考えています。これは秘密のプロファイルである必要があります。
これで、データベースに2つのレコードを追加できますが、IDはシーケンシャルになり（サインアップのヒット率が高くなるまで）、ユーザーはuserIdが1つ上のIDに関連付けられるようにトレーニングできます。
これは理想的なソリューションではないことは承知していますが、大規模なソフトウェアプロジェクトへの変更は遅れているため、コードの変更をできるだけ少なくして、できるだけ実用的なものにするよう努めています。
オプション：
- 自動インクリメントIDをオフにして、独自のkeyGenerationテーブルを作成します。1つのテーブルを0から開始し、シークレットテーブルを1000000000から開始します。次に、ユーザーテーブルの自動インクリメントIDをオフにして、これらのキーを使用できます。
問題は、キーを実行していると、1,1000000000,2,1000000001,3,1000000002が大規模なインデックス作成の問題を引き起こすということです。インデックスの再構築を常に強制する必要がありますか？
- 2番目のプロファイルIDに対してのみ、10000000000から開始して、個別のテーブルにキーを設定します。次に、すべてのコードを変更してIDが999999999を超えているかどうかを確認し、サーバー側でロジックを反転して、ルックアップが正しく機能するようにします。
フロントエンドから、ユーザーIDがサイトに渡されるすべての場所でそのチェックを行うことを意味します。
あまり多くのことをしないので（明らかに、主にログインしているユーザーのuserIdを安全に取得しますが、それほど悪くはないかもしれません。
とにかく、誰かがこれについて何か考えを持っているかどうか疑問に思っていますか？
///////編集
これをさらにコンテキストに入れるために、stackoverflowまたはfacebookで想像してみてください。制御できるプロファイルが2つあり、それらの間にリンクはありません。Facebookの複数のユーザーがすべてページアカウントとして機能できるのと同じように、そのアカウントから実際のユーザープロファイルに戻るリンクはありません。
基本的に、参照整合性を壊したり、コードを書き直したりしないために、これらのアカウントのフロントエンドにID（int）を戻したいと思います。その後、システム全体が、これまでと同じように動き続けます。
GUIDはかっこいいかもしれません！ただし、パフォーマンスのオーバーヘッドが発生します（実際には気にしないでください;）が、フロントエンドに渡されるGUIDを処理するための多くのコードを記述することも意味します（フロントエンド変数が正しいことに依存しているわけではありません）しかし、それが上記の高整数ソリューションを提案する理由です。まだASP.NETメンバーシップがバックグラウンドに潜んでいるので、それは良いことだと思いましたが、A）その日を削除する（または単純なメンバーシップに移行する）予定ですb）パフォーマンスのためにユーザーテーブルで順次GUID生成を使用します（必要になる前に、最適化についてもう一度お話しして申し訳ありません）