0

一部のユーザーを格納するデータベースがあります。各ユーザーには、アカウント設定、プライバシー設定、および設定する他の多くのプロパティがあります。それらの物件の数は増え始め、最終的には30物件程度になる可能性があります。

これまで、私はそれを「UserInfo」テーブルに保持し、UserとUserInfoを1対多として関連付けていました（すべての変更のログを保持します）。単一の「UserInfo」テーブルに配置するのは適切ではなく、少なくともデータベースモデルでは、乱雑に見えます。解決策は何ですか？

プライバシー設定、アカウント設定、その他の設定の「グループ」を別々のテーブルに分離し、UserInfoと設定テーブルの各グループの間に1-1の関係を持たせることは、1つの解決策ですが、データを取得するときに遅すぎる（またははるかに遅い）でしょうか？すべてのデータが同時に1つのページに表示されるわけではないと思います。では、各テーブルに1対多の関係を持たせることも解決策になるのではないでしょうか（各グループのログを個別に保持する）。

4

1 に答える 1

1

プロパティが 30 個しかない場合は、30 個の列を作成することをお勧めします。これは、最新のデータベースで処理するには多すぎません。

しかし、今日 30 のプロパティを持っている場合、時間の経過とともに新しいプロパティを発明し続け、列の数が増え続けると思います。毎日列を追加するようにテーブルを再構築すると、多くの行が得られるため、時間がかかる場合があります。

別の解決策については、「スキーマレス」な方法で多くの動的属性を保存するための気の利いた解決策について、このブログをチェックしてください: How FriendFeed Uses MySQL .

基本的に、すべてのプロパティを何らかの形式にまとめて、1 つの TEXT 列に格納します。形式は半構造化されています。つまり、アプリケーションは必要に応じてプロパティを分離できますが、いつでも追加したり、行ごとに異なるプロパティを持つこともできます。XML、YAML、または JSON はサンプル形式、またはアプリケーション コード言語でサポートされているオブジェクトのシリアル化形式です。

CREATE TABLE Users (
  user_id SERIAL PRIMARY KEY, 
  user_proerties TEXT
);

これにより、特定のプロパティで特定の値を検索することが難しくなります。したがって、TEXT 列に加えて、検索可能にする各プロパティの補助テーブルを作成します。このテーブルには、特定のプロパティの値と、その特定の値が見つかるメイン テーブルへの外部キーの 2 つの列があります。これで、列にインデックスを付けることができるので、検索が迅速になります。

CREATE TABLE UserBirthdate (
  user_id BIGINT UNSIGNED PRIMARY KEY,
  birthdate DATE NOT NULL,
  FOREIGN KEY (user_id) REFERENCES Users(user_id),
  KEY (birthdate)
);

SELECT u.* FROM Users AS u INNER JOIN UserBirthdate b USING (user_id)
WHERE b.birthdate = '2001-01-01';

これは、Users の行を挿入または更新するときに、データとの同期を維持するために、各補助テーブルにも挿入または更新する必要があることを意味します。補助テーブルを追加すると、これは複雑な雑用に発展する可能性があります。

于 2011-06-20T23:57:16.577 に答える