2010-11-23 15 views
0

Iは異なる)データベースの設計:複数のユーザーの種類の異なるフィールド

a)は、別のユーザーの種類(例えば大工、機械工、...、配管工)
Bが含まれているMySQLの5.0.77を使用してアプリケーションを構築しています各ユーザータイプの入力フィールド、たとえばユーザーは大工を選択し、私の思考はのラインに沿って、各専門職のためのフィールドが異なる

であること職業に関係する分野が提示されています

Table: users
user_id
user_name

Table: carpentry
user_id
woodwork_rating
metalwork_rating

Table: plumbing
user_id
central_heating_rating
bathroom_rating

など...

これは非常に良いようには見えませんが、潜在的には異なるフィールドを持つ複数のテーブルに存在する多くのテーブルとユーザーになる可能性があるからです。

メタデータテーブル(Wordpressで見られるような)のアイデアはかなり好きで、各ユーザーフィールドのエントリが保存されます。

Table: user_info
user_id
field
value

だから我々は例

1のために持っています|ウッドワーク_レーティング|中間体
1 |メタルワーク_レーティング|アドバンスド
2 |ウッドウォーク_レーティング|

私の質問は、どのように各ユーザーが利用可能なフィールドの1つのカテゴリを塗りつぶす複数のユーザーに対して複数のフィールドを持つデータベースを構成しますか?

おかげ

+0

あなたが求めていることは、次のことが起こらないようにすることです。 1 |ウッドワーク_レーティング|中間体; 1 |ウッドワーク_レーティング|進んだ; 2 |ウッドウォーク_レーティング|進んだ; ユーザー1にwoodwork_ratingを使用する方法がわからないという問題がありました。 – Dave

答えて

1

表のユーザー:

UserID: Autoinc PRIMARY KEY 
(More user data columns here) 
UserType: CHAR(5) 

表のUserTypes

UserType: CHAR(5) PRIMARY KEY 
Description: VARCHAR(50) 

表UserRatingList

UserRatingCode: CHAR(5) PRIMARY KEY 
UserType: CHAR(5) REFERENCES UserTypes 
Description: VARCHAR(50) 

表のUserRatings

UserID: INTEGER PRIMARY KEY/REFERENCES Users 
UserRatingCode: CHAR(5) PRIMARY KEY/REFERENCES UserRatingList 
Rating: INTEGER (or whatever you prefer) 

テーブルUserRatingListは、各ユーザータイプに適用できる評価のパターンを確立します。 UserRatingsには実際の評価が含まれます。私はCHAR(5)を使用して、Descriptionフィールドに参加することなく読み込み可能なコードを提供しますが、必要に応じてINTEGERに変更できます。

この構造は、各ユーザが複数のタイプを持つことができるようにすることもできます。 UserIDとUserTypeを持つ追加UserTypeLinksテーブルを作成するだけです。

+0

これは理にかなっていますが、私の質問は誤解を招いていました。 UserRatingListをUserMetaListに変更したり、UserRatingsをUserMetaに変更すると、これが機能するとは思うが、ユーザーフィールドのすべてが評価されるわけではありません。 – dianovich

+0

はい、実際には理論よりも常に複雑です。より複雑なデータベースをどのように構造化するかは、追加のメタデータがどのように見えているかによって異なります(また、あなたとは多少異なるデザインを選ぶかもしれません)。私の答え(もしあれば)から取り除く重要なことは、新しい格付けごとにテーブルに列を追加するデザインを避けることです。代わりに、作成する新しい評価タイプ(またはメタタイプ)ごとに1つ以上のテールに_row_を追加するデザインを使用します。 –

0

すべてのフィールドが同じデータ型の「評価」になりますか?もしそうなら、私はLarry Lustigのソリューションが好きです。

異なるデータ型の無関係なフィールドがある可能性がありますか?日付、文字列、小数点、整数そうであれば、ユーザーと結合する1対1の関連テーブルを持つ最初のソリューションはOKです。実行時に新しいフィールドを動的に追加する必要がないかぎりです。

1

私は 'mikeの最後の答えに頼りたいと思います。 私はこの正確な問題に直面しています。私は、次の種類のネットワークを作成してい

Enterprise {name, mail, adress, etc ...} 
Employee {name, mail, branch, jobdescription, etc ...} 
Individual {name, mail, surname, age, town, etc...} 

方法について:

表のユーザー

userID (autoincr) 
userType 
mailadress 
password 
...  

表Usertypes

typeID 
typeName 
typeDescr 

表企業

entID (autoincr) 
userID 
field 1 
field 2 
... 

表の従業員

empID (autoincr) 
userID 
... 

表個人

indID (autoincr) 
userID 
... 

はあなたにこのメーク意味していますか?

関連する問題