ユーザーが検索ボックスに任意のキーワードを入力し、すべてのテーブルを検索することで、研究所名、所属するホットスポット、都市、コースなどの詳細をいくつかの研究所に提供できる大学検索システムを作成したいと考えています(エリア、都市、研究所名、コース、または私たちが持っているものなら何でも)。
しかし、問題は、すべてのテーブル間で結合を行う必要があり、速度が遅くなりすぎていることです。これらのテーブルを最適化して、データベースをより検索/フィルターに適したものにすることはできますか?
今のところ、MongoDBを使用してこれらのデータを単一のコレクションにキャッシュしています。 MongoDBはリレーショナルデータベースシステムではないため、多くの機能に妥協する必要があります。
MongoDBは私にとって唯一の解決策ですか?または、これらを最適化できますか?
私の質問は
SELECT i.name, GROUP_CONCAT(h.hotspot_name) hotspots,
GROUP_CONCAT(ac.accreditation) accreditations, c.city_name from institutes i
left join areas a on i.area_id = a.area_id
left JOIN districts d on a.district_id = d.district_id
LEFT JOIN cities c on c.city_id = d.city_id
LEFT JOIN institute_hotspots ih on ih.inst_id = i.inst_id
LEFT JOIN hotspots h on ih.hotspot_id = h.hotspot_id
LEFT JOIN institute_accr ia on i.inst_id = ia.inst_id
LEFT JOIN accreditations ac on ia.accr_id = ac.accreditation_id
LEFT JOIN institute_courses ic ON i.inst_id = ic.inst_id
LEFT JOIN courses co on ic.course_id = co.id
LEFT JOIN course_names cn on co.course_id = cn.id
LEFT JOIN subcourses sc on co.subcourse_id = sc.id
LEFT JOIN course_types ct on co.type_id = ct.id
LEFT JOIN course_levels cl on co.level_id = cl.id
LEFT JOIN course_streams cs on co.stream_id = cs.id
LEFT JOIN course_category_relation ccr ON co.id = ccr.course_id
LEFT JOIN course_categories cc ON ccr.category_id = cc.id
WHERE i.name LIKE '%{QUERY}%'
OR i.name LIKE '%{QUERY}%'
OR c.city_name LIKE '%{QUERY}%'
OR a.area_name LIKE '%{QUERY}%'
OR d.district_name LIKE '%{QUERY}%'
OR h.hotspot_name LIKE '%{QUERY}%'
OR ac.accreditation LIKE '%{QUERY}%'
OR cn.name LIKE '%{QUERY}%'
OR sc.name LIKE '%{QUERY}%'
OR cl.name LIKE '%{QUERY}%'
OR ct.name LIKE '%{QUERY}%'
OR cs.name LIKE '%{QUERY}%'
OR cc.name LIKE '%{QUERY}%'
GROUP BY i.inst_id
limit 10
私のローカルシステムでも動作しません。
ダイアグラムの準備中に、いくつかのフィールド名を変更しました。
34テーブルがたくさんあります。
いくつかの例:
地区-都市-州のネストされた性質、および都市と州の名前が「決して」変更されないという事実のために、その正規化をdistrict
(またはおそらくarea
)を超えて実行する必要はありません。 )。
2文字の州の略語を使用し、フルネームを使用しないことをお勧めします。注:サイズ(2バイト)を最小化するには、CHAR(2) CHARACTER SET ascii
にする必要があります。
keywords
、course types
などの単純なものを「正規化」する必要はありません。そのようなものが比較的少なく静的な数である場合は、それらにENUM
を使用することを検討してください。
「認定」は1つの機関に対するものですよね?それは多くの研究所にとって毛布ではありませんか?つまり、これは実際には1:多く、多くはありません:多くです。したがって、中間テーブルは不要です。 (いくつかの関係は引き続き多くなるはずです:多く。)
数十のアイテムには、TINYINT UNSIGNED
(4バイト)ではなく、INT UNSIGNED
(1バイト)を使用します。数百、場合によっては数千の場合は、SMALLINT UNSIGNED
(2バイト)を使用します。
type_id
とは何ですか?