Заранее спасибо за совет

Вам бы ТЗ писать. Слог хороший...

Это видимо и есть ТЗ

Всем привет. Скажите как можно реализовать 2 обратный связь в одном проекта с yii2 (или 2ой в виде виджет в другом страница). 1 для связь с админом а 2 для отправка письмо по другом вопросу на другой почта.

Больше похоже на тз. вопрос то в чем ?

"Как можно реализовать" это скорее всего что-то очень близкое к "сделайте всё за меня" или "дайте инструкцию по которой не шарящий в программировании человек всё сделает"

Кто на yii2 реализовывал комментарии? Ткните как лучше хранить дерево, с максимальной вложенностью 5-го уровня

https://github.com/yeesoft/yii2-comments

Кто на yii2 реализовывал комментарии? Ткните как лучше хранить дерево, с максимальной вложенностью 5-го уровня

.

гугл yii2 nested comments

Ну я больше про то как лучше сделать в данном случае, nested sets, closure table итп. Хочется узнать мнения, комментарии

думаю nested set лучше

он сложнее, но эффективнее

а closure table проще но с сортировками накладно

вообще было бы здорово под это юзать базу типа mongo

но йии в нее не умеет со всеми плюшками

зато ларка умеет

но это уже в другую группу)

Монго же но-sql? Можно подробнее про преимущества в данном случае? Ну вроде к йии есть же коннекторы, хотя хз не работал. Просто изначально есть уже йии, но в целом советы на чем реализовать комментарии будут полезны, ибо дальше возможно уйдем с йии. Я читал что pqsql может из коробки деревья, но как я понял там в основе materialized path.

Преимущества nosql ?

Преимущества nosql ?

Конкретно преимущества монго для древовидных комментариев с уровнем вложенности не более (5, хотя можно заменить на любое конечное N)

Преимущества nosql ?

это вообще отдельная огромная категория баз данные, у которых НЕ sql синтаксис, у них у всех свои преимущества

Монго же но-sql? Можно подробнее про преимущества в данном случае? Ну вроде к йии есть же коннекторы, хотя хз не работал. Просто изначально есть уже йии, но в целом советы на чем реализовать комментарии будут полезны, ибо дальше возможно уйдем с йии. Я читал что pqsql может из коробки деревья, но как я понял там в основе materialized path.

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

Монго же но-sql? Можно подробнее про преимущества в данном случае? Ну вроде к йии есть же коннекторы, хотя хз не работал. Просто изначально есть уже йии, но в целом советы на чем реализовать комментарии будут полезны, ибо дальше возможно уйдем с йии. Я читал что pqsql может из коробки деревья, но как я понял там в основе materialized path.

монго умеет хранить любую структуру с довольно быстрым доступом

монго умеет хранить любую структуру с довольно быстрым доступом

а коннектор йии2 не умеет сохранять вложеные объекты

в ларке может

А мы сейчас поднимаем yii2 advanced для рест апи

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

А мы сейчас поднимаем yii2 advanced для рест апи

что его поднимать то) он изкоробки работает)

Гы из коробки

Там конфиг на конфиге

Конкретно преимущества монго для древовидных комментариев с уровнем вложенности не более (5, хотя можно заменить на любое конечное N)

Он не знаю, мы только сырые данные на nosql храним

для рест апи юзайте рест контроллер и все, ничего сложного

Вот пробуем

Там конфиг на конфиге

доступ к базе, накатил миграшку, запустил index.php. готово

Ща базы грохнем лишние и миграцию сделаем

yii2 advanced в чем прикол этого шаблона ?

Он не знаю, мы только сырые данные на nosql храним

Данные приходят от пользователя, помещаются в nosql, далее обработка и помещение в sql-хранилище? Я правильно понимаю? В чем профит? Nosql быстрее на запись, sql для чтения?

а можно ваш чатик в список добавить? ?

github.com/goq/telegram-list который

github.com/goq/telegram-list который

У меня есть предложение . одно

А можно ссылку на пхп чат. Можно в лс

