Бизнес правила меняются на ходу. В своей практике нам приходится только подстраиваться под тех, кто оплачивает всю вечеринку. И если будут варианты из упереться и не делать так как что то не так в бизнесе или быстро под него подстроиться я предпочту последнее.
До библиотеки это на мой взгляд не дотягивает. Удобная функция обработки массива. Его выборки по ключу.
С утверждением про библиотеку соглашусь не надо. А от одной крайне важной я бы не отказался.
4 запроса. Но практика показывает, что наглядность дороже оптимизации. Правильно построенные ключи сводят к минимуму накладные расходы. Это согласуется с мнением что базам удобнее работать с двумя простыми запросами чем с одним сложным. По своей практике могу сказать что это действительно так. Любой самый сложный скрипт занимает доли секунд. Хотя и тут остаются маневры для оптимизации если интересно могу предложить один. Функция пересборки названа не зря. Один раз выгрузив массив мы можем его пересобирать многократно
Таблицы модель и марка связаны через третью таблицу модельный ряд (много ко многому) если допустить что у марки есть флагманская модель и ее вторичный ключ есть в таблице марки А у модели по каким то причинам потребовалось добавить ключ марки то связь уже не такая явная.
Я хотел бы в языке видеть нативную функцию Примеры таких функций работающих с подобными конструкциями я уже приводил array_column и array_map их появляется все больше, и думаю в ближайшее время что то подобное появится в обновлениях.
Давайте усложним задачу. Как поменяется ваш код если связь марки с моделью поменяется до много ко многому, через промежуточную таблицу Модульный ряд modeling (id, marks_id, models_id)
Это то, что очень органично вплетается в верстку, у любого верстальщика мало мальски привыкшего к подобным подходом не возникнет сложностей с версткой, полное отсутствие каких то зависимостей. Удалив кусок кода вы удаляете все связанные с ним запросы и переменные. И немного привыкнув к синтаксису наглядность примера просто зашкаливает. Видно к какой таблице мы обращаемся, по каким полям идет выборка и сразу указана переменная в которой будем искать свойство марок и моделей. При дальнейшей модификации связей в таблице (с одного ко многим до много ко многим) легким движением руки меняются структура выборки ничего не меняя в логике. Мы все также получим $marks и $models доступными для вывода в шаблон.
Если внутреннее ветвление кода условно назвать путями следования в коде то большая часть будет проходить одними и теми же путями. У каждого человека есть часто употребимые конструкции и методы. Такие же есть и у языков. К примеру foreach применяется чаще чем do while во всяком случае для меня. От этого и утверждение о неравномерности таких путей в алгоритме. Большая их часть будет ходить по одним и обходить другие.
сложен не код. Сложна концепция. Если мне до сих пор приходится некоторым разработчиками объяснять почему обязательно нужно использовать автоинкрементное поле в таблице — другие концепции также натыкаются на сложность восприятия и особенности их понимания конкретным человеком. В данном случае предполагается что человек для себя уже ответил на вопрос зачем ему это а на вопрос как это сделать он найдет в примерах. А легкость восприятия это вопрос привычки. Легче всего воспринимается код написанный в привычном стиле написания кода. Со временем любой стиль становится привычным.
Выборку данных по нужному условию из смежных связанных таблиц. Если не считать конструкций языка if и foreach которых будет тоже не мало это одна из самых частоупотребимых функций.
Собственно на предположении и основывается. Если почитать сферы деятельности в котором находит применение данный закон можно предположить что он работает и тут. Считает что нет?
Если вспомнить закон Паретто и предположить что он работает и здесь то 20% кода в любой библиотеке будут охватывать 80% ее фукнционала. Остальные 80% будут работать лишь на 20% задач. Тут вопрос в том какого уровня функционал человека устраивает. Мне хватает 10% — вам возможно будет мало 50% от сюда и объем кода который будет по тому же закону разниться на порядки.
Вам не приходилось сталкиваться с неожиданно отказывающим инструментом. В этот момент понимаешь, что придется самостоятельно искать ошибку из трех мегобайт исходного кода волосы встают дыбом. Когда подобные случаи происходят несколько раз подряд начинаешь подходить к выбору инструмента более придирчиво. Понять как работает пятьдесят строк кода на порядок проще чем в миллионе строк, не говоря уже о быстродействии и пороге вхождения. Название "универсальные" использовал по отношению к себе из за большого круга задач где это может применяться. В моем случае подобные конструкции занимают большую часть кода. Для других это может быть не так.
По дефолту где? Хорошо бы подобный подход бул реализован в php по дефолту. Но я встретил только две функции которые полноценно работают с подобными структурами array_column и array_map сторонние решения тяготят своей ООП концепцией, избыточным функционалом и часто быстродействием. Нативные функции реализованные из коробки были бы очень востребованы.
Все реализации orm тяготят своей сложностью. Выбрать из чего-то из за этого не получалось. Всегда находился фатальный недостаток мешающий остановиться на каком то одном выборе. Написав свою реализацию как мне показалось ненужный мне функционал, и реализовал все хотелки. Но надо помнить, то что русскому хорошо немцу смерть. Универсальных рецептов не существует.
С утверждением про библиотеку соглашусь не надо. А от одной крайне важной я бы не отказался.
$tpl['models'] = rb("models");
$tpl['marks'] = rb("marks"):
<? foreach(rb($tpl['marks'], "id", "id", rb($tpl['models'], "marks_id")) as $marks): ?> <h1><?=$marks['name']?></h1> <? foreach(rb($tpl['models'], "marks_id", "id", $marks['id']) as $models): ?> <div><?=$models['name']?></div> <? endforeach; ?> <? endforeach; ?>В этом случае запроса будет всего два при неограниченном количестве их использования.
<? foreach(rb("marks", "id", "id", rb("modeling", "marks_id")) as $marks): ?> <h1><?=$marks['name']?></h1> <? foreach(rb("models", "id", "id", rb("modeling", "marks_id", "marks_id", $marks['id'])) as $models): ?> <div><?=$models['name']?></div> <? endforeach; ?> <? endforeach; ?><? foreach(rb("marks", "id", "id", rb("models", "marks_id")) as $marks): ?> <h1><?=$marks['name']?></h1> <? foreach(rb("models", "marks_id", "id", $marks['id']) as $models): ?> <div><?=$models['name']?></div> <? endforeach; ?> <? endforeach; ?>Вывести марки только те, у которых есть хотя бы одна модель. И дальше список этих моделей.