7

私は Web サイトのユーザー プロファイル システムに取り組んでおり、より良い (スケーラブルな) アプローチを検討しています。私は 2 つの解決策を思いついたので、私が見逃したかもしれない何かへの入力またはポインタを探しています。

次の create table ステートメントは、実行可能にすることを意図したものではなく、関連するテーブルのレイアウトのアイデアを提供するためのものです。

私の最初の考えは次のようなものでした：

CREATE TABLE user(
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,

    user_email VARCHAR(320),

    user_joined DATATIME,
    user_last_seen DATATIME,

    user_name_first VARCHAR,
    user_name_last VARCHAR,

    user_name_alias VARCHAR,

    user_location_country VARCHAR,
    user_location_region VARCHAR,
    user_location_city VARCHAR

    # ...
);

明らかに、これはまったくスケーラブルではなく、追加のプロパティを追加するのは面倒です。1 つの利点は、特定のプロパティ セットに一致するユーザーをすばやく検索できることです。私は少し調べてみましたが、これはかなり一般的なアプローチです (Wordpress など)。

私の2番目のアプローチ（私が現在遊んでいるアプローチ）ははるかにスケーラブルですが、パフォーマンスが少し心配です：

CREATE TABLE user(
    id INT UNSIGNED NOT NULL AUTO_INCREMENT,

    user_email VARCHAR(320)
);

CREATE TABLE user_profile(
    user_id INT UNSIGNED NOT NULL,

    visibility ENUM('PRIVATE', 'PUBLIC'),

    name VARCHAR,
    value VARCHAR
);

このアプローチを使用すると、すべての使用に一連のキーと値のペアが関連付けられているため、追加のプロパティを簡単に追加したり、ログイン時にユーザー プロファイルをロードしたりできます。ただし、最初のアプローチで持っていたすべての型情報が失われるため (たとえば、DATETIME は書式設定された文字列として格納されるようになりました)、一部の検索が煩わしくなります。これにより、ユーザーが公開したいプロパティをより細かく制御できます。

両方の方法の長所と短所のバランスを取るには、ハイブリッド アプローチの方がよいでしょうか? SO はどのような方法を使用しますか? 私が考えていない、または見逃していない、これに対する別のアプローチはありますか？

拡張:ハイブリッド アプローチでは、user テーブルのプロパティを user_profile テーブルに挿入して、他のユーザーへの可視性を制御することも有利でしょうか?それとも追加のオーバーヘッドと見なされる可能性がありますか?

4

4 に答える 4

4

ハイブリッドアプローチを使用します。ユーザー名、電子メール、lastlogindate などのいくつかの基本的なプロパティをユーザー テーブルに追加する必要があります。2 番目に重要な項目は、キーと値のペアとして追加できます。

このようにして、最も重要な情報を簡単に検索し、スキーマを変更せずにプロファイル アイテムを追加し続けることができます。

于 2009-01-09T21:55:58.090 に答える
3

ハイブリッド ソリューションは適切ではありません。基本的に、追加のプロパティをプロパティ バッグ テーブルに格納します。長期的には、レポートやクエリの実行が複雑になります。また、日付、int、decimal、ntext などを varchar として格納することは、パフォーマンスとスケーラビリティの交換として受け入れられるものではありません。必要が生じた場合、そのテーブルからどのように関係を作成しますか?

より良い方法は、ユーザー情報用のユーザー テーブルを用意することです。次に、ニーズが拡大するにつれて、新しい機能を表す新しいクラスを作成します。これらの新しいクラスには、対応するテーブルがある可能性があります。そうすれば、ユーザーに関連付けられたプロパティが独自の空間に属しているときに、「ユーザー」クラスが指数関数的に拡大することはありません。はい、将来的には、ユーザー テーブルに属する新しいプロパティが実際に作成される可能性があります。その時点で、戻ってスキーマと DBAL を調整する必要がありますが、それは理解しやすいコードの代償です。

あなたの例では、最初のユーザーテーブルにユーザーの住所情報があります。私がしていることの 1 つは、ユーザーだけでなくアドレスを保存する必要があることを知っていることです。したがって、別の Address テーブルを用意してから、null 許容の AddressId を User テーブルに含めます。そうすれば、Stores テーブルや Events テーブルがある場合、そこにも AddressId リレーションを含めることができます。このアプローチの副作用は、住所オブジェクトに戻って緯度/経度を追加すると、データ モデル内の全員がそれらの新しいプロパティも取得することです。

于 2009-01-09T22:45:16.587 に答える
0

パフォーマンスと設計のスケーラビリティの理由から、ハイブリッド ソリューションも使用します。

users私は、 (テーブル名の複数形も好きです) のようなテーブルは、他のオブジェクトによって一般的に処理されるデータのコア セットと、「領域」のような仕様内の基本的に書き込み専用データの拡張ビットに分割する必要があると感じる傾向があります。 、「middleinitial」、「shoesize」は、拡張可能で更新頻度の低い領域に移動できます。

于 2009-01-09T22:16:16.303 に答える
0

必須ではない追加情報を格納するための XML フィールドを用意しないでください。

これは構成ファイルで構成でき、さらに一歩進んで構成から UI コントロールを生成することもできます。

于 2009-01-10T00:05:20.687 に答える