Мдя? А мне показалось, это ты наше тратишь ;)

А за свое я сам в ответе ;)

У тебя колонкофобия?

Мдя? А мне показалось, это ты наше тратишь ;)

Если ты за свое время в ответе, как же так получилось, что я его трачу?

Вернее, строкофобия

Вернее, строкофобия

Вот это ближе

У тебя колонкофобия?

Вопрософилия

Симфони. Доктриновская сущность User. Как лучше всего реализовать связь "друзья", чтобы при это были удовлетворены следующие условия: 1) Изестно кто кому отправил запрос (т.е. при необходимости, админ сможет это выяснить) 2) Дружбу необходимо подтверждать на "другой" стороне. 3) Если другая сторона отклонила запрос на дружбу, второй раз запрос отправлять нельзя. Запрос на дружбу превращается в подписку (как вконтакте)

Есть entity FriendshipRequest которая имеет свойства user1, user2, isFriendshipAccepted Логика "дружбы" реализуется отдельным сервисом в которой прописываются все 3 правила Entity User может иметь связь с FriendshipRequest, а может не иметь

Если ты за свое время в ответе, как же так получилось, что я его трачу?

опять 25... вопросы уже научился задавать, осталось ещё научиться уважать чужое время и мнение. по факту - написали верный запрос, рассказали что нужно использовать GROUP BY, без чтения теории РСУБД рассказали что вариант с 1 строкой плох, @miksir аж подарил тебе своего времени на пару $$$. спасибо говорить не учили?

bool лишнее

по сути дружба это взаимный фоловинг

то есть если они друг друга фоловят, то значит они дружат

а с bool это уже денормализация идет)

статус отношений можно хранить в int в одной таблице

1 - послан запрос на дружбу, 2 - запрос принят, 3 - запрос отклонен

и в обратную сторону такая же связь

И тогда все друзья человека выбираются 1 простым запросом из 1 таблицы

Эта проблема с логикой присутствует и в других вариантах таблиц, это все должно контролироваться на уровне приложения, или составного констрейнта бд

1 - послан запрос на дружбу, 2 - запрос принят, 3 - запрос отклонен

4 - удалил из друзей, если передобавлять нельзя.

Эта проблема с логикой присутствует и в других вариантах таблиц, это все должно контролироваться на уровне приложения, или составного констрейнта бд

Ты предлагаешь на всё-провсё иметь одну таблицу

Ты предлагаешь на всё-провсё иметь одну таблицу

нет, для "дружбы" нужна отдельная таблица.

Ты предлагаешь на всё-провсё иметь одну таблицу

Да именно так

Господа, что скажете про JSON-RPC ? Это модно или есть что-то лучше? Какие библиотеки и бандлы юзать?

Да именно так

То есть смотри, пример последовательности: 1) Павел отправляет запрос Максиму 2) В таблице появляется запись павел | максим | 1 3) Максим подтверждает дружбу 4) В тааблице изменяется статус и добавляется новая строка павел | максим | 2 максим | павел | 2

Так?

да

А зачем второй троке "статус"?

2 в данном случае

для упрощения запросов

не слишком ли избыточно?! на одну "дружбу" две записи в базе

Чтобы получить друзей пользователя, надо й простейший запрос ... WHERE user_id = 'максим' AND status = 2

не слишком ли избыточно?! на одну "дружбу" две записи в базе

Не слишком, это плата за несимметричность связи.

не слишком ли избыточно?! на одну "дружбу" две записи в базе

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

Да я именно такой костыль и делал в 2010, потом долго плевался что приходится делать извращенные запросы с UNION

сначала доставать тех кого я добавил, потом тех кто добавил меня.

сначала доставать тех кого я добавил, потом тех кто добавил меня.

А у тебя там что происходило, если человек отклонял запрос? Второй раз его прислать было нельзя?

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

И тогда нельзя уже будет вставить новую запись.

И тогда нельзя уже будет вставить новую запись.

Ну да, в принципе такая таблица охватывает все что мне необходимо. Спасибо

так и сделаю

Господа, что скажете про JSON-RPC ? Это модно или есть что-то лучше? Какие библиотеки и бандлы юзать?

RPC - это вчерашний день! все сейчас пишут REST hypermedia

hateoas и вот это все?

Не слишком, это плата за несимметричность связи.

нормальная форма? нет, не слышали :)

ага, вот это вот все

нормальная форма? нет, не слышали :)

А где там ненормальная? Там все нормализовано ;)

И при этом в одной таблице

https://ru.wikipedia.org/wiki/Пятая_нормальная_форма

Это не тот случай. В данном случае первичным ключом является пара (me_id, friend_id) а status функционально зависим от него, и декомпозиция тут невозможна

Ну или я бы с удовольствием посмотрел как это еще нормализуют :)

зачем ?

Умнож стоимость часа на число часов, вот и оценка

Лучше бы в сторону битрикса смотрели при таких условиях. имхо. разработчиков от джунов до матерых профи - пруд пруди. Для заказчика намного удобнее . Админка, эрмитаж - все порадует. P.S> Предвижу ругать в сторону битрикса, но обратите внимание, в замен чего я его предлагаю))

Магазин на битрикс легче поддерживать и продавать заказчику. Из коробки есть столько всего, что даже серьезный кодер на фраемворке на сделает за пару месяцев, а ободйется куда дороже. Главный минус битрикса - говнокод в отличии от фраемворков. Как разработчик, не получаю удовольствия от работы с ним) Однако, заказчика это ни как не касается. Для них, как я уже говорил, битрикс постарался на славу. Но если сравнить с ХостЦМС... Не думаю, что будет дешевле, тем-более значительно.. Если цель - максимум экономии - битрикс может себя не оправдать, да

Магазин на битрикс легче поддерживать и продавать заказчику. Из коробки есть столько всего, что даже серьезный кодер на фраемворке на сделает за пару месяцев, а ободйется куда дороже. Главный минус битрикса - говнокод в отличии от фраемворков. Как разработчик, не получаю удовольствия от работы с ним) Однако, заказчика это ни как не касается. Для них, как я уже говорил, битрикс постарался на славу. Но если сравнить с ХостЦМС... Не думаю, что будет дешевле, тем-более значительно.. Если цель - максимум экономии - битрикс может себя не оправдать, да

bullshit!

зависит от конкретного разраба в бОльшей степени

всё будет зависить от суммы ;)

посмотрите в сторону шаблонных решений на битрикс. может быть, и разраб не понадобится,если заказчику что то приглянется) P.S> просто посмотрите и приценитесь для начала

посмотрите в сторону шаблонных решений на битрикс. может быть, и разраб не понадобится,если заказчику что то приглянется) P.S> просто посмотрите и приценитесь для начала

wix будет ещё дешевле

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

не думаю что требования заказчика были достаточно изучены чтобы не обосновать ему разработку или наоборот отговорить от чего сложнее чем wix

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

мимо)

мимо)

выходит два перекупа :)

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

выходит два перекупа :)

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

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

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