мульти-индексевый масив

[WMix]

А можно пример что выберет эта коснтрукция?

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

Разве такое с помощью итераторов/генераторов сделать нельзя?

вот и я, вроде простые вещи!

только то на что намекает grigory меня останавливает, "какой дебил это писал", иначе уже давно бы впиндюрил. ищу основания почему это не стоит делать, или как это делается правильно.

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

 

[grigori]

да понимаешь, который уже раз, в очередном проекте встречаюсь с такой ситуацией:
была когда-то задача сделать список, потом выборку по связанному справочнику, сделали key-value таблицу и фильтрацию в php,
постепенно каталог из 1000 товаров/объектов вырос до 30к, из 2х городов бизнес захотел охватить все, и время генерации страницы выросло пропорционально - до 7 сек., yandex определяет сайт как недоступный и опускает в выдаче.

Смотрю как тысячи записей подгружаются и фильтруются скриптом и понимаю что все это надо переписать полностью.
А вы хотите это формализовать и рекомендовать всем собаководам. Они ж так начнут писать вообще везде!

Недавно услышал во время собеседования: "мы при выкладке все внешние ключи УДАЛЯЕМ НАХРЕН! Разработчики yii это рекомендуют!" - и показывает ссылку, где Макаров написал, что в сильно нагруженной базе стоит удалить fk.

 

[AmdY]

постепенно каталог из 1000 товаров/объектов вырос до 30к, из 2х городов бизнес захотел охватить все

отлично, в случае с решением от WMix, нам нужно найти модель и сделать

-use ArrayQueryLanguage;
+use SqlQueryLanguage;

а всё потому, что он решил сделать врапер над операцией и тем самым заложил возможность манипуляций.

 

[grigori]

так я ж о чем - это новый QL, который никто не знает, это усложнит поддержку
в реальном коде "-use ArrayQueryLanguage;" часто означает полное переписывание

написать операции на AQL не будет намного быстрее, чем написать их же сразу на SQL

 

[WMix]

написать операции на AQL не будет намного быстрее, чем написать их же сразу на SQL

давайте возмем задачу с группированием позиций счета по категориям товаров. как не крути запрос к базе не изменится, а массив придется еще раз перелопачивать - в модельке появится метод (ну или перекрутка произойдет непосредственно во view), для второй группировки по странам еще один метод. эта задача возникает каждый раз когда есть табличная моделька. к примеру на отправку: по товарно для файла передачи, по таможеному коду для декларации, по упаковкам для погрузочного листа, по клиентно для f103 подобной формы и тд. запрос один и тотже а подкруток куча. далее вызов метода будет плодится либо по controllers либо по views. и каждый раз читая это придется напрягаться, пытаясь понять симантическую нагрузку этих 3х скрок (цикл + присвоение). при этом вызов $s->prepare(array('group'=>'country'), создаст эту проблему понимания всего 1 раз. далее как по накатаной

 

[AmdY]

написать операции на AQL не будет намного быстрее, чем написать их же сразу на SQL

обёртка типа linq как раз и является заменой sql, это query builder, который при работе с mysql разворачивается в sql, для коллекций организует циклы с ифами, для mongodb map reduce. в теории всё замечательно, а на практике достаточно пары методов, как предлагает WMix, а то каждый будет городить свой велосипед с контроллере-модели-вьюхе и не дай бог sql.

 

[WMix]

http://habrahabr.ru/post/259155/ я не единственный