Данные приходят от пользователя, помещаются в nosql, далее обработка и помещение в sql-хранилище? Я правильно понимаю? В чем профит? Nosql быстрее на запись, sql для чтения?

да так. Ну данные могу поменятся, мы тупо все собираем. Не знаю но у нас носкл не в жился в качестве основного хранилище

А можно ссылку на пхп чат. Можно в лс

так в списке всё есть, вообще всё

?

да так. Ну данные могу поменятся, мы тупо все собираем. Не знаю но у нас носкл не в жился в качестве основного хранилище

я ща подробнее раскажу

yii2 advanced в чем прикол этого шаблона ?

фронтент для клиента, бэкэнд для админки, коммон для борохла

фронтент для клиента, бэкэнд для админки, коммон для борохла

у них же у всех разные точки входа

это же минус

Данные приходят от пользователя, помещаются в nosql, далее обработка и помещение в sql-хранилище? Я правильно понимаю? В чем профит? Nosql быстрее на запись, sql для чтения?

nosql вагон разных. редис, монго, кауч и еще десятки если не сотни

да так. Ну данные могу поменятся, мы тупо все собираем. Не знаю но у нас носкл не в жился в качестве основного хранилище

Ну просто применимо к моим требованиям данная модель навряд ли подойдет, ибо комментарии не редактируемые, не вижу смысла. Пытаюсь понять в чем профит писать дерево комментариев в nosql по совету Яна

nosql вагон разных. редис, монго, кауч и еще десятки если не сотни

Я знаю что их много. Профит для комментариев какой? И если есть профит, можно тогда замутить чисто nosql под комменты?

у них же у всех разные точки входа

всм?

github.com/goq/telegram-list который

у меня есть бот. который собирает стату, я хочу сделать бейджики. как на гитхабе но с кол-вом человек в чате. Можно я потом их добавлю к тебе ?

всм?

web/index.php api/index.php

Ну просто применимо к моим требованиям данная модель навряд ли подойдет, ибо комментарии не редактируемые, не вижу смысла. Пытаюсь понять в чем профит писать дерево комментариев в nosql по совету Яна

в том что оно будет деревом. кладешь потомка внутырь родителя, все по порядку.

Ну просто применимо к моим требованиям данная модель навряд ли подойдет, ибо комментарии не редактируемые, не вижу смысла. Пытаюсь понять в чем профит писать дерево комментариев в nosql по совету Яна

тогда профита нет. имхо

у меня есть бот. который собирает стату, я хочу сделать бейджики. как на гитхабе но с кол-вом человек в чате. Можно я потом их добавлю к тебе ?

да, конечно ? а это ты автоматом хочешь делать? или как?

web/index.php api/index.php

api/ зачем? он должен быть в урле. разруливает то все один индекс

да, конечно ? а это ты автоматом хочешь делать? или как?

да автоматом. пишу api для этого на след недели будет беджики

Как я понимаю в nosql удобно хранить неструктурированные данные. Т.е. если нужно часто менять структуру. Это как плюс, так и минус. Я на одном проекте костыльно писал json-данные в файл и в бд писал ссылку на него (это помимо остальных структурированых данных)

да автоматом. пишу api для этого на след недели будет беджики

вообще шикарно, круто будет ?

api/ зачем? он должен быть в урле. разруливает то все один индекс

хм. структуру advanteda видел ? там нет единой точки входа. там их минимум 2

в том что оно будет деревом. кладешь потомка внутырь родителя, все по порядку.

я не говорю что это решение лучше того. я говорю что с точки зрения архитектуры оно самое ровное, т.к. дерево хранится как дерево

ERROR: S client not available

Как я понимаю в nosql удобно хранить неструктурированные данные. Т.е. если нужно часто менять структуру. Это как плюс, так и минус. Я на одном проекте костыльно писал json-данные в файл и в бд писал ссылку на него (это помимо остальных структурированых данных)

именно. но станет это злом или нет уже от тебя зависит. у тебя в моделях будут явно объявлены поля. миграции не нужны. структуру твоих данных в базе должна определять твоя модель данных

