@mkramer я кстати не так давно наткнулся на это определение DataMapper, но чёт пока руки не дошли почитать. У Зандстры вроде же написан ? Надо бы почитать
Кстати, не думаю, что разница в скорости будет в разы. Запросы такие же ORM формирует. За исключением некоторых случаев группирующих запросов, которые лично я никогда через ORM и не делаю.
Ну это если неправильно их использовать, или БД спроектирована не правильно. Так что наоборот именно в большинстве случаев один получается быстрее. Тем более СУБД тоже "кеширует", и повторяющийся запрос работает еще быстрее. Да и вообще хороший профит дает перенос части логики (естественно которая относится к данным) на СУБД. Я на мускуле не пробовал пока, а вот на Interbase/Firebird триггеры, хранимые процедуры и вьюхи помогали хорошо ускорить приложение. Единственное но, там бы не веб. Был сервак отдельный СУБД, а вся основная кухня это уже ПО на персональных компах.
Откуда инфа? И что, нагрузка твоих проектов сравнима прямо с ВК? А как ты делаешь условие по связанной таблице без join? Или по нескольким
@mkramer а как тебе сочетание WHERE IN --- Добавлено --- у товарища прогера друг там разраб --- Добавлено --- ну такого я не говорил. --- Добавлено --- @mkramer но есть такой проект на него приходится около 300-400 в человек одновременно конечно не супер хай. Но всё же там мы почти пришли к тому что избавиться полностью от join и индексы проставили --- Добавлено --- @mkramer вот придумай сочетание где я не смогу обойти это выборкой из одной таблицы а потом по всем полученным результатам составлю WHERE IN (); и отправлю второй запрос на получение этих данных. С учётом индексов по полям два запроса пролетят моментально.
Join-ы индексы тоже учитывают. А если по нескольким связанным таблицам? --- Добавлено --- https://ruhighload.com/post/Как+использовать+индексы+в+JOIN+запросах+Mysql
@askanim, смотря что джоинить. Если речь о справочниках, то профит возможен... А просто слепо смотреть на "вк" это не серьезно. Мы ж достоверно не знаем их архитектуру, предполагать можем это да.... Не думаете же вы, что за столько времени существования SQL только вк додумались, что join это плохо? Join это обычный инструмент, и важно уметь грамотно им пользоваться. Вот в той системе что я сопровождал, я с ужасом представляю, что бы пришлось делать откажись от join. В случаях где join уместен, вам все равно это придется делать, но на том же PHP. Но СУБД заточена на это, и работает с этим не один десяток лет, думаете PHP скрипт отработает быстрее чем оптимизированное ядро. [OFFTOP] В свое время в институте товарищ писал программу для одного научного рассчета. Вычисления шли 2 или 3 дня. Я тогда ассемблером увлекся и переписал для него математику на asm. Для вычислений хватило 5 часов. Потом был у меня проект реалтаймовый - попробовал узкое место переписать на asm.... Фиг. компилятор все равно более быстрый код (из C++) рожал.... Попробуйте переделать любую функцию PHP на свой аналог из более простых - будет работать медленнее. [/OFFTOP] Я этот офтоп к чему: Надо все же доверять инструментам заточенным под свое назначение. ВК скорее всего не от хорошей жизни отказалось от JOIN и не в полной мере. У них вообще, мне кажется, несколько другая СУБД (а то и не одна)
Да? Вы уверены, что ни когда и не за что не превысите длину запроса? А если отбирать надо по колонкам из обеих таблиц? (а из трех....?)
@voralа из трёх это точно жёпашный запрос --- Добавлено --- @voral да это так мускуль вообще не айс. Надо тестить но у меня задач на Join редко приходится где я могу написать два простых запроса за место одного тяжёлого пишу два.
Круто... Т.е. нам надо получить первых десять человек. Мы выбираем всех... Для всех делаем второй запрос, сортируем, и уже показываем только 10.... Замечу - это мы только две таблицы взяли
С чего это? Просто у вас не встречалось таких задач. Это нормальный запрос. Или вы предлагаете нарушать принципы построения БД?
дай лучше свой пример и я попробую сделать не получится если знач буду иметь ввиду когда надо юзать Join --- Добавлено --- лучше пусть у меня два запроса каждый из которых по 100 мс пройдут чем один в 200 мс. вот честно.
7 000 000 была у меня как то база были индексы. Ток вот не хрена запрос хоть убей 300 мс шёл --- Добавлено --- сделал на два в два раза быстрее пошло
Просто я придумываю, как можно так плохо построить запрос с джоином, чтоббыо выгоднее сделать два запроса и потом их клеить и дообрабатывать в приложении.