従来のインターネットからモバイルインターネットの時代に移行し、Android、iOS、アプレットなどを開発する際のクライアントの登録方法は非常に豊富かつ多様になっています。したがって、新しいサードパーティのログイン タイプの開発コストを最小限に抑えるために、バックグラウンドのユーザー テーブルの設計も、さまざまな登録方法の「継続的拡張」と「相互バインディング」に適応する必要があります。
ユーザー テーブルといえば、おそらくすべてのアプリケーション/Web サイト プロジェクト (コード ファーマー) が最初に考慮するものです。ユーザー テーブル構造の設計は、バックグラウンド アーキテクチャ全体の基礎となります。基礎が安定していないと、後で需要をフォローしてみたら対応できないことが分かり、遡ってユーザーテーブルの修正を繰り返したり、大小さまざまな変更が必要な箇所が多々あります。それよりも、ユーザー テーブルの設計の最初にスケーラビリティを考慮し、次のステップで余分なコストがかからない状況を目指すことをお勧めします。
1. 以前のデザイン
id
username
passwordユーザー名とパスワードで単純なニーズを解決し、ID を外部キーとして他のテーブルに残します。もちろん、その時点でもパスワードは平文で保存されている可能性があるため、md5 について知っておくとよいでしょう。その後、ビジネスニーズの拡大に伴い、ユーザーがブロックされているかどうかを判断するためのユーザーステータスステータス、登録時刻と登録IPアドレス、将来の参照用に最終ログイン時刻とIPアドレスを追加する（ログイン記録を導出する）必要があります。ユーザーが別の場所にいるかどうかを判断するためのテーブル（ログインなど、ここでは示されていません）、ユーザーの役割/権限の役割（ユーザーの役割と権限の関係が導出されます。これについては別の記事で説明します）、ビジネスには個人的な個人も必要です本名、住所などの情報も追加され、非常に完全なユーザー関係テーブルが形成されます。
id
username
password
realname
address
…
status
role
register_time
register_ip
login_time
login_ipここで問題が発生します。Web 2.0 の時代に、Weibo はサードパーティの Web サイトへのログインをオープンし、Weibo アカウントで Web サイトにログインできるようになりました。上司は、これを要求する必要があると言いました。Weibo ユーザーのログイン フォームを追加しましょう。もちろん、独自のユーザー テーブルに関連付けられている必要があります。この Weibo ユーザー情報テーブルは次のとおりです。
id 自增ID
user_id 关联本站用户ID
uid 微博唯一ID
access_token
access_expireこれはまだ終わっておらず、QQ はユーザー ログインを再開し、多くのサードパーティ ログインが一度に接続されるため、「Weibo ユーザー情報フォーム」に基づいてタイプと判断を追加し続けることしかできません。新しいテーブルを作成し、それは間違いなく狂うでしょう。
時代は変わり、モバイルインターネットの時代になったのに、なぜログインに携帯電話番号をサポートしなければならないのでしょうか？したがって、現在、すべての標準構成は、ユーザー名/電子メール/携帯電話番号のログインに加えて、Weibo や WeChat などの一連のサードパーティのログインとなっています。テーブル構造は次のとおりです。
ユーザーテーブル:
id
username
email
phone
…
ユーザーのサードパーティログインフォーム:
id
user_id
app_type
app_user_id
access_token
…
ユーザーが入力ボックスにユーザー名/メールアドレス/携帯電話番号とパスワードを入力すると、バックグラウンドでメールアドレス、携帯電話番号、ユーザー名のいずれであるかを判断し、条件に従って特定のユーザーであるかどうかを確認します。 。このテーブル構造は、将来の一定期間のビジネス ニーズに対応できます。ある日、ID 番号ログインなどの新しいログイン方法が現れたらどうしますか? ユーザーテーブルにフィールドを追加し続けますか? もっと良い選択肢があると思います。
2. 改良版
ユーザー名 + パスワードまたは電話番号 + パスワードに関係なく、ユーザー情報 + パスワード検証の形式です。サードパーティ ログインについて理解しましょう。実際には、ユーザー情報 + パスワードの形式でもあり、ユーザー情報は、サードパーティのシステム (サードパーティのログインでは、そのシステム内で確実に一意の識別子が与えられます)、パスワードは access_token です。これは、期限付きで定期的に変更される単なるパスワードです。そこで、ユーザー基本情報テーブルとユーザー認可情報テーブルの形に抽象化しました。
ユーザー基本情報テーブル users
id
nickname
avatar
ユーザー認可情報テーブル user_auths
id
user_id
identity_type 登录类型（手机号 邮箱 用户名）或第三方应用名称（微信 微博等）
identifier 标识（手机号 邮箱 用户名或第三方应用的唯一标识）
credential 密码凭证（站内的保存密码，站外的不保存或保存token）
このシステムの最大の特徴は、ユーザー情報テーブルにはパスワードやログイン情報（ユーザー名、携帯電話番号、メールアドレスなど）は一切保存せず、ニックネームやアバターなどの基本情報のみを保持することです。認可に関連するもの（基本的なフロントエンド表示には関係しないもの）はすべてユーザー情報認可テーブルに配置され、ユーザー情報テーブルとユーザー認可テーブルは 1 対多の関係になります。抽象的すぎるのでコードを見せてください。
users
|id|nickname|avatar|
|1|慕容雪村|http://…/avatar.jpg|
|2|魔力鸟|http://…/avatar2.jpg|
|3|科比|http://…/avatar3.jpg|
user_auths
|id|user_id|identity_type|identifier|credential|
|1|1|email|[email protected]|password_hash(密码)|
|2|1|phone|13888888888|password_hash(密码)|
|3|1|weibo|微博UID|微博access_token|
|4|2|username|moliniao|password_hash(密码)|
|5|3|weixin|微信UserName|微信token|
具体的な処理について説明すると、ユーザーがメールアドレス/ユーザー名/携帯電話番号とパスワードを入力してログインを要求した場合でも、最初に種別が判断されます 携帯電話番号でログインするユーザーを例にします, SELECT * FROM user_auths WHERE type='phone' と identifier='携帯電話番号' を使用してエントリを見つけ、存在する場合はそれを取り出し、password_hash (パスワード) がエントリの資格情報と一致するかどうかを判断し、一致する場合は一致します。 、検証に合格し、user_id を通じてユーザー情報を取得します。
サードパーティのログインを使用する場合、SELECT * FROM user_auths WHERE type='weixin' および identifier='WeChat UserName' を判断するだけで済みます。レコードがあれば、ログインは成功し、新しいトークンは次の目的で使用されます。元のトークンを更新します。WeChat サーバーとの通信がハイジャックされていないと仮定すると、資格情報の問題を判断する必要はありません。
3. メリットとデメリットの比較
このテーブル構造の設計により、多くの複雑な問題が瞬時に解決されます。
1. サイト内のログイン タイプは無限に拡張でき、コードの変更はわずかです。本当に ID カード ログインをサポートしたい場合は、テーブル構造を変更せずに、いくつかの変更を加えるだけで済みます。
2. サードパーティのログイン タイプはファクトリ モードでバッチで拡張でき、サードパーティのログイン タイプを追加する開発コストが最小限に抑えられます。
3. 元の条件では、アプリケーションは携帯電話番号が検証済みかどうか、および電子メール アドレスが検証済みかどうかを検証する必要があり、phone_verified や email_verified などの対応する追加フィールドが必要ですが、今後は、統合された検証済みフィールドが必要になります。 user_auths テーブルに追加されると、各ログイン方法が利用可能になる状況が確認できているかを視覚的に確認できます。サードパーティのログイン データの正確性の信頼に基づいて、サードパーティのログインはデフォルトで検証されます。ユーザーがログイン携帯電話番号またはログイン電子メールを変更した場合、各ステップの完了を明確に追跡することもできます。
4. 必要に応じて、同じタイプのログイン方法をいくつでもバインドできます。つまり、ユーザーは複数の WeChat アカウントをバインドし、複数のメールボックスを持ち、複数の携帯電話番号を持つことができます。もちろん、ログイン方法を 1 つのレコードのみに制限することもできます。
5. ユーザーの使用習慣をより完全に追跡できるように、対応する時刻と IP アドレスを user_auths に追加します (たとえば、2 年以上ログインに Weibo を使用していない、WeChat を 300 日間バインドしているなど)。
6. サードパーティのアカウントでログインした場合でも、フロントエンドでは「当サイトへのアカウント登録が不要」の効果を実現できます。これまで、多くの Web サイトがサードパーティ アカウントのログインをサポートしていましたが、ユーザーの囲い込みなどの理由により、Weibo に初めてログインするときに、Web サイトのメール アドレス、パスワードなどの別の情報の入力が求められます。 、など、Weibo ログインの最大値を失います。技術的に言えば、元の構造では、Weibo ユーザー テーブルにエントリを作成することに加えて、対応するエントリをユーザー テーブルにも作成する必要があり、通常、ユーザー テーブルの電子メール アドレスまたはユーザー名とパスワードを空白のままにすることはできません。ユーザーエクスペリエンスは良好で、メールボックスはWeibo [email protected]を自動的に生成し、パスワードはランダムに生成されます。悪い経験としては、もっと早く知っていれば、Weibo にログインしないほうが良かったとしか言えません。さて、Weibo が提供するニックネームとアバター アドレスを使用してこのユーザーを生成し、そのユーザーの Weibo ログイン レコードを関連付けることができる限り、私たちのユーザー テーブル構造にはそのような問題はまったくありません。そして、このテーブル構造は、ユーザーがすべてのログイン方法をキャンセルできることを意味するため、このアカウントは完全にログインできないゾンビになっています (解決策は、コードに制限を追加し、少なくとも 1 つの user_auths レコードを保持することです)。ユーザーの電子メール アドレスを取得する必要がある場合、ログインするたびに、そのユーザーの電子メールとしてのidentify_type の記録がないことがわかると、ポップアップ ウィンドウがポップアップしてユーザーを強制終了し、ユーザーに入力させます。メールアドレスをすぐに送信してください。そうでない場合は、何もしないでください。
7. 論理的思考能力の向上。物事の本質を抽象化することはコードファーマーに必要な職業的資質ですが、ユーザーテーブル構造の調査と研究を通じてあらゆる面でスキルが向上し、それ以来コードを書くのがずっとスムーズになりました...
8. 電子メール アドレスと携帯電話番号がユーザー情報の一部であると言う場合、フロントエンド表示としてユーザー テーブルに反映する必要がありますか? 問題ありません。users テーブルが展開されても、users テーブルには電子メールと電話が残りますが、これらは「表示目的」にのみ使用され、ニックネーム、アバター、性別などの属性と本質的な違いはありません。ユーザー情報テーブルとユーザー認証ログインを分割した後、ユーザー情報テーブルでは、いつでも任意のフィールドを追加したり、星座や誕生日を追加したりできます。問題ありません。フロントエンドに表示するときに、さらにいくつかの入力ボックスが必要です。入力時にコード行を削除することで、ユーザーのログインに関連する問題が最大限に分離されます。
メリットもあればデメリットもありますので、デメリットについてもお話します。
1. 当初のユーザー判断は 1 つの SQL リクエストから 2 つの SQL リクエストに変更されました。
2. ユーザーがメールアドレス、ユーザー名、携帯電話番号などの複数のログイン方法を同時に持っている場合、パスワードを変更する際にそれらも一緒に変更する必要があります。そうしないと、メールアドレス + 新しいパスワード、携帯電話番号 + 古いパスワードになります。アクセスするには、非常に奇妙な状態に違いありません。これを考慮すると、サイト上のログイン方法またはサードパーティのログイン方法を示す識別フィールドを user_auths テーブルに追加する必要があります。
3. コード量が増え、場合によっては論理的な判断が増え、難易度が上がりました。たとえば、ユーザーがログインしているかどうかに関係なく、ユーザーが登録しているかどうかに関係なく、同じリンクをクリックして Weibo に移動し、サードパーティの承認後に戻ります。OK、直接登録して彼と関連付けますログインしてください; 2. Weibo はこのサイトにすでに存在しており、現在のユーザーはログインしておらず、直接ログインは成功しています; 3. Weibo はこのサイトに登録されていませんが、現在のユーザーはログインして関連付けられています別の Weibo アカウント、対処方法は複数の Weibo アカウントのバインドが許可されているかどうかによって異なります; 4、Weibo はこのサイトに登録されていません、現在のユーザーはログインしています、バインドしてみてください; 5、Weiboはすでに登録されており、ユーザーはこのアカウントでログインしています。なぜ彼は何度も自分自身をバインドするのでしょうか - -. 6. Weibo はすでにこのサイトに存在しますが、現在のユーザーはログインしており、別の Weibo アカウントに関連付けられています。どうすればよいですか?する？ユーザーを切り替えるか、エラーを報告しますか? (フローチャートを描くと、この問題をよりよく説明できます) この問題は、使用されているデータ構造とは関係ありませんが、サードパーティのアカウントで登録およびログインするときに発生するさまざまな状況がここで整理されています。
その他の関連記事については、以下も参照してください。
1. データテーブルの設計:
アプリのログイン、登録、サードパーティのログイン データの設計とビジネス プロセス - 短い本
2.製品機能設計: