Istnieje nadrzędna tabela, która przechowuje podstawowe informacje o budynkach typu:

tabela objects
o_id - ID budynku
o_name - nazwa budynku

każdy budynek może posiadać wiele zdjęc (1:n) w tabeli object_images
oi_id - ID zdjęcia
object_id - klucz obcy do tabeli z obiektami
oi_path - ścieżka do zdjęcia

każdy budynek może posiadać wiele sal (1:n) w tabeli object_rooms
r_id - ID sali
object_id - klucz obcy do tabeli z obiektami
r_name - nazwa sali

dodatkowo budynki mogą posiadać różne akcesoria (n:n) w tabelach:

accessories
a_id - ID akcesorium
a_name - nazwa akcesorium

accessories_to_objects - tabela łącznika
accessory_id - id akcesorium
object_id - id obiektu
a_price - cena danego akcesorium w konkretnym obiekcie

Dodatkowych tabel i zależności do obiektu jeszcze jest kilka. Aktualnie mam to rozwiązane w ten sposób:

1. W metodzie modelu, która ma za zadanie pobrać wszystkie dane wszystkich obiektów robię zapytanie w stylu:

[SQL] pobierz, plaintext 
SELECT o.o_id, o.o_name, GROUP_CONCAT(DISTINCT(oi.oi_id)) AS object_image_id, GROUP_CONCAT(DISTINCT(oi.oi_path)) AS object_image_path FROM objects o LEFT JOIN object_images oi ON (oi.object_id = o.o_id) GROUP BY o.o_id
[SQL] pobierz, plaintext 

w zapytaniu jest więcej JOINów i GROIP_CONCAT dla kolejnych tabel 1:n i n:n

Na liście obiektów potrzebuję wyświetlić dane o 20 obiektach ze zdjęciami i ich atrybutami, stąd to wszystko w jednym zapytaniu. Czy jest to poprawne użycie? Czy lepiej poradzić sobie jakimś innym zapytaniem lub rozbić to na kilka zapytań?

2. W metodzie modelu, która ma za zadanie pobrać tylko dane o jednym obiekcie po jego ID, robię kolejno np. 5 prostych zapytań typu:

[SQL] pobierz, plaintext 
SELECT * FROM object_images WHERE object_id = ID
SELECT a_name FROM accessories a JOIN objects_to_accessories a2o ON (a2o.accessory_id = a.a_id) WHERE a2o.object_id = ID
...
[SQL] pobierz, plaintext 

Później łącze wyniki i je zwracam. Czy taki sposób także jest wydajny, czy lepiej to zrobić na mniejszej liczbie zapytań lub w inny sposób?