Как я понимаю в nosql удобно хранить неструктурированные данные. Т.е. если нужно часто менять структуру. Это как плюс, так и минус. Я на одном проекте костыльно писал json-данные в файл и в бд писал ссылку на него (это помимо остальных структурированых данных)

да правильно. У нас или сырые данные или логи. но монга у нас первариват по пол терабайта данных в сутки

я не говорю что это решение лучше того. я говорю что с точки зрения архитектуры оно самое ровное, т.к. дерево хранится как дерево

Ну я понял. Это грубо говоря даст более наглядно структуру без необходимости строить дерево через запрос (или средствами php)

хм. структуру advanteda видел ? там нет единой точки входа. там их минимум 2

ну да. два ж приложения. а зачем плодить еще одну точку?

да правильно. У нас или сырые данные или логи. но монга у нас первариват по пол терабайта данных в сутки

А можно уточнения что за проект/специфика данных?

сделай себе backend под админку и api для апи. толькл не на уровне потрохов модуля, а на уровне самих модулей. /api/web/index.php

А можно уточнения что за проект/специфика данных?

Аналитика отельного сектора

именно. но станет это злом или нет уже от тебя зависит. у тебя в моделях будут явно объявлены поля. миграции не нужны. структуру твоих данных в базе должна определять твоя модель данных

А если меняется структура данных, то накладно ли будет менять структуру всех данных в nosql?

Аналитика отельного сектора

Букинг Экспедия еще 100 партнеров парсим

сделай себе backend под админку и api для апи. толькл не на уровне потрохов модуля, а на уровне самих модулей. /api/web/index.php

ненужно рушить структуру фреймворка. в нем уже есть альяс @webroot к примеру который смотрит в /web

А если меняется структура данных, то накладно ли будет менять структуру всех данных в nosql?

перебрать и поменять

если оно уложится в один запрос - сделай одним запросом

ну да. два ж приложения. а зачем плодить еще одну точку?

не ужели 2 разных точки это удобно ? я тупо беру стандартный шаблон и разделяю по модулям

Букинг Экспедия еще 100 партнеров парсим

Ну на такие объемы данных не рассчитываем. Тем более данные будут однородные

я не пробовал монго на йии. я нашел коннектор и всплакнул, все. с монго я работал на рельсах

не ужели 2 разных точки это удобно ? я тупо беру стандартный шаблон и разделяю по модулям

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

соблюдение разделения абстракции в йии практически фундаментально

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

ну api это не разное приложение . Ну А еще у меня есть страница с одной функцией. но на поддомене. не делать же для нее еще одно приложение

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

Разве модули для этого не предназначены ?

ну api это не разное приложение . Ну А еще у меня есть страница с одной функцией. но на поддомене. не делать же для нее еще одно приложение

апи это одно приложение, которое работает с общими можелями одним образом, админка другое приложение, которое работает по другому. а свою отдельную страницу можно и в приложении админки разместить, если оно расти не будут, а если в будущем планируется расширение, то 3е приложение

Разве модули для этого не предназначены ?

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

Как я понимаю в случае с апи должно быть админка, приложение апи и приложение для пользователей (к примеру, чтобы раздавать ючи для апи).

делаем по мануалу рест апи на yii, столкнулись с тем, что нет файла common/config/aliases.php это нормально?

или надо его создать?

Причем приложений для апи можно делать несколько (для версий/обратной совместимости). Я прав?

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

api это тоже кусок приложение. тем более он использует все те же entity

Причем приложений для апи можно делать несколько (для версий/обратной совместимости). Я прав?

да

делаем по мануалу рест апи на yii, столкнулись с тем, что нет файла common/config/aliases.php это нормально?

альясы в main лежат. просто кто-то вытащил его наружу

я вот роуты наружу вытаскиваю

апи это одно приложение, которое работает с общими можелями одним образом, админка другое приложение, которое работает по другому. а свою отдельную страницу можно и в приложении админки разместить, если оно расти не будут, а если в будущем планируется расширение, то 3е приложение

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