Size: a a a

2021 January 06

V

Vasily in phpGeeks
23687s Lomanu4
ну хоть примерно ясен вопрос?
если даже гугл отказал, то это попадос
источник

Y

Yegor in phpGeeks
23687s Lomanu4
ну хоть примерно ясен вопрос?
нет))
источник

ЕА

Егор Андреевич... in phpGeeks
Aleksey Potapenko
Здрастье. У меня вопрос есть. В фейсбуке и в вконтакте есть "списки друзей", в один список можно добавить дохрена друзей, возможно там даже нет лимита(я 1100 добавил на фейсбуке). И мне интересно как они хранят эти списки. Может быть есть join таблица, где в одном столбце ID списка, а в другом ID друга. Или может быть есть таблица, где в одной записи(row) находится вся информация о списке, то есть id списка, имя списка и id всех друзей добавленных в этот список, разделённых через запятую? Как вы думаете? Просто в любом случае получается жесть. Если, например, в списке 1000 друзей, то это либо 1000 новых записей в join таблице, либо очень большая запись в БД.
Хранить как угодно можно, от этого просто зависит количество ресурсов, которые будут требоваться.

В классических SQL бд можно хранить инфу, которую надо анализировать и совмещать через джойны например, но в твоём примере совсем не обязательно хранить это в SQL базах, для этого скорее keyvalue хранилища больше подходят
источник

AP

Aleksey Potapenko in phpGeeks
Егор Андреевич
Хранить как угодно можно, от этого просто зависит количество ресурсов, которые будут требоваться.

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

AS

Alexey Shatunov in phpGeeks
Vasily
если даже гугл отказал, то это попадос
можно в яндекс обратиться 🤗
источник

ЕА

Егор Андреевич... in phpGeeks
Aleksey Potapenko
Здрастье. У меня вопрос есть. В фейсбуке и в вконтакте есть "списки друзей", в один список можно добавить дохрена друзей, возможно там даже нет лимита(я 1100 добавил на фейсбуке). И мне интересно как они хранят эти списки. Может быть есть join таблица, где в одном столбце ID списка, а в другом ID друга. Или может быть есть таблица, где в одной записи(row) находится вся информация о списке, то есть id списка, имя списка и id всех друзей добавленных в этот список, разделённых через запятую? Как вы думаете? Просто в любом случае получается жесть. Если, например, в списке 1000 друзей, то это либо 1000 новых записей в join таблице, либо очень большая запись в БД.
Ну и нужно понимать, что нет никакой разницы между фейсбуком и новымУбийцейФейсбука, если предусмотрено горизонтальное масштабирование, просто другое количество ресурсов и приколов в инфраструктуре
источник
2021 January 07

S

STEM in phpGeeks
Привет. Под утро возникла у меня проблема, не могу никак придумать варианты решения, пдскажите что-нибудь, пожалуйста)
Есть абстрактный класс AbstractClass, у него есть свойство $prop, в котором я хочу хранить классы наследумые от OtherAbstractClass.
Я не могу оставить в абстрактном классе свойство без типа, но при этом, если я указываю тип OtherAbstractClass у свойства, а потом пытаюсь в новом классе переопределить его указав тип конкретного класса, то выходит ошибка compile error…
Я пока вижу только вариант указывать конкретный класс в phpdoc, но чет мне вообще это не нравится(
источник

KN

Kirill Nesmeyanov in phpGeeks
потому что null
источник

KN

Kirill Nesmeyanov in phpGeeks
?OtherAbstractClass $prop = null
источник

AL

Alexander Lisachenko in phpGeeks
STEM
Привет. Под утро возникла у меня проблема, не могу никак придумать варианты решения, пдскажите что-нибудь, пожалуйста)
Есть абстрактный класс AbstractClass, у него есть свойство $prop, в котором я хочу хранить классы наследумые от OtherAbstractClass.
Я не могу оставить в абстрактном классе свойство без типа, но при этом, если я указываю тип OtherAbstractClass у свойства, а потом пытаюсь в новом классе переопределить его указав тип конкретного класса, то выходит ошибка compile error…
Я пока вижу только вариант указывать конкретный класс в phpdoc, но чет мне вообще это не нравится(
PHP не поддерживает ковариантность для свойств, то есть нельзя указать в родителе более широкий тип и сужать его в потомках. Типичное решение - в родителе указать базовый широкий тип в самом свойстве, а в дочернем классе добавить в док-блок класса @property с более узким типом.
источник

AL

Alexander Lisachenko in phpGeeks
Но вообще наследование - зло, а если вам нужно знать конкретный тип, то это ещё и LSP будет нарушать. Возможно, имеет смысл вообще разрубить такие классы и не делать наследования вообще.

Подозреваю, что это ORM самописная и вам нужны типы чтобы знать конкретные свойства?
источник

G

Gearonix in phpGeeks
ребят, не подскажите как спроектировать базу данных для мессенжера? типо таблицы: комнаты, юзеры, сообщения
источник

СГ

Салман Габаев... in phpGeeks
Всем доброго времени суток, народ подскажите пожалуйста, есть задача создать сервис авторизации а так как у меня в этом нету опыта мне нужно понять что это и как это работает и про возможные архитектурные решения, можете посоветовать какую нибудь статью
источник

СГ

Салман Габаев... in phpGeeks
В инете что то не получается найти
источник

K🔪

Killer 🔪 in phpGeeks
источник

D

Dimon in phpGeeks
Тут плюс
источник

D

Dimon in phpGeeks
У Русакова хорошие статьи по пыхе, на базовом уровне, после этого копай в гугле для расширения возможности кода
источник

K🔪

Killer 🔪 in phpGeeks
у него есть курс для трёх уровней
источник

LS

Luka Solncev in phpGeeks
Кто то видел бота для телеграмма, чтобы был доступ к базе данных с функциями php?
источник

K🔪

Killer 🔪 in phpGeeks
у меня такой
источник