а зачем юнионы между ними?

а зачем юнионы между ними?

Агрегатные запросы, статистику считать, что-то такое.

угу

Народ помогите плз!

а какая связь между орм и статистикой?

работа на разных базах реализуется через конфигурацию энтити менеджера(ов). статистика - не головняк доктрины и аще общего бэкэнда

а какая связь между орм и статистикой?

DQL оперирует именами сущностей

работа на разных базах реализуется через конфигурацию энтити менеджера(ов). статистика - не головняк доктрины и аще общего бэкэнда

Вот доктринофилы постоянно произносят какой-то такой ответ: "доктрина для этого не предназначена" :)

для этого в принципе ни что не предназначено

Голый SQL прекрасно предназначен.

э...для olap не предназначена, да

Ну или, как я выше написал, yii2 по крайней мере никак не препятствует, позволяя в рантайме подставлять в класс любой префикс схемы.

если у вас 1 и тот же пользователь имеет доступ во все базы, то это проблема вашей реализации. sql позволяет строить запросы сквозные, но их в жизни увидешь не часто

мухи отдельно, котлеты (статистика) отдельно

любая орм... если ты приделал орм пофиг какую к olap профилю, то... ну... ты не прав ;)

и да, siteid рулит

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

и в конце контов кто вам мешает из доктрины получить объект пдо и херануть такой же нативный sql запрос?

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

Репорты так вообще одна из любимых тем.

и в конце контов кто вам мешает из доктрины получить объект пдо и херануть такой же нативный sql запрос?

Ну то есть это эквивалентно выкидыванию доктрины.

какая задача, такое и решение

репорты прекрасно живут отдельно рядышком

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

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

Ну не всем жу CRUD сайтики клепать :(

ну, видимо, вы из числа тех, кто круд клепал всё время

Понятно что в тривальных случаях все ORM движки работают примерно хорошо.

и да, siteid рулит

бесплатная подсказка пролетала

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

кто-то не хочет разделять модели на write and read :)

siteid не рулит. Это будет вмешивание в структуру абсолютно всех таблиц и куча доп условий в запросах. Кроме того, если какому-то клиенту понадобится свое эксклюзивное изменение в схеме, то облом.

тогда глупый вопрос: почему sql?

siteid не рулит. Это будет вмешивание в структуру абсолютно всех таблиц и куча доп условий в запросах. Кроме того, если какому-то клиенту понадобится свое эксклюзивное изменение в схеме, то облом.

json field :)

кто-то не хочет разделять модели на write and read :)

А что надо сделать? Как это поможет?

просто в вашем "эксклюзиве" логика страдает: сущность итак будет изменена с кучей ифов)

siteid не рулит. Это будет вмешивание в структуру абсолютно всех таблиц и куча доп условий в запросах. Кроме того, если какому-то клиенту понадобится свое эксклюзивное изменение в схеме, то облом.

а доктрина потом намапит разнородну структуру одной и той же таблицы?

какую к чёртовой матери разнородную структуру?

мы правда про sql сейчас говорим?

json поле - это круто, но...

я не понял комментарий про "...эксклюзивное измнение в схеме.."

никто не понял

json поле - это круто, но...

но...?

но с таком случае проблема решается не с того конца

понятно что это уже попахивает nosql

в общем щадача - говнокод ;) решается элементарно написанием обработчика события loadClassMetadata скорее всего

что и следовало ожидать

А тут кто-то вообще работал с мультитенантными системами? )

Было бы интересно послушать как оно на практике у него делается.

И как работают сайты наподобие wix, insales, tilda

я бы шел siteId. Поднобные систмы априори не предполагают "кастомное изменение схемы"

Хм ну ладно. В морг, значит в морг :\

работали. Так же изолировано всё расположено. Но при этом нет 1й вундервафли, которая знает всё и обо всех. Каждый кусок собирает свою статистику и в конце агрегируется. И, да, схема у всех одинаковая.

