то есть при енуме - альтер на добавление каждого флага, при компресед поле - 1 альтер на добавление новых 63-64 флагов

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

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

А кто нибудь graphQL реализовывал поверх ларки?

Привет. Я чёт туплю. Как хелпер в ларке называется. Который берет из ассоциативного масива по такому типу. $arr = [ 'a' => [ 'b' => [ 'c' => 'a' ] ] ] method($arr, 'a.b.c')

Привет. Я чёт туплю. Как хелпер в ларке называется. Который берет из ассоциативного масива по такому типу. $arr = [ 'a' => [ 'b' => [ 'c' => 'a' ] ] ] method($arr, 'a.b.c')

вроде как можно нагулилть через EAV и SKU

Как я почитал, более целесообразно использовать flat table или вообще переехать на Mongo, может у вас есть какое-то мнение или опыт по этому поводу?

Как я почитал, более целесообразно использовать flat table или вообще переехать на Mongo, может у вас есть какое-то мнение или опыт по этому поводу?

Как я почитал, более целесообразно использовать flat table или вообще переехать на Mongo, может у вас есть какое-то мнение или опыт по этому поводу?

монга вроде как там заходит, но я с ней опыта не имел (

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

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

Лучше за постгрес почитать. Или джсончики в мускуле. Монганенужна (с)

Лучше за постгрес почитать. Или джсончики в мускуле. Монганенужна (с)

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

нужна, для других задач

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

то что это единственный сценарий из твоей практики, не означает, что это единственный сценарий в принципе)

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

вот 2 хороших профита монги. но и это лечится :)

Какого именно дублирования?

в реляционных базах от него можно избавится нормализацией

да это не профит вовсе

Эта медаль о двух сторонах

пример?

пример?

скорость выборки

иногда нормализация - избыточна

а когда тебе надо что то изменить?

да, но в большенстве случаев она норм работает

есть контроль на уровне БД, есть контроль на уровне кода.

допустим у нас есть товар с цветом синий, у нас этих товаров 15000, а теперь мы хотим цвет синий переименовать в синеватый

потому что, опять же, нормализация - избыточна зачастую

т.е. когда ты у юзера пишешь город, ты это не нормализуешь? все в одной таблице?

Лучше за постгрес почитать. Или джсончики в мускуле. Монганенужна (с)

грубо говоря есть профиль profile: id, lastname, firstname а может быть id, lastnameId, firstnameId

Немного не понял с постгресом, вроде же тоже реаляционая СУБД или я где-то что-то упускаю?

она помощнее будет, и встроенные типы массив и джсон решат 75% твоих проблем

Как по мне, вообще глупо сравнивать реляционки и json-based нереляционки

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

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

Может и так (хотя я, например, не согласен насчет того, что реляционки - идеальны. Это вовсе не так), но есть кейсы применения и монги тоже 🤷‍♂️