1

SEARCH クエリのパフォーマンスに関する私の質問です。

純粋に検索用に存在する読み取り専用の Person テーブル (MySQL) にデータをフラット化しました。このテーブルには、約 20 列のデータがあります (ほとんどの場合、制限されたテキスト値、日付、ブール値、および無制限のテキストを含む列がいくつかあります)。 

Person
=============================================================
id      First   Last    DOB         etc (20+ columns)...
1       John    Doe     05/02/1969
2       Sara    Jones   04/02/1982
3       Dave    Moore   10/11/1984

別の 2 つのテーブルは、Person と Activity の間の関係をサポートします。

Activity
===================================
id      activity
1       hiking
2       skiing
3       snowboarding
4       bird watching
5       etc...

PersonActivity 
===================================
id      PersonId        ActivityId
1       2           1
2       2           3
3       2           10
4       2           16
5       2           34
6       2           37
7       2           38
8       etc…

検索に関する考慮事項:

  1. Person テーブルには 200 ～ 300k 以上の行が含まれる可能性があります
  2. 1 人あたり 50 以上のアクティビティがある可能性があります
  3. 検索にはアクティビティ フィルターが含まれる場合があります (例: 1 つまたは複数のアクティビティを持つ人物を選択)
  4. 返された結果は、個人の詳細と活動とともに箇条書きリストとして表示されます

Person テーブルが検索のみに使用される場合、Activity テーブルと PersonActivity テーブルに結合するのではなく、アクティビティをコンマ区切りの値として Person テーブルに追加する必要があるかどうか疑問に思っています。

Person
===========================================================================
id     First    Last    DOB         Activity    
2      Sara     Jones   04/02/1982  hiking, snowboarding, golf, etc.

上記の検索に関する考慮事項を考慮した場合、これは検索のパフォーマンスに役立ちますか、それとも低下しますか?
入力していただきありがとうございます。

4

1 に答える 1

3

恐ろしい考え。クエリでインデックスを使用できなくなります。その列を検索する場合は、どのような状況でもデータをコンマ区切りのリストに保存しないでください。Realtional データベースは、テーブルを結合してパフォーマンスを向上させるように設計されています。データベースは比較的小さいため、適切にインデックスを作成すれば、パフォーマンスの問題はまったく発生しないはずです。

コンマ区切りで結果を表示したい場合もあります。そのために MYSQL には GROUP_CONCAT という関数があると思います。

于 2013-05-10T17:04:29.770 に答える