вот, смотрим на этот форум и видим список тем. в конце есть дата обновления и имя последнего отвечавшего.

вопрос: как бы это сделать оптимальней?

раньше бы (при малых объёмах постов и тем) я бы не стал заморачиваться, и даже не создал бы поля под это дело в таблице topics.
но допустим, количество посетителей будет такое же, как здесь. наверняка, лучше вставить дополнительные поля в таблицу topics: dateupdate и id_updater. и обновлять эти поля при каждом добавлении/редактировании поста в топик.
таким образом, мы устраняем по одному лишнему запросу на тему при выводе списка тем

теперь ещё одна заморочка. не будем же мы показывать id пользователей, надо отобразить имя. как это сделать?
единственное, что приходит в голову, так это при выборке топиков складировать все id_updater (а также id_creator) в массив, и затем провести дополнительный запрос на в таблицу users по набранным id.

будет это лучшим вариантом или следует как-то по-другому извернуться?
что-то мне не кажется, что составной запрос, где имя пользователя получается сразу, будет быстрее. али я не прав?


или может я ошибаюсь в некой глобальной точке?

А джойны совсем не рассматриваются?
Если первая задача денормализацией решается часто (но при этом усложняет обслуживание форума), то вторая-то как была джойном - так и остается.

очень даже рассматриваются.

сейчас попробую изобразить:



однако, 

считаете, что не прав. создавать и мерять что ли?

собсна, спрашиваю как всегда, предполагая, что могу в чём-то глобально ошибаться. может сейчас уже придумана более грамотная структура, чем разделы-топики-посты. /люди пожизни что-то придумывают/

Это сообщение отредактировал(а) bars80080 - 10.3.2010, 18:06

зачем left join?
даже если юзеры "удаляются", ничего не мешает оставлять их в базе и помечать "удаленными". при этом, использовать inner join во всех соответствующих запросах.
тебе ж имя пользователя понадобится при выводе сообщений темы - не будешь же ты при удалении пользователя удалять и все его сообщения, правда?

Добавлено через 35 секунд

inner join по числовому полю, ещё и первичному ключу - разницы практически не будет.

понятия не имею. физически не могу представить эту операцию (сколько не читал). поэтому просто передрал



то есть так:

?

первичный ключ, в смысле, id в users отмечено primary key и этого хватит?

 Сделай себе 2 таблички (id: 1,2,3  name: a,b,c)  и (id: 2,3,4  name: d,e,f) и попробуй над ними все типы джойнов. Поймешь по результату.

IMHO, так можно поступить и с именами пользователей: минус один запрос при выводе списка тем с создавшим, последним отписавшимся в тему, плюс дополнительные возможности по поиску тем по автору - задаётся маска имени и одним запросом находятся сообщения всех участников с похожими именами, возможно, есть ещё какие-то плюсы... Для вывода сообщений в полном формате - либо JOIN, либо два SQL: один на выбор топиков, второй - информации об авторах по массиву идентификаторов полученному в первом запросе.

Это сообщение отредактировал(а) Wolf1994 - 13.3.2010, 08:41

Wolf1994, ну если у вас нет опыта веб-разработки, то читайте хотя бы тему перед тем, как в нее писать. Никакого дополнительного запроса для имени автора и так не делается. Имя автора вообще не проблема для запросов, каких угодно - что для вывода тем, что для поиска авторов. Все делается джойном.

Я прочитал тему.

Прошу прощения, если что-то неправильно понял, но, кажется, речь всё же шла о выборе между вариантом с двумя простыми запросами:

и составным запросом:

которой я рискнул формально отнести к дополнительному запросу, так как он осложняет и замедляет выборку.

Суть моего комментария сводится к тому, что, в некоторых случаях, можно обойтись без этих двух вариантов, занеся информацию о name_creator, name_updater в таблицу топиков, в дополнение к id_creator, id_updater.

И раз уж коснулся упоминания двух вышеназванных методов выборки, то выскажу мнение человека далёкого от веб-разработки и по этому вопросу: два простых SQL предпочтительнее работы с JOIN.

ответ был дан выше:


что же касается

то это просто заблуждение.

Это моё мнение. Ваше право считать его заблуждением.

Беда в том, что такое "мнение", иррелевантное как задангному вопросу, так объективной реальности, у вас при каждой попытке что-то написать в этот раздел форума.

Тем не менее, я оставляю за собой право его высказывать, без претензии на абсолютную истину.

- накладные расходы на передачу запроса и обработку ответа от СУБД удваиваются
- оптимизатор работает с двумя отдельными запросами и результат оптимизации может быть хуже, чем если бы он получал сразу один запрос
- с точки зрения читаемости, код проигрывает, потому что логика выборки данных оказывается разделена между разными запросами и "разбавлена" дополнительными конструкциями(присваивания, условия или что там ещё)
если бы был подзапрос, приводящий к using temporary, то можно было бы ещё о чем-то спорить и делать замеры. а так как мы говорим про join, то я даже не берусь придумать причину, по которой два запроса были бы предпочтительнее одного.