Система друзей на php mysql

Система друзей на php mysql

В этом разделе помещены уроки по PHP скриптам, которые Вы сможете использовать на своих ресурсах.

Фильтрация данных с помощью zend-filter

Когда речь идёт о безопасности веб-сайта, то фраза «фильтруйте всё, экранируйте всё» всегда будет актуальна. Сегодня поговорим о фильтрации данных.

Контекстное экранирование с помощью zend-escaper

Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.

Подключение Zend модулей к Expressive

Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.

Совет: отправка информации в Google Analytics через API

Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.

Подборка PHP песочниц

Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.

Совет: активация отображения всех ошибок в PHP

При поднятии PHP проекта на новом рабочем окружении могут возникнуть ошибки отображение которых изначально скрыто базовыми настройками. Это можно исправить, прописав несколько команд.

Агент

PHP парсер юзер агента с поддержкой Laravel, работающий на базе библиотеки Mobile Detect.

Источник

Система друзей/подписчиков на php

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Система друзей и ее реализация php mysql
Всем привет, кто может мне помочь с реализацией система друзей на сайте? Сколько таблиц надо.

совет нужен! система друзей на сайте
Добрый вечер, дорогие форумчане! решил обозначить (наметить) систему друзей на сайте, и.

Как создать систему друзей php mysql
Как создать систему друзей, то-есть: Отправляем заявку в друзья пользователю, а он подтверждает.

Спасибо большое!
Но у меня есть еще вопрос.

Но сложна ситуация при принятии заявки в друзья.

В этом случае должен поменяться status на friend.
Сложность заключается в следующем.

Вот когда юзер является к другому подписчиком (subscriber’ом) сохраняется «направление» заявки в друзья- от одного юзера к другому. И когда нужно вывести на экран всех подписчиков проблем нет, потому что нужно просто вывести получателя заявки.

Но когда заявка принята, юзеры становятся друзьями и это «направление» стирается ведь в случае, о котором я описал выше один юзер является подписчиком другой нет. А когда становятся друзьями, то они друг другу являются друзьями. Направление заявки исчезает. По крайней мере должно, но не все так просто.

Возможно я не понятно объяснил словесно, поэтому попробую в форме таблицы (если получится потому что не рисовал таблицы на форуме)

Допустим есть таблица

И допустим если нужно вывести всех подписчиков mikhailshell, то есть все строки ГДЕ `user` = «mikhailshell» И `status` = «subscriber»;

Выведет
user1
user2
user4
user6

И вторая ситуация где во всех строках status = friend.

Мне нужно вывести все всех друзей.
Но если двигаться по той же схеме (ГДЕ user = «mikhailshell») то выведутся те же самые люди что и в первом случае. А нужно чтобы было все.

Подскажите пожалуйста, что нужно сделать чтобы решить данную проблему!

Источник

Система друзей и ее реализация php mysql

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Система друзей/подписчиков на php
Недавно появилась необходимость создания системы друзей/подписчиков на сайте. Но я не совсем.

Как создать систему друзей php mysql
Как создать систему друзей, то-есть: Отправляем заявку в друзья пользователю, а он подтверждает.

Система тестирования php+mysql
Создаю систему тестирования. Возникли такие проблемы: 1.нет перехода на следующий вопрос.

Реализация сортировки по дате PHP MySQL
Здравствуйте. Стоит такая задача. Есть страница с объявлениями при нажатии на ссылку «СОРТИРОВАТЬ».

Это и есть конкретное решение. Зачем вам еще одно, в котором вы все равно не разберетесь? Вы уже 3 месяца с этой темой сидите.

Вы спрашиваете о таблицах и полях, но при этом даже ТЗ не написали.
Вот с этого и начните.
Потом, не нравится mysql, хотите PDO? Изучайте PDO. Сами sql запросы там абсолютно такие же.

tarasalk, Сами запросы одинаковые, я это знаю, но есть там например дополнительные stmp->PDO типа таких вставок, вот я с этим туплю)
Ладно могу скинуть что у меня получилось, а вы если хотите помогите отредактировать, что не так пожалуйста.

Добавлено через 10 минут
tarasalk,
requests:

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

Ну и скрипты на удаление и отклонения друзей аналогичные друг другу, один напишу, второй такой же:

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

Вот же этот кусок, в примере который я вам кинул он практически во всех запросах есть

Наоборот, надо еще больше разделить на файлы. У вас тут каша полная. html и БД это не то что разные файлы, но вообще разные слои.

