0

私は、グループ、イベント、友達リストを作成することを考えているソーシャルネットワーキングWebサイトに取り組んでいます。私は以下のように彼の友人のためにユーザーのプライバシーを望んでいます：

1.ユーザーは、自分の個人情報を表示できる友達と表示できない友達を選択できます。2.ユーザーは、自分のイベントやグループを表示できるユーザーと表示できないユーザーを管理できます。

以下に貼り付けているものと同じテーブル構造を設計しました：

  1. User_location_id
  2. ユーザーID
  3. Allow_friends（コンマで区切られたID）
  4. Deny_friends（コンマで区切られたID）
  5. Allow_groups（コンマで区切られたID）
  6. Deny_groups（コンマで区切られたID）
  7. Allow_search（州、市の章）
  8. 友達（一部に表示、一部から非表示）（0の場合、allow_friends else Deny_friendsから友達IDを取得しています）
  9. グループ（一部のユーザーに表示、一部のユーザーから非表示）（0の場合、allow_groupsから友達IDを取得しています。それ以外の場合はDeny_groups）
  10. Privacy_for_type
  11. Privacy_for_name

効率的で、データベースのヒットを最小限に抑え、データベースを集中的に使用しない構造が他にあるかどうか。

4

2 に答える 2

1

データベース テーブルを設計する場合は、正規化について読むことをお勧めします: http://en.wikipedia.org/wiki/Database_normalization

コンマで区切られた ID を保存すると、それらのレコードの更新が難しくなり、重複を防ぐことができなくなります。許可列と拒否列を別々の関連テーブルに分割することをお勧めします。必要なクエリは 1 つだけであるため、これによりデータベースが集中的に使用されることはありません。結合を含むクエリが必要になる可能性があることを意味します。

于 2013-02-09T09:58:34.470 に答える
0

2つ（または3つ）のテーブルを使用し、ユーザーとグループ、およびアクセス許可を分離することをお勧めします。

ユーザー/グループテーブルには、ユーザー/グループに固有の（そして分離された）情報を含めることができ（したがって、ユーザーの＃1と2）、「タイプ」または「カテゴリ」のフィールドを追加して、それがユーザーまたはグループ。ユーザーとグループ用に保存している情報が十分に異なる場合は、それぞれに個別のテーブルを設定できます。

権限テーブルには、リストの＃の4〜9を含む、任意の権限を含めることができます（10/11のコンテキストはよくわかりません）。このテーブルは、グループメンバーシップの管理にも使用できます。以下は、権限テーブルを構成する方法の例です。

  • permid：任意の一意の主キーauto_increm列
  • Asset_cat：アセットが属するカテゴリ（またはテーブル名）
  • Asset_id：権限で説明されているユーザーID、グループIDなど
  • uid：許可を求めているユーザー
  • パーミッション：uidによってasset_idに対して求められているパーミッション
  • 値：その権限の値


いくつかのエントリ例：

//Same as listing 1338 in user 1337's Allow_Friends Field
1002, 'user', '1337', '1338', 'Allow_Friends', 'True'

//Lists 1337 as a member in group # 43
1003, 'group', '43', '1337', 'Member', 'True'

これらは、始めるのに役立ついくつかの例にすぎません。これが役に立ったかどうか、または何かを明確にする必要があるかどうかを教えてください:)

于 2013-02-09T10:04:14.803 に答える