2009-09-04 6 views
0

PHPとMySQLを使用して、ユーザーについての多くのプロパティ(例えば、DOB、高さ、重量など)を格納する必要のあるサイトを構築する(単一テーブル、多数のプロパティ)が必要です)。正規化または代替MySQLを使用

しかし、システムはまた、話し言葉や器械的能力などの他の情報も記憶する必要があります。まったくそのような特性は十数以上あります。デフォルトでは、別のテーブル(多分言語と呼ばれる)を作成し、次に複合ID(user_id、language_id)を持つリンクテーブルを作成すると仮定しました。

私はこれらの基準を使ってユーザーが検索しようとしていますが、問題は予見しています。使用する予定のデータセットには、起動時に15,000人以上のユーザーがおり、主な機能はユーザーの検索と改善です。これは、毎日何百ものクエリが発生していることを意味し、数十個以上のJOINを使用してクエリを使用する見込みは魅力的ではありません。

私の質問は、より効率的になる選択肢がありますか?私が考えていた1つの方法は、ユーザーテーブルにIDのCSVとしてM2M値を格納し、それに対してLIKEクエリを実行することです。私はLIKEが最高ではないことを知っていますが、参加よりも優れていますか?

解決策はありますか?

答えて

1

ジョイントで実行します。あなたのパフォーマンス目標が満たされていない場合は、別のものを試してみてください。

+0

これは、サンプルが1500台の高速なマシンで実行されていることです。速度が遅すぎるような線形速度であっても、すでに400 + msを要しています。 – Dachande663

+0

私はそこにあなたの設定で何か非常に間違っていると思います:1500行は小さいです;索引なしで完全な表検索を実行する最悪の場合でも、400msかかるとは限りません。どのテーブルタイプを使用していますか、インデックスはありますか?正確なクエリは何ですか? – bobince

+0

@bobince:私は彼が15,000と言っていると思うが、私は完全に同意すると思うが、15kでもそれはまだ小さく、問題は別の場所になければならない。 – erikkallen

0

normalizedデータベース(たとえば、マッピングテーブルによってユーザーテーブルにリンクされた言語テーブル)から始めて、データがきれいに論理的に表現されていることを確認してください。

パフォーマンスに問題がある場合は、クエリを調べて、適切なindexesがあることを確認してください。

多数の結合を含むクエリを繰り返しコーディングすることを嫌う場合は、viewsを定義します。

ビューのクエリが非常に遅い場合は、materialized viewsを検討してください。

1日に数千のレコードと数百のクエリがある場合(実際には、これは非常に小さく、使い方が低い)、これらの手法では、データの完全性を損なうことなくフルスピードでサイトを実行できます。数百万のレコードと数百万のクエリを一日に拡大する必要がある場合、これらの手法でさえ十分ではないかもしれません。その場合は、cacheingdenormalizationを調べてください。

関連する問題