4

データベースには、自動インクリメント機能を備えた列IDを常に含めています。それをソーシャルネットワーキングサイトのユーザーIDとして使いたくない理由はありますか。IDは一般に公開されており、URLなどで使用されます。別の関数を追加してメンバー用に個別の一意のIDを作成するよりも簡単だと考えました。コードで使用する前に、他の誰かがこれに問題を見つけたかどうかを確認したかっただけです。

4

4 に答える 4

2

また、これは基本的な問題に対する標準的なアプローチだと思います。

また、他のユーザーIDを持つ他のサイトへのリンクも簡単になります。ユーザーID（あなたが説明したとおり）、他のサイトID（foreign sitesテーブルから）、そこで使用するユーザーIDを持つテーブルを用意するだけです。

私がこれまでに観察した唯一の欠点は、一部のスクリプト キディが n、n+1、n+2、... を使用して脆弱なパスワードを持つユーザー ID をテストしたことです。これはランダム ID によって難しくなりますが、個人的には、これは別の場所で処理する必要があると思います。

于 2012-11-26T23:58:18.340 に答える
2

ID 自体が情報を漏らし、第三者がサイトに登録した日付を概算できるようになります。したがって、アリスがボブと友達で、彼女が昨年登録し、彼が 3 日後にフォローし、彼女の ID が 100 で彼の ID が 150 であることを知っている場合、アリスは、友達ではないキャロルがその時点であなたのサイトに登録したことを知ることができます。キャロルが主張したように「最近」ではなく、あなたのソーシャル メディア サイトで彼女がアリスと「友達」ではない理由について言い訳を見つけようとしています!

これは問題ですか？決めるのはあなた自身ですが、個人的には少し専門的/偏執的になりたいと思います (この 2 つは、私たちの職業にとって何を意味するにせよ、一緒に使われることがよくあります)。 / プライバシーに関する懸念。または、少なくとも、そうするようにアドバイスしてください:-)

美徳の道を取ることにした場合は、他の ID も情報を漏らすことを考慮する必要があるかもしれません (たとえば、アリスは、自分のプロファイル ID がボブの ID よりも小さいことに気付いた場合、彼女が主張したよりも早くキャロルを知ることになります)。そのため、たとえば GUID 列を追加して、それを URL に含めても安全なセカンダリ ID として使用できるように見えるかもしれませんが、自動インクリメント ID から GUID を使用するように切り替えるだけの方がよい場合があります。(GUID の詳細はこちら: http://en.wikipedia.org/wiki/Globally_unique_identifier )

それが役立つことを願っています:-)

于 2012-11-27T00:17:30.447 に答える
1

それは完全に有効なアプローチだと思います。ユーザーの一意のIDをサポートする場合（たとえば、ユーザーが一意のuser_idを必要とする場合）、後でいつでもユーザーテーブルの個別の列として追加できます。

于 2012-11-26T23:51:43.043 に答える
1

いいえ、user_idとして使用したくない理由はありません。

他の列をidに設定すると、次のような問題が発生します。

  • ユーザーIDを生成する方法
  • テーブルに重複するIDがあるかどうかを確認する方法

また、主キー（AUTO_INCREMENTでもある）によるSELECTフィルタリングを実行している場合、特定のユーザーのテーブルでのルックアップははるかに高速になります。

于 2012-11-26T23:52:01.083 に答える