Võrgurakendused I / Programmeerimise põhikursus

Отправлено 03 декабря 2010 - 19:13

• Наверх
• 

Отправлено 03 декабря 2010 - 21:38

• Наверх
• 

Отправлено 03 декабря 2010 - 21:44

• Наверх
• 

Отправлено 03 декабря 2010 - 21:46

• Наверх
• 

Отправлено 03 декабря 2010 - 21:47

• Наверх
• 

Отправлено 04 декабря 2010 - 01:23

• Наверх
• 

Отправлено 04 декабря 2010 - 11:09

• Наверх
• 

Отправлено 04 декабря 2010 - 16:37

• Наверх
• 

Отправлено 04 декабря 2010 - 16:52

Wardann, Опять же, я же просто пошутил, на что указал в пс
у frienship идет many to many к юзер, если конечно ничего не путаю. Так что требуется одна таблица где будет ид записи ид юзера номер один ид юзера номер два. Если запись есть в таблице, значит друзья, если нет значит не друзья. Опять же возможны варианты, типа как уместить всю БД в одну таблицу, но это уже на вкус и цвет...

• Наверх
• 

Отправлено 04 декабря 2010 - 20:55

JakeTheFIsh, интересно будет посмотреть на приложение с одной таблицей в БД, когда как минимум должно быть 2 таблицы из-за реляции между ними.

Народ,в 4 дз выргу как организовать проверку,является ли человек в списке мои друзья? У меня только складывается такое решение:

1) Создать таблицу friends и выделить в ней 3- поля(id,user,pass,email,status);
2) Создать кнопку Добавить друзя и обработчик для неё click,в котором через аякс пышному скрипту(как в вк) передавался бы логин и заносился бы инсертом(походу херню сморозил)в таблицу с френдами;
3)Создать кнопку Отправить приглашение будущему друзю(ну чот такое),но опять-таки через аякс!(о_О!) проверять,есть ли такой аккаунт уже в таблицы френдов.
Если есть,то выдать предупреждение мол *такой друзь уже есть!*
4)Для вывода списка друзей тупо заюзать while($row = mysql_fetch_arra($r)) {}

Есть у кого какие мысли ?? Теряется логика,блин... Нарисовать это дело,чтоли.

1) В данном случае в таблицу friends не нужно ничего писать, кроме ID двух человек, которые продтвердили дружбу между собой внутри приложения.
2) Слишком усложняешь. Просто не отображай кнопку для пользователей, ID которых есть в таблице friends. Сортировку SQL-запросом выполнить можно.
3) Опять усложняешь с AJAX. Создай еще одну таблицу в БД для хранения запросов о дружбе. Каждый раз при логине пользователя выводи ему на главной странице все существующие для него запросы с двумя кнопками - "принять" и "отклонить". "Принять" заносит запросившего в список друзей и удаляет уже ненужный запрос из таблицы. "Отклонить" сразу же удаляет запрос из таблицы БД.
Проверку нужно ставить не при отображении запроса о дружбе, а при подаче его - т.е. не выводить кнопку "Добавить в друзья" если пользователи уже и так друзья.
4) Лупом, да. Только не забудь правильный SQL-запрос построить, который бы выделял из таблицы friend только друзей конкретного пользователя, а не всех подряд.

P.S Конечно нарисуй Это всегда помогает при разработке. А еще ERD смоделируй, чтобы понять как будет работать твоя БД.

у frienship идет many to many к юзер, если конечно ничего не путаю.

Optional one-to-many. У 1 пользователя может быть много друзей, но может и вообще не быть.

Сообщение изменено: K1sa (04 декабря 2010 - 21:06 )

• Наверх
• 

Отправлено 04 декабря 2010 - 22:13

K1sa,
а ну да, че-то поздапарился Один ко многим

P.S. Ну теоретически, только теоретически можно создать БД вообще с одной ячейкой, но это извращение %).
Если все же интересует. То подумай об ХМЛ.

Верхний нод - юзер, у юзера атрибуты типа новости, друзья, и все такое. И скрипт загружает из базы эту ячейку обрабатывает и через какой-нить rowmapper преобразует все в нормальный вид, но это все...мсье знает толк в извращениях..
P.P.S. трололо ))

• Наверх
• 

Отправлено 04 декабря 2010 - 22:18

JakeTheFIsh,
угу и для полного счастья еще придумать сверхгениальный алгоритм сериализации/десериализации объектов со сжатием данных для работы с одной этой ячейкой в базе данных

Сообщение изменено: Mr. Positive (04 декабря 2010 - 22:20 )

• Наверх
• 

Отправлено 04 декабря 2010 - 22:30

• Наверх
• 

