0

現在、Usersテーブルがあり、特定のユーザーに関する他のユーザー関連情報を追加したいと考えています。この情報を受け入れるフォームには、言語やOSなどのフィールドがあり、それぞれにチェックボックス付きのオプションのリストがあります。

例えば：

既知の言語：チェックボックスPHP、Java、Ruby

OSの知識：Windows、Linux、Mac

現在、私のデータベーステーブルは次のようになっています。

USER
----------------------------------------
|  ID  |  Name      |  
-----------------------
|   1  |    John    |    
-----------------------
|   2  |    Alice    |    
-----------------------

LANGUAGES
----------------------------------------
|  ID  | User_ID(FK)     | lang-name  | 
----------------------------------------
|   1  |    1            |   PHP      |
----------------------------------------
|   1  |    2            |   Java     |
----------------------------------------

OS
----------------------------------------
|  ID  | User_ID(FK)     | os-name  | 
----------------------------------------
|   1  |    1            | Windows  |
----------------------------------------
|   1  |    2            |  Windows |
----------------------------------------

これは良いスキーマのように見えますか？それぞれが独自のテーブルを持つ必要があるそのようなユーザー関連のフィールドはもっとたくさんあり、何千人ものユーザーがPHPを知っているので、テーブル内に多くの冗長性があるようです。したがって、言語としてPHPを使用すると何千もの行があります。異なるユーザーごとに。

スキーマを整理するためのより良い方法はありますか？

4

1 に答える 1

1

おそらく、独自のテーブルを使用してデータベース内のエンティティを作成Languageし、最初のクラスのエンティティを作成してから、 との多対多の関係に結合テーブルを使用できます。このようなもの：OSUser

User
---------
ID
Name
etc...

Language
---------
ID
Name

OS
---------
ID
Name

UserLanguage
---------
UserID
LanguageID

UserOS
---------
UserID
OSID

そうすれば、実際のエンティティ ( User、Language、OS) は、それらにとって意味のあるデータのみで自己完結型になり、相互の関係の懸念によって汚染または複製されることはありません。また、リレーションシップは、それ自体はエンティティではなく、エンティティ間の単なる多対多リンクである、独自の単純な数値のみのテーブルに含まれています。

データは複製されません (サンプル データではLanguage、OS少なくとも今のところ、それぞれに 3 つのレコードしかありません)。また、ORM や他のフレームワークを使用する必要がある場合でも、より使いやすくなります。

編集：コメントに基づいて、次のようなことを試すことができます：

User
---------
ID
Name
etc...

Lookup
---------
ID
LookupTypeID
Value

LookupType
---------
ID
Value

UserLookup
---------
UserID
LookupID

これにより、多くの柔軟性が得られます。サンプル データでは、 のレコードになりLanguageます。すべての言語と OS は、それぞれの にリンクする値になります。したがって、データの繰り返しはまだありません。そして、このテーブルは唯一の多対多リンク テーブルです。OSLookupTypeLookupLookupTypeUserLookup

ただし、このデザインには注意してください。柔軟です、間違いなく。しかし、このテーブル構造を実際のドメイン モデルとして使用すると、「ルックアップ」などの用語がビジネス用語になる状況に遭遇しますが、おそらくそうではありません。「言語」と「OS」は実際のモデルです。ビューまたはストアド プロシージャを使用して、この構造をコードから抽象化することをお勧めします。そのため、コードはテーブルから直接ではなく、言語ビューまたはプロシージャから言語を取得しLookupます。

于 2012-05-22T22:35:34.637 に答える