LIKE ни в коем случае. Если короткое имя одного пользователя будет содержаться в имени другого пользователя, это явно косяк.
это вопрос регистрации пользователей - какие там ограничения. Если выставить ограничение в 5-9 символов, поиск возвращать вполне адекватные результаты поиска.
Сообщение от brainix
Исключительно по id пользователям обращаться в бд.
м? в поиске вбивать id пользователя? Данный вопрос решается на уровне БД - какие связи между таблицами сообщений и пользователями.
Сообщение от brainix
Несколько адресатов можно записывать в бд айдишники через запятую, а потом парсить explode эту строку. Ну естественно нужно как-то ограничить, там 50, 100 адресатов. Но так лучше сделать для этой задачи на мой взгляд.
Не совсем удобная структура. Лучше уж таблицы-связки. В вашем варианте, запрос в базу будет проходить по всем записям базы, что уменьшит время поиска. Да и запросы надо будет делать _мягко говоря_ извращенными (читать с теми же LIKE).
Сообщение от OKyJIucT
насчет ограниченного количества - это само собой) в базе более 5000 сообщений, и все шерстить для проверки нереально
5000 сообщений - вполне нормальное количество для вывода результатов. БД это никак не напрягает. Напряги с бОльшим количеством записей( > 1 млн.). Если же у вас на данном уровне возможны такие выборки, значит структура базы не очень-то уж и удобная для использования.
OKyJIucT, вот тут например тема связей и explode поднималась. Еще в интернете на тему "сделать теги статьям php" обычно выдает про таблицы связи. Еще иногда полезно покопаться в движках, например в таблицах форума какого-нибудь, там кстати и таблицы связи можно найти еще.
Если выставить ограничение в 5-9 символов, поиск возвращать вполне адекватные результаты поиска.
sw04, возьмем даже этот форум. Ник администратора seo_optimizator и ник новичка будет допустим seo. Ай какая незадача, новичек переписку администратора сможет прочитать. А ограничивать настолько коротко логины это не комильфо для проекта, где должно быть много пользователей. Для интереса гляньте какой самый длинный ник на этом проекте.
Исключительно по id пользователям обращаться в бд.
м? в поиске вбивать id пользователя? Данный вопрос решается на уровне БД - какие связи между таблицами сообщений и пользователями.
О том и речь, вероятно было неясно потому что не стал расписывать мысль.
sw04, возьмем даже этот форум. Ник администратора seo_optimizator и ник новичка будет допустим seo. Ай какая незадача, новичек переписку администратора сможет прочитать.
чтобы ввести seo и получить результат seo_optimizator надо чтобы в запросе присутствовал % Пример: `user` LIKE 'seo%' А если будет `user` LIKE 'seo' - то результат seo_optimizator не выдаст хотя может я не понял, как вы собираетесь использовать like :) Чет намудрили короче)
OKyJIucT, если несколько значений может попробуйте сделать так:
Код:
SELECT * FROM `users` WHERE `user` in ('seo','seo_optimizator','еще какой-то ник')
Последний раз редактировалось Unick; 16.02.2013 в 15:04.
OKyJIucT, да, так рациональнее, я бы тоже через id делал. Но только это зависит от структуры таблиц, возможно так придется на 1 запрос больше делать, вам придется получить список id по никам, и потом уже работать с id
Я бы предложил сделать так 1 таблица: таблица пользователей user id nick 2 таблица: таблица сообщений chat id message in_id /* кому */ out_id /* от кого */
Пример запроса, чтобы прочитать входящее сообщение для человека
Код:
SELECT `user`.`nick`,`chat`.`message` FROM `chat`,`user` WHERE `chat`.`in_id`={$id_пользователя} AND `chat`.`out_id`= `user`.`nick` LIMIT 1;
И на вывод будет примерно такое: nick: seo_optimizator message: Правила никто никуда не тащит :) А вот пример:
[свернуть]
Последний раз редактировалось Unick; 16.02.2013 в 15:54.
redm1ke, есть сайт, который предлагает услуги (продает) вы даете реф ссылку, сайт запоминает что пользователь пришел от вас. И если пользователь что-то покупает, сайт смотрит, кто его пригласил и дает ему плюшку :)
Зы Сайт получает гет запрос и создаету пользователя кукисы, если он уйдет с сайта и вернется, то он увидит ранее созданные куки.
OwnCloud (http://owncloud.org/) — это бесплатное программное обеспечение на PHP, с помощью которого можно легко поднять собственный веб-сервис, аналогичный Dropbox или другому облачному хостингу. Вы можете хранить файлы, синхронизировать их через веб-интерфейс, с поддержкой WebDAV.
Платформа ownCloud с открытыми исходными кодами развивается уже около трёх лет, и сейчас обросла целым рядом полезных функций, например, для синхронизации контактов, событий из календаря, закладок между целым рядом устройств. Появились базовые функции для редактирования файлов в вебе и многое другое. Буквально в ближайшие дни ожидается выход пятой версии ownClowd с видеоплеером, PDF-просмотром, полнотекстовым поиском и другими нововведениями, пишет TechCrunch.
Для инсталляции ownCloud подходит сервер минимальной конфигурации, процесс максимально оптимизирован для простоты и скорости установки. Дальнейшее расширение функциональности собственного облачного хостинга осуществляется через простые API для подключения сторонних приложений, а также через плагины.
Разработка программного обеспечения ownCloud началась в январе 2010 года, когда на конференции Camp KDE 2010 в Сан-Диего один из линуксоидов выступил с пламенной речью о том, что пользователям обязательно нужно своё облако, полностью контролируемое, настраиваемое и предсказуемое, с открытыми исходными кодами. Это единственная альтернатива сервисам вроде Dropbox, Box.net и Google Drive, использовать которые небезопасно.
На базе свободного проекта существует и коммерческая компания ownCloud, которая предоставляет услуги корпоративным пользователям: внедрение, техподдержка и проч. Это стандартная модель заработка на open source программах, так же делают разработчики MySQL, различных дистрибутивов Linux и другого популярного ПО под свободными лицензиями.
[свернуть]
Сам очень заинтересовался этим проектом, очень много полезного кода покурить можно, посмотрите демо и вдохновитесь.