а фильтры по siteId в доктрине можно вынести в фильтры и автоматически применять ко всем запросам...

> Так же изолировано всё расположено. А почему не siteId ?

вопрос размеров. Если что-то мелкое, или среднее - site_id наше всё

емнип эта задача решается через обработчик события loadClassMetadata

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

в шардировании, в принципе, всегда есть смысл :)

это не шардирование, по факту

ну если применить логику на имя схемы

то почему нет

отдельная схема на отдельный сайт - как раз шардирование

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

отдельная схема на отдельный сайт - как раз шардирование

неа

отдельная схема на отдельный сайт - как раз шардирование

это не шардинг

а зачем реплика, вынеси их на отдельый сервер ;)

вот объясните пожалуйста тогда, почему это не шардирование

потом схему реплицировать - это все-равно логическое реплицирование будет

ERROR: S client not available

да впринципе шардирование в каком то смысле. Смотря как термин трактовать.

Несколько мест с одинаковой схемой и разными данными - шарды и есть.

лучше это называть партицированием ;) что бы не путать вертикальный и горизонтальный шардинг

okay :(

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

хотя скорее шардирование это горизонтальное партицирование ;) в общем есть определенная путаница

по теме - это должно быть реализуемо через loadClassMetadata event, даже похожий вопрос на SO нашелся https://stackoverflow.com/questions/17134855/programmatically-modify-tables-schema-name-in-doctrine2

по теме - это должно быть реализуемо через loadClassMetadata event, даже похожий вопрос на SO нашелся https://stackoverflow.com/questions/17134855/programmatically-modify-tables-schema-name-in-doctrine2

О, это лудший отвед пока во всей этой дискассии )

таких уже 2 было)

но вообще апгрейд саас с апгрейдом схемы в случае мультисхемной архитектуры превращается в какую-то боль ;))

Ну а с siteId эксплуатация превращается в боль. Везде в запросах надо учитывать фильтр по нему.

с фильтрами как раз попроще будет)

Ну а с siteId эксплуатация превращается в боль. Везде в запросах надо учитывать фильтр по нему.

глобальный фильтр

Ну и отдельного клиента не забекапишь.

а какой юзкейс для бэкапа отдельного клиента?

да это логичнее в т.ч. и с точки зрения доступа, аудита, разделения рисков и т.д.

чем не угодил инкрементальный бэкап?

тем, что восстановление *данных* одного пользователя может затрагивать всех остальных

я не понял комментарий про "...эксклюзивное измнение в схеме.."

Поясню. Я имел в виду, например мы захотели для половины клиентов выкатить какой-то апдейт движка с измененными структурами. В случае мультисхемы мы делаем копию всех сущностей, редактируем их и привязывем к новым клиентам. При этом старые клиенты спокойно себе работают на старой кодовой базе.

это сраный ад будет

а какой юзкейс для бэкапа отдельного клиента?

Почти в любом саасе есть много маленьких клиентов и есть немного жирных важных клиентов, с которыми все возятся и облизывают их :)

ну нет же, А/В никто не отменял, а писать код, который будет поддерживать разные версии И уметь переключаться между ними - вот ад

а/б тут рядом не стоял даже

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

ну и раздели физически толстых и тонких ;) и на тонких эксперементируй ;)

когда речь о данных разных клиентов (saas), хранить все в одной куче черевато

из другой оперы пример - один клиент создает большую нагрузку, затрагивая всех остальных. Без отдельной схемы отделить его на другой сервер будет ой каким гемором.

когда речь о данных разных клиентов (saas), хранить все в одной куче черевато

+

оки, а условия в mysqldump кто-то отменил?)

из другой оперы пример - один клиент создает большую нагрузку, затрагивая всех остальных. Без отдельной схемы отделить его на другой сервер будет ой каким гемором.

делаешь полную репликацию и потом грохаешь ненужные siteId :)

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