Отправлено 04 декабря 2010 - 22:38

• Наверх
• 

Отправлено 04 декабря 2010 - 22:43

• Наверх
• 

Отправлено 04 декабря 2010 - 22:45

• Наверх
• 

Отправлено 04 декабря 2010 - 22:51

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

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

В общем не понятно чего ты хочешь

• Наверх
• 

Отправлено 04 декабря 2010 - 22:52

Mr. Positive, ооо...а блекджек и шлюхи будут? %)

K1sa, Я рассуждаю из простого желания потрещать о чем-то отвлеченном ))

Я как-то другу сказал, что читал спор между оракл и постгре. Смысл том что одна база круче другой из-за того что одна может выдержать ну допустим 10 миллионов транзакций, а другая только 9млн. На что он процитировал персонажа из СССР: ядерный потенциал США сможет уничтожить Землю 30 раз, а яд. пот. СССР только 26. Какой эпик...
Суть этого всего в том, что "идеального" способа нет, оптимальность покажет только процесс использования...чего в принципе у этих проектиков не будет ;)

Ну если вы настаиваете так, то : хранение списка друзей вообще это массив. Сама таблица скорей всего будет иметь 3 ячейки ид ид1 ид2. Причем при sql запросе проверяется оба варианта то бишь проверяется ид1 ид2 и наоборот ид2 ид1. Вроде того. Можно конечно придумать что-то поинтересней, но зачем

• Наверх
• 

Отправлено 04 декабря 2010 - 23:04

| ID | ID_1 | ID_2 |
 ------------------
| 1  | uid1 | uid2 |
| 2  | uid2 | uid1 |

• Наверх
• 

Отправлено 04 декабря 2010 - 23:09

• Наверх
• 

Отправлено 04 декабря 2010 - 23:11

• Наверх
• 

Отправлено 04 декабря 2010 - 23:23

• Наверх
• 

Отправлено 04 декабря 2010 - 23:24

Я понял, только для этой проверки не нужна третья ячейка то

• Наверх
• 

Отправлено 05 декабря 2010 - 01:37

• Наверх
• 

Отправлено 05 декабря 2010 - 02:57

SELECT a.ID, b.имя, b.фамилия FROM друзья a, пользователи b WHERE ID_дружбы IN (SELECT ID_дружбы FROM друзья  WHERE ID = 'ID_залогинено_юзера') AND a.ID != 'ID_залогинено_юзера' AND a.ID = b.ID

• Наверх
• 

Отправлено 05 декабря 2010 - 14:56

• Наверх
• 

Отправлено 05 декабря 2010 - 16:57

• Наверх
• 

Отправлено 05 декабря 2010 - 17:05

K1sa, Tasmanian Fox, Моё кунгфу круче вашего

• Наверх
• 

Отправлено 05 декабря 2010 - 18:37

И не нужно боятся строить большие запросы, это наоборот плюс.
Тебе придется 2 раза обращаться к базе, чтобы получить результат с дружбой пользователей.

По поводу первой мысли - поддерживаю полностью, большие запросы, не требующие осуществления каких-либо дополнительных запросов, рулят. Насчёт второй идеи - можно выкрутиться через UNION, объединяющий 2 запроса в один, при условии, что названия столбцов совпадают.
Для примера. Цель: выцепить ИД, имена и фамилии твоих друзей - как тех, кто тебя добавил, так и тех, кого добавил ты:

SELECT user.id, user.name, user.surname FROM user RIGHT JOIN
friendship ON user.id = friendship.subject WHERE friendship.accept = '1'
AND friendship.object = '$user->id'
UNION
SELECT user.id, user.name, user.surname FROM user RIGHT JOIN
friendship ON user.id = friendship.object WHERE friendship.accept = '1'
AND friendship.subject = '$user->id'

Куски запросов можно также сортировать. Вот например отсортированные по дате в порядке убывания последние 20 новостей друзей:

SELECT news.id, news.content, user.name, user.surname, user.id as uid, news.date AS date FROM news RIGHT JOIN user ON news.author = user.id
LEFT JOIN friendship ON friendship.object = user.id WHERE friendship.subject = $uid
AND friendship.accept = '1' AND news.content != 'NULL'
UNION
SELECT news.id, news.content, user.name, user.surname, user.id as uid, news.date AS date FROM news RIGHT JOIN user ON news.author = user.id
LEFT JOIN friendship ON friendship.subject = user.id WHERE friendship.object = $uid
AND friendship.accept = '1'  AND news.content != 'NULL'
ORDER BY date DESC LIMIT 20

Моё кунгфу круче вашего

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

• Наверх
• 

Отправлено 11 декабря 2010 - 20:07

• Наверх
•