Всем привет. Создаю на сайте личные сообщения в виде диалогов. Имеется таблица im с полями: id - индекатор user_from - имя отправителя id_from - id отправителя user_to - имя получателя id_to - id получателя text - текст письма date - дата отправки see - просмотрено ли сообщение (знач. 0 и 1) Возник следующий вопрос... Как просканить таблицу, и выводить имена тех, с кем была переписка? Вот мой код... P.S. Переменная login это мой ник PHP: $sql = mysql_query("SELECT user_from FROM `im` WHERE user_from != '$login' and user_to = '$login' or user_to != '$login' and user_from = '$login' GROUP BY user_from ORDER BY date DESC"); while($result = mysql_fetch_array($sql)) { echo"$result[user_from]<br>"; } Всё вроде работает, то проблема в том, что имена с темми с кем я переписывался будут дублироваться, так как имя переписчика может быть и в user_from и в user_to... В этом и проблема Объеденить в запросе эти 2 поля я не умею И второй вопросик... Правильно ли я вообще делаю? Или же при наличии в таблице пару миллионов строк, моя БД рухнет? так как мне приходится постоянно селектить всю таблицу, чтобы найти всех челов с кем была переписка?
В фильтрах запроса используйте не логин а идентификатор пользователя ("Id_from, Id_to" в вашем примере). Это только вы знаете. Требования к приложению вы не озвучивали. В любом случае, какой бы не была реализация, в запросе должны присутствовать ограничители на количество извлекаемых записей (LIMIT)
не много не понял этой фразы - человек пишет сам себе ? на сколько я знаю любая внутрення переписка это диалог 1 на 1 .. например вася с федя федя с вася можно предположить что есть групповой чат - но тут по полям не проходите почему не просто вот так ? Код (Text): WHERE user_from!= '$login' or user_to = '$login'
Боюсь, что LIMIT работает не так. Это не "найди только N результатов и верни мне", это "найди ВСЕ результаты, а мне верни только N из них". На большой базе нужна индексация грамотная. Тогда все будет работать как надо.
стоп-стоп. Я и не утверждал конечно что LIMIT сам по себе влечет к обработке СУБД лишь записей равному количеству записей в LMIT. Разумеется если не будет индекса, то будет фулскан таблицы для возврата лимитированного числа записей. В данном случае, нужен будет индекс на поля в условии WHERE тса, на которые, вероятнее всего будет ещё и сортировка ORDER BY (в идеале). Если сортировка на другое поле то (тут уже по ситуации) вероятно нужен будет индекс на поле сортировки для оптимизации скорости.
Ок, просто это частое заблуждение, что использование лимита снижает нагрузку на БД, мол выборка останавливается на определенном количестве.