1) выкинуть PDO, используйте например библиотеку medoo.
2) почитайте про MVC.
3) пишите свой код, а не просто копипасты из разных источников.
4) использовать более логичные названия переменных. Вот совсем не очевидно когда add_friend превращается в receiver_id. Тратится куча времени чтобы пройти по всей логической цепочки и понять что откуда и куда. А должен быть маленький метод, который выполняет конкретно одно логическое действие.

Помощь в написании контрольных, курсовых и дипломных работ здесь.

MYSQL PHP Система оповещений (Notices)
Доброго времени суток, уважаемые коллеги! Реализовал систему оповещений на своем сайте. Оповещения.

Реализация двухуровневого меню на php&MYSQL
Есть две таблицы: categories и sub_categories Нужно выводить это в двухуровневое меню, вот в.

совет нужен! система друзей на сайте
Добрый вечер, дорогие форумчане! решил обозначить (наметить) систему друзей на сайте, и.

Хранение друзей в базе данных mysql
Добрый вечер. У меня вопрос. Лучше всего, для каждого пользователя, создавать отдельную таблицу.

Источник

Как реализовать хранение друзей в БД?

Как хранить связи вида пользователь-друг — понятно. Создаем таблицу friend в которой два столбца — user и friend. Делаем ключ по двум полям. Соответственно, пользователь А, добавил в друзья пользователя B — появилась соответствующая запись. Когда пользователь В подтвердил заявку в друзья — создается симметричная запись.

Далее, если хотим вывести друзей пользователя, пишем что-то вроде
select f1.friend from friends f1 join friends f2 on f1.user=f2.friend and f2.user=f1.friend where f1.user=:user_id

Но что делать если мы хотим вывести не только т.н «взаимных друзей» но и заявки в друзья и не подтвержденные заявки в друзья.
т.е например:
Пользователь user1 добавил в друзья пользователей user2, user3. user2 подтвердил заявку. user4 добавил в друзья user1. И в профиле user1 должно выводиться:
user2 (удалить из друзей)
user3 (отозвать заявку)
user4 (принять заявку)

Как правильно написать запрос? Или одним запросом не обойтись?

А что если хранить немного по другому?

Например не создавать дублирующую запись в обратную сторону, а изначально использовать еще одно поле в троичной системе счисления: ± 1 когда один пользователь добавил другого (знак указывает направление заявки) и 0 когда заявка подтверждена.

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

Из очевидных плюсов. Места занимать будет примерно в два раза меньше — мелочь, а приятно.
Минусов не сразу не соображу.

Просто тогда непонятно как выбирать друзей пользователя. Если делать что-то вроде select * from friend where user = :user_id or friend = :user_id, то не совсем понятно становится, кто кого добавил friend юзера в друзья или юзер френда. Ну и соответственно запись вида

будет означать одно и то же. Понятно, что добавляться будет только одна из них, но мороки, имхо, слишком много

Записи не идентичны.
если 1 добавил 2, то будет запись 1 2 0
если 2 добавил 1, то будет запись 2 1 0

Тут по записи видно кто инициировал добавление, кроме того, можно даже для дополнительного поля использовать bool, характеризующий подтвержденность дружбы. А направление запроса брать из полей user и friend.

Все что выше — мое видение направления решения. Идти в этом направлении или нет — решать вам.

Так хранить друзей это не очень хорошая идея. Если на сайте будет 1000 пользователей и у каждого по 100 друзей, то у вас будет таблица на 200000 записей, и довольно медленные запросы для такой простой штуки как список друзей.
Я бы сделал денормализацию, то есть просто хранил бы список друзей строкой в поле модели user 🙂
Быстрые запросы, так как пропарсить строку в несколько сотен символов будет быстрее, чем делать запрос к таблице в несколько сотен тысяч записей, да и в разработке такой способ проще.
Хотя возможно я ошибаюсь и разница в производительности будет не такой большой.

Собственно, отвечаю на ваш вопрос. Нужно просто получить список всех записей, где user1 есть в поле user или friend, затем уже в коде определить, взаимные это друзья (есть запись где user1 в поле friend, и запись где user1 в поле user, второй пользователь одинаковый в обоих запросах) или кто-то из них только отправил запрос. Запрос будет чем-то вроде:
select user, friend from friends where user=:user_id or friend=:user_id

> у вас будет таблица на 200000 записей
И что? И 50 лямов — не проблема для тупого индекс-скана даже на убитой виртуалке.

А вот хранить массив в поле таблицы — ветвь тупиковая. Чуть только понадобится найти «кто добавил в друзья меня», а не кого добавил этот пользователь — сразу получается full-scan, который быстро выполняться не может в принципе.

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

