увидел и сглючил на секунду, как я еще раз добавился)
Вот так вот бывает)
Yan
Ян
2^7
Anonymous
128
Александр
2 « 7 , такую цифру испортил
Toly
Если вас так заботит эта цифра, кто-нибудь один может покинуть сообщество 😆
SiZE
лучше следующую степень
Sergey
нормальное число, в 6-ричной системе исчесления записывается как 333
Toly
А в 129 ричной - 10
⌚️
Всем привет. Скажите как можно реализовать 2 обратный связь в одном проекта с yii2 (или 2ой в виде виджет в другом страница). 1 для связь с админом а 2 для отправка письмо по другом вопросу на другой почта.
⌚️
Заранее спасибо за совет
Anatole
Вам бы ТЗ писать. Слог хороший...
Иван
Это видимо и есть ТЗ
Dmitriy
Иван
"Как можно реализовать" это скорее всего что-то очень близкое к "сделайте всё за меня" или "дайте инструкцию по которой не шарящий в программировании человек всё сделает"
Antony
Кто на yii2 реализовывал комментарии? Ткните как лучше хранить дерево, с максимальной вложенностью 5-го уровня
Ян
https://github.com/yeesoft/yii2-comments
Ян
гугл yii2 nested comments
Antony
Ну я больше про то как лучше сделать в данном случае, nested sets, closure table итп.
Хочется узнать мнения, комментарии
Ян
думаю nested set лучше
Ян
он сложнее, но эффективнее
Ян
а closure table проще но с сортировками накладно
Ян
вообще было бы здорово под это юзать базу типа mongo
Ян
но йии в нее не умеет со всеми плюшками
Ян
зато ларка умеет
Ян
но это уже в другую группу)
Antony
Монго же но-sql? Можно подробнее про преимущества в данном случае?
Ну вроде к йии есть же коннекторы, хотя хз не работал.
Просто изначально есть уже йии, но в целом советы на чем реализовать комментарии будут полезны, ибо дальше возможно уйдем с йии.
Я читал что pqsql может из коробки деревья, но как я понял там в основе materialized path.
Dmitriy
Преимущества nosql ?
Antony
Преимущества nosql ?
Конкретно преимущества монго для древовидных комментариев с уровнем вложенности не более (5, хотя можно заменить на любое конечное N)
Ян
Преимущества nosql ?
это вообще отдельная огромная категория баз данные, у которых НЕ sql синтаксис, у них у всех свои преимущества
Ян
Монго же но-sql? Можно подробнее про преимущества в данном случае?
Ну вроде к йии есть же коннекторы, хотя хз не работал.
Просто изначально есть уже йии, но в целом советы на чем реализовать комментарии будут полезны, ибо дальше возможно уйдем с йии.
Я читал что pqsql может из коробки деревья, но как я понял там в основе materialized path.
в пг дерево реализуется так же как и в любой табличной бд, грубо говоря костылями.
Ян
Монго же но-sql? Можно подробнее про преимущества в данном случае?
Ну вроде к йии есть же коннекторы, хотя хз не работал.
Просто изначально есть уже йии, но в целом советы на чем реализовать комментарии будут полезны, ибо дальше возможно уйдем с йии.
Я читал что pqsql может из коробки деревья, но как я понял там в основе materialized path.
монго умеет хранить любую структуру с довольно быстрым доступом
Ян
монго умеет хранить любую структуру с довольно быстрым доступом
а коннектор йии2 не умеет сохранять вложеные объекты
Ян
в ларке может
Dan
А мы сейчас поднимаем yii2 advanced для рест апи
Ян
потому в йии монго мало полезна, от таблиц отличается только возможностью хранить простой индексированый массив
Dan
Гы из коробки
Dan
Там конфиг на конфиге
Dmitriy
Конкретно преимущества монго для древовидных комментариев с уровнем вложенности не более (5, хотя можно заменить на любое конечное N)
Он не знаю, мы только сырые данные на nosql храним
Ян
для рест апи юзайте рест контроллер и все, ничего сложного
Dan
Вот пробуем
Dan
Dan
Ща базы грохнем лишние и миграцию сделаем
Dmitriy
yii2 advanced в чем прикол этого шаблона ?
Antony
Он не знаю, мы только сырые данные на nosql храним
Данные приходят от пользователя, помещаются в nosql, далее обработка и помещение в sql-хранилище? Я правильно понимаю?
В чем профит? Nosql быстрее на запись, sql для чтения?
Dan
а можно ваш чатик в список добавить? 😊
Dan
github.com/goq/telegram-list который
Antony
Dmitriy
Данные приходят от пользователя, помещаются в nosql, далее обработка и помещение в sql-хранилище? Я правильно понимаю?
В чем профит? Nosql быстрее на запись, sql для чтения?
да так. Ну данные могу поменятся, мы тупо все собираем. Не знаю но у нас носкл не в жился в качестве основного хранилище
Dan
😃
Dmitriy
Ян
yii2 advanced в чем прикол этого шаблона ?
фронтент для клиента, бэкэнд для админки, коммон для борохла
Dmitriy
фронтент для клиента, бэкэнд для админки, коммон для борохла
у них же у всех разные точки входа
Dmitriy
это же минус
Ян
Данные приходят от пользователя, помещаются в nosql, далее обработка и помещение в sql-хранилище? Я правильно понимаю?
В чем профит? Nosql быстрее на запись, sql для чтения?
nosql вагон разных. редис, монго, кауч и еще десятки если не сотни
Antony
да так. Ну данные могу поменятся, мы тупо все собираем. Не знаю но у нас носкл не в жился в качестве основного хранилище
Ну просто применимо к моим требованиям данная модель навряд ли подойдет, ибо комментарии не редактируемые, не вижу смысла.
Пытаюсь понять в чем профит писать дерево комментариев в nosql по совету Яна
Antony
nosql вагон разных. редис, монго, кауч и еще десятки если не сотни
Я знаю что их много.
Профит для комментариев какой?
И если есть профит, можно тогда замутить чисто nosql под комменты?
Dmitriy
github.com/goq/telegram-list который
у меня есть бот. который собирает стату, я хочу сделать бейджики. как на гитхабе но с кол-вом человек в чате. Можно я потом их добавлю к тебе ?
Ян
Ну просто применимо к моим требованиям данная модель навряд ли подойдет, ибо комментарии не редактируемые, не вижу смысла.
Пытаюсь понять в чем профит писать дерево комментариев в nosql по совету Яна
в том что оно будет деревом. кладешь потомка внутырь родителя, все по порядку.
Dmitriy
Dan
у меня есть бот. который собирает стату, я хочу сделать бейджики. как на гитхабе но с кол-вом человек в чате. Можно я потом их добавлю к тебе ?
да, конечно 😊 а это ты автоматом хочешь делать? или как?
Dmitriy
да, конечно 😊 а это ты автоматом хочешь делать? или как?
да автоматом. пишу api для этого на след недели будет беджики
Antony
Как я понимаю в nosql удобно хранить неструктурированные данные. Т.е. если нужно часто менять структуру. Это как плюс, так и минус.
Я на одном проекте костыльно писал json-данные в файл и в бд писал ссылку на него (это помимо остальных структурированых данных)
Dmitriy
api/ зачем? он должен быть в урле. разруливает то все один индекс
хм. структуру advanteda видел ? там нет единой точки входа. там их минимум 2
Ян
в том что оно будет деревом. кладешь потомка внутырь родителя, все по порядку.
я не говорю что это решение лучше того. я говорю что с точки зрения архитектуры оно самое ровное, т.к. дерево хранится как дерево
Ян
Как я понимаю в nosql удобно хранить неструктурированные данные. Т.е. если нужно часто менять структуру. Это как плюс, так и минус.
Я на одном проекте костыльно писал json-данные в файл и в бд писал ссылку на него (это помимо остальных структурированых данных)
именно. но станет это злом или нет уже от тебя зависит. у тебя в моделях будут явно объявлены поля. миграции не нужны. структуру твоих данных в базе должна определять твоя модель данных
Dmitriy
Как я понимаю в nosql удобно хранить неструктурированные данные. Т.е. если нужно часто менять структуру. Это как плюс, так и минус.
Я на одном проекте костыльно писал json-данные в файл и в бд писал ссылку на него (это помимо остальных структурированых данных)
да правильно. У нас или сырые данные или логи. но монга у нас первариват по пол терабайта данных в сутки
Antony
я не говорю что это решение лучше того. я говорю что с точки зрения архитектуры оно самое ровное, т.к. дерево хранится как дерево
Ну я понял. Это грубо говоря даст более наглядно структуру без необходимости строить дерево через запрос (или средствами php)
Ян
хм. структуру advanteda видел ? там нет единой точки входа. там их минимум 2
ну да. два ж приложения. а зачем плодить еще одну точку?