юзер А зашел на страницу юзера В и ему показали что у них есть общие друзьяшки.
1. вытаскиваете конкретного юзера B по ID - обычный select. Дешевая операция. Очень быстрая.
2. получаете список друзей юзера B, из поля. скидываете его в LIST или МАССИВ, программно.
3. делаете пересечение ПОЛЯ ДРУЗЕЙ текущего пользователя А со списком B - все что в результате - это конкретные ID их общих друзей.
4. делаете запрос к users таблице с условием этих ID = общим друзьям.
5. выводите общих друзей.
Все операции очень быстрые. И не надо строить супер запросы на БД, которые тяжелые и дорогие.
БД умеет много чего - но это не значит что нужно всю логику переложить в БД и ждать когда она выплюнет правильный ответ на ваш запрос. Она его выплюнет, но насколько быстро и затратно?
1. составной ключ - первый ключ - ID сервера, второй сам LONG.
2. разделите LONG на количество серверов - получите шаг.
первый сервер будет генерировать с 0 до ШАГА-1
второй сервер генерирует с ШАГ до ШАГ*2-1
и т.д.
задать начало и конец генерации поля можно в настройкой конкретной таблицы.
в MS SQL знаю как. в Oracle не работал. но такое тоже есть там 100%.
ваши LONG значения не будут пересекаться между серверами.
1. я предлагаю не создавать дополнительную таблицу под хранилище пар ключей. и не делать дорогущие запросы через JOINы. Вы просто храните список внутри существующей таблицы. Вам останется только реализовать добавление в список, удаление из списка.
2. Умей отличать реальный проект или лабораторной работы в университете! В вашем проекте с 1 лямом юзеров вы будете хранить еще N лямов записей ключей. И это только функционал Друзья. А если захочется сделать функционал Подпизчики - еще куча ключей-записей. и т.д. За***тесь оптимизировать. + у вас не будет возможности сделать масштабирование своей БД.
В реальном проекте проще в логике приложения (код на ПэХаПе в вашем случае) сделать подгрузку данных и вывести в браузере. Чем ждать 100500 секунд когда база MySql вам отдаст JOIN JOIN JOIN.... запрос и при этом ваш сервер ну умрет.
redkin: делать связи и JOIN запросы на БД еще хуже.
не знаю как там у PHP с парсингом-сериализацией, неужели все так плохо?
вам достаточно будет сделать запрос конкретного USER - профиль пользователя.
и затем сделать запрос множества USERs - друзья - c условием что userid = requestfriendlist конкретные значения.
1. запрос к БД очень легкий. вытащить кокретные записи по ID - индексы и всетакое.
2. легко управлять списком друзей - обращение к одной записи.
"Параметр WMI_SIGNATURE формируется путем объединения значений всех остальных параметров формы в алфавитном порядке их имен (без учета регистра) с добавлением в конец «секретного ключа»
интернет-магазина. Если форма содержит несколько полей с одинаковыми именами, такие поля сортируются в алфавитном порядке их значений."
sim3x: пфф. вы еще скажите Пупин виноват. ) ты жалок! сначала разберись и почитай почему курс рубля падает. может поумнеешь. и не будешь всякую х***ю писать и ссылки давать.
Я понял! Вы хотите общую админку сделать для 12 сайтов?
ну тогда просто создавайте mysql_connect после ввода логина и пароля, через локальную БД определайте к кому подключаться. вот только все равно придеться создавать множество юзеров на всех БД - иначе не пустит. или работать чисто по мастер паролю, универсальному на все базы.
DoubleWish: ну тогда вам надо почитать про реализацию OAuth. И сделать межсайтовую авторизацию.
просто поймите суть еще одну - если пользоватерю надо будет на другой сайт (из тех 12) - он сам пойдет на другой сайт. Или выберет его из выпадающего списка.
А обмануть юзера, мол вводи логин и пароль - а мы тебя кинем туда куда-нужно - не сработает. в втроке браузера все равно будет отображаться конкретный сайт.
или делать один сайт общий (13й) и создавать DbContext на этапе авторизации, который будет иметь подключение к кокретной БД. но тогда логику отображения данных надо делать под все 12 сайтов.
FanatPHP: я не вкурсе контекста создания баз данных. может это разные абсолютно клиенты. а автор хочет сделать OpenID или OAuth для них всех.
скорее всего 12 баз данных - это 12 интернет-магазинов. по 12 разным категориям товаров или для 12 клиентов. но тогда зачем дугим клиентам знать про другие 11 сайтов помимо себя? зачем объядинять единую точку входа? много вопросов, а автор не хочет идти на встречу.
