Как вы будите разруливать кейс когда удалили пользователя, а он у кого-то в друзьях был? Перебирать всех остальных пользователей?
Как будите проверять что один пользователь один раз в друзьях у другого пользователя?
Колличество друзей вы будите считать по колличеству записей в массиве, но на самом деле их будет другое колличество.
Плюс если брать кейс когда будет подтверждение добавления в друзья, то его можно будет решить добавлением одно boolean поля.
И опять-же у вас будет время добавления в друзья, а это возможность для сортировки по недавно добаленным друзьям.
Таблица с ID много места не займет, с индексами это будет работать очень быстро, и если у вас будет составной уникальный индекс, то на уровне БД то на уровне БД вы не сможете подружить двух пользователей больше 2х раз. https://www.postgresql.org/docs/9.4/static/indexes...
Sergey750il: да получилось, и вполне успешно.
Дело в том что молодые и не опытные бойцы, не кому не нужны, а тем более на удалёнке. Когда человек сидит рядом, его всегда можно проконтролировать и понять. Что не скажешь об удаленном сотруднике.
Павел Грудинкин: Ну тут мне кажеться без расписания не обойтись.
К примеру каждый час отбираем пользователей у которых осталось меньше 1 часа до конца подписки, и пробуем им её продлить, со всеми вытикающими последствиями.
Когда у вас пользователь переходит с директа то переходит по такой ссылке с параметрами, и они установленны. GET параметры это часть url запрашиваемой страницы.
Имя телефон и прочее это инпуты, их вводит пользователь.
Из готовой верстки вы должны усваивать приёмы, а не по каждому свойству лезть гуглить что делает. Это как учить испанский по первой попавшейся книге и переводить незнакомые слова в переводчике. В общем смысл возможно понятен будет, но есть вероятность не полного понимания.
Да и не думаю что сильно спасет лицензия.
Как только разработчик сделает git clone код уже ушел.
Вы даже не узнаете когда этот код появится в другом репозитории.
