1

私は友人のためにWebサイトを設計していますが、データベーステーブルの1つに関して何が最善の方法かわかりません。あなたにアイデアを与えるために、これは大まかに私が持っているものです

Table: member_profile
`UserID`
`PlanID`
`Company`
`FirstName`
`LastName`
`DOB`
`Phone`
`AddressID`
`website`
`AllowNonUserComments`
`AllowNonUserBlogComments`
`RequireCaptchaForNonUserComments`
`DisplayMyLocation`

最後の4つ AllowNonUserComments AllowNonUserBlogComments RequireCaptchaForNonUserComments DisplayMyLocation

(そしておそらく将来追加されるそのようなブールフィールド)は、ユーザーの好みに基づいて特定のWebサイトの機能を制御します。

基本的に、これらのフィールドをに移動する必要があるかどうかはわかりません

新しいテーブル:member_profile_settings

`UserID`
`AllowNonUserComments`
`AllowNonUserBlogComments`
`RequireCaptchaForNonUserComments`
`DisplayMyLocation`

または、すべてのメンバーが独自の設定を行うため、それをmember_profileテーブルの一部のままにしておく必要がある場合。

目標は、長期的には約100000人、短期的には10kから20kです。私の主な関心事はデータベースのパフォーマンスです。

そして、私が質問#2)にいる間、住所テーブルとiのようなAddressIDを持つ代わりに、住所通り、都市、州、郵便番号、電話など のメンバーの連絡先情報をmember_profileテーブルに移動することは理にかなっていますか?現在持っています。

ありがとうございました

4

3 に答える 3

1

1)と2)の答えとして、「いいえ」と「はい、しかし」と言います。#1の場合、設定ごとに列を作成すると、クエリの管理がはるかに簡単になります。私が使った中で最高のシステムはそのようにして作られました。プリファレンスを「user、preference、value」トリプルを含む別のテーブルに移動すると、設定を確認するためだけに複数のテーブルを結合する複雑なクエリが発生します。

#2の場合:アドレスを別のテーブルに配置する理由はありません。単一の「AddressID」列は、とにかくメンバーごとに1つのアドレスしかないことを意味し、繰り返しになりますが、クエリが複雑になるだけです。それを逆にして、ユーザーIDを埋め込むアドレステーブルがある場合、それは理にかなっているかもしれません。人々はしばしば複数の電話番号を持っているので、そのように電話番号を行うことはさらに理にかなっています。

于 2011-03-17T03:52:02.603 に答える
1

データベース内の各メンバーが、リストした属性ごとに正確に1つの値を持っている場合、データベースはすでに正規化されているため、非常に便利な形式になっています。したがって、#1に答えると、これらのフィールドを別のテーブルに移動しても何も改善されず、クエリがより困難になります。

#2に関しては、メンバーが複数の住所や電話番号を持っている可能性を検討したい場合は、それらを異なるテーブルに配置して、多対1の関係を可能にする必要があります。これは、多数のユーザーが同じアドレスを共有することを期待している場合にも意味があります。このように、複数のユーザーの同じアドレス情報をすべて保存する必要があるため、情報を複製する必要はありませんaddresses。アドレスごとに1回、関連情報を持つテーブルを参照するだけです。

ただし、メンバーごとに複数のアドレスが必要な場合も、アドレスごとに複数のメンバーが必要な場合も、アドレス情報を別のテーブルに配置することは、不必要な複雑さです。どちらのソリューションがより便利かは、特定のアプリケーションのニーズによって異なります。

于 2011-03-17T04:08:24.670 に答える
0

このテーブルには各メンバーの値が1つしかないため、すでに正規化されています。ただし、クエリの効率を考慮すると、非正規化を検討する必要がある場合があります。

IDフィールドを除いて、他のグループはプロファイルグループと設定グループの2つのグループに分けることができます。Webサイトで通常、これら2つのデータグループを別々に使用する場合は、使用方法の異なるニューステーブルを用意することを検討する必要があります。

たとえば、プロファイルフィールドがプロファイルページにのみ表示され、設定フィールドがサイト全体で機能する場合、プロファイルフィールドを常に検索する必要はありません。

于 2013-08-14T03:49:21.573 に答える