4

私は正規化のジレンマに直面しています。

OpenID は失敗と宣言されたので、Web サイトに組み込みたいと考えています。ついでに FB Connect も投入します。

これは明らかに、アカウントとログインの間に 1 対多の関係があることを意味します。それは簡単です。ただし、すべてのタイプのログインが同じではないことも意味します。

つまり、機能は似ているが形式が異なる 3 つの情報セットを格納する方法を決定する必要があります。つまり、私は煩わしい選択をしなければならず、「最善の」解決策があるかどうかはわかりません。これが私があなたのところに来る理由です

当面の選択肢は 3 つあります。

オプション 1: 各タイプの行を含むログイン テーブル

- ID
- Account ID
- Username
- Password
- Facebook ID
- OpenID URL
- OpenID ID

オプション 2: 一般的な行を含むログイン テーブル

- ID
- Account ID
- Login Type
- Generic Field 1
- Generic Field 2

オプション 3: 各ログイン タイプのログイン テーブル

Password Logins
- ID
- Account ID
- Username
- Password

FB Connect Logins
- ID
- Account ID
- Facebook ID

Open ID Logins
- ID
- Account ID
- OpenID URL
- OpenID ID

一般的なログイン テーブル (つまり、オプション 1) に各ログイン タイプのアドホックな行があると、汚い感じになり、非正規化されたように感じます。

一般的なログイン テーブル (つまりオプション 2) に一般的な行を含めると、汚く、非常に難読化されているように感じられます。

ログインの種類ごとに個別のテーブルを用意すること (つまり、オプション 3) は、クリーン/正規化されたように感じますが、非効率的で難読化される可能性があります。

他の人はこれをどのように達成しますか？他のオプションはありますか？現実に最も否定的な影響を与えるものは何ですか?

追加のログイン タイプ (たとえば、Twitter / 次の大物 / なんでも) が登場したら組み込みたいと考えていることを覚えておいてください。

4

1 に答える 1

4

オプション 3 が最適です。

1) セキュリティ
クライアントのセキュリティ データをすべて失うには、複数のテーブルが盗まれなければなりません。リスクと責任を制限することを考えてください。

1a) また...
どの facebook ログインがどの openID ログインに関連付けられているかを知る必要はありますか? おそらく、しかしいずれにせよ、データ泥棒のためにそのようにすべてをまとめれば、データ泥棒にとっては確かに便利です (オプション 1)。

2) テーブルの機能 -- トリガー、計算フィールド、またはプロバイダーごとに独自の方法で使用される可能性が高い (?) ものなど。

3)奇妙な / アドホックな目的のために 1 つのテーブルにすべてを含める必要がある場合でも、ビューを使用してこれを実現できます。

4) 設計の最適化。
おそらく、データはかなり似ていますが、それでも...データ型は動機にはならないかもしれませんが、パーティション化/インデックス作成/などは関連するでしょう。

5) 固有の要件。次の大物に何
が必要になるかは誰にもわかりません。既存の構造を再定義する必要のないスケーラビリティを考えてください (非常に多く)。

これについては他にも関連する考えがあると思います...しかし、それは私の頭の中から外れています。

于 2011-05-18T22:28:55.337 に答える