пересечение будет давать взаимных френдов, вычитания — невзимных с одной и с другой стороны.
синтаксис SQL говорит что это легко можно сделать полным join, который обычно не имплементируется но эмулируется обьединением left и right. То бишь:

и будет 3 варианта — обе f1 и f2 не null — взаимные друзья или один из них null

Но это не самый эффективный способ, я бы согласился с serso и посоветовал иметь доп колонку с типом ( заодно можно их иметь несколько — друзья, супруги/любовники, коллеги ) и при добавлении проверять обратное отношение и сразу заполнять колонку. На нагруженной системе это можно делать в отложенном режиме.

Источник

Система личных сообщений с диалогами с помощью Mysql и PHP

Большинство CMS и форумов используют довольно устаревшую систему для переписки. Уже давно время поставило свои стандарты, поэтому необходимо идти нога в ногу с прогрессом.

В этом посте объясняется, как спроектировать систему обмена личными сообщениями в виде диалогов с использованием PHP и MySQL. Мы будем использовать Класс для работы с базой данных MySQL.

Перед началом хочу объяснить, что в данной статье будет описана структура и все методы работы с базой данный, которые включают исходные коды SQL запросов. Здесь не будет рассматриваться вопрос верстки дизайна переписки, поскольку это дело вкуса. Описанные здесь основы дадут возможность реализовать на своем сайте довольно неплохую систему переписки. Достаточно добавить асинхронную загрузку с помощью jQuery и будет вам переписка в виде диалогов аналогичная VK или Facebook.

Основные возможности системы переписки:

— Вывод диалогов получателей и отправителей сообщений.

— Возможность визуально пересмотреть, прочитано сообщение или нет.

— Просмотр количества непрочитанных сообщений.

— Удаление сообщений и диалогов индивидуально для каждого пользователя.

При создании системы переписки мы подробно разберем:

— Создание структуры базы данных.

— Создание диалога и отправка сообщения.

— Вывод диалогов пользователя и личных сообщений.

Чтобы реализовать систему обмена сообщениями, необходимо создать 3 таблицы: Users, Conversation и Messages.

Для логичной структуры и взаимосвязи таблиц, последняя таблица Messages должна содержать следующие поля:

Соответственно, если один пользователь удаляет сообщение, в собеседника сообщение не удаляется.
Благодаря такой реализации мы создали вполне логическую структуру построения системы личных сообщений в виде диалогов.

Будем следовать по порядку. Пользователь хочет написать сообщение другому пользователю, соответственно, при этом должна осуществляться следующая логика:

— Проверка на существование диалога между пользователями.

Перед данной логикой, на всякий случай, проверяем, не отправляет ли пользователь сообщение сам себе.
Следующим шагом мы выведем список всех диалогов пользователя. Для этого мы создадим запрос, в котором ищем все записи, в которых фигурирует данный пользователь (в данном случае с ID 1). Также сортировка будет происходить по полю непрочитанных сообщений, поэтому они всегда будут наверху и навиду:
После того, как мы отправили сообщение, просмотрели список диалогов, нам необходимо увидеть все сообщение с определенным пользователем, что полностью реализует следующий код:
Думаете это все? Ошибаетесь. Остается еще 2 важных функции, а именно удаления конкретного сообщения и диалога. Начнем с удаления сообщения:
Для удаления диалога выполняем код:
Самое важное, а это структура базы данных, было изложено. При проектировании вашей системы сообщений, а это будет имеено ваша, потому что для каждого проекта необходимый свой функционал, вам необходимо будет перерабатывать и дорабатывать код. В данной статье были упущены некоторые детали, например, обновления полей таблицы диалога при удалении сообщения, отображение аватарок при выводе сообщений, сортировка диалогов и другое, но если все описывать, так вам не будет над чем работать, поэтому усовершенствуйте свои знания в области запросов SQL и проектируйте свои, намного быстрее и качественные продукты.

Но, как бонус к статье, я опишу еще алгорит динамической работы, которая, в моем случае, реализована с помощью библиотеки jQuery.

Для реализации необходимо дополнительно иметь идентификаторы стилей start_id и last_id, которые обозначают ID первого и последнего сообщения, которые будут отображены польователю. Данные идентификаторы нужны для того, чтобы подгружать предыдущие сообщения, основываясь на start_id (10 записедо до данного ID), и новые сообщения, ID которых больше за last_id. Использование данной техники позволит безошибочно выводить порядочность сообщений.

Источник