@igordata у нас есть сайт который держит кучу сайтов, задача такая передлать весь тамошний гавно код в что нибудь нормальное, и нормально работающие без лагов. Но так же я хочу сразу взять за основу какие нибудь более менее удобные для этого каркасы. Например я уже беру роутер slim, а второе мне нужна оболочка для работы с pgsql.
просто проанализируй ORV vs sql query builder например вот наобум в гугле https://github.com/usmanhalalit/pixie это вот помогает строить запросы. Объект можно передавать в разные методы, и они будут докидывать на него свои условия. Потом ты - бах - и получил запрос. Это удобно. а орм она не просто запросы делает. Она ведёт себя определённым образом. У неё может быть ленивая подгрузка объектов по одному. А может не быть. А можно использовать ORM, а запросы тяжелые фигарить через куери билдер. Короче, это не просто "я ща достану из штанов толстый ORM и мой код станет красивым и охуенным".
у меня нет опыта работы с этими штуками. я пишу запросы руками и читаю глазами. Мне норм. Но я б заюзал ченить помогающее их делать, да. Просто пока не приспичило.
Не, строилка запросов минимально грузит проект, оверхед только за счёт того, что появляются классы. Это простая, на самом деле, штука, которая хранит внутри объекта запроса все твои where, order by, join-ы и т.п. в понятном ей виде (обычно специфический массив), и только перед самым запросом на основе всего этого генерит строчку запроса. Удобство в том, что до этого момента она запросто может пройти через 15 твоих классов, каждый из которых что-то туда может добавить. И при этом всё равно в каком порядке - можно сначала order by, потом where, потом join, потом опять where и т.п. Вот ORM подгружает, да. Особенно ActiveRecord, хотя он и достаточно удобен. И есть вещи К тому же, не знаю как сейчас, а когда-то doctrine ORM сканил налету исходники, по комментариям смотрел соответствие полей БД и полей классов. Сейчас они вроде как с ActiveRecord перешли на Data Mapper, так что по-идее побыстрее должно быть. https://github.com/PHPixie - отсюда можешь взять последнюю версию. Читал пост автора на хабре, что он несколько лет потратил на то, чтобы добиться самой минимальной связанности, чтоб можно было не весь его фреймворк тащить, а только то, что надо.
Я советую открыть для себя мир SQL и написания запросов руками. Разница между postgesql и mysql минимальна, и если ты её не знаешь(я её тоже если что не знаю), переходить с одного на другое нет смысла. Лучше проставьте индексы в базе мускула, там где они нужны и занимайтесь программированием. Базами в упоротых хайлоад-проектах должен заниматься разработчик бд.
Весьма. Вот пример из текущего проекта. Есть контакты, у них есть свойства, которые ещё и динамически вешаются (т.е. мне не известно, чего придумает юзверь). Но не суть. Эти контакты надо получать списком из базы. К списку могут быть применены фильтры. К списку может быть применена сортировка, и хрен знает что ещё. Так вот, функция, которая получает список контактов (у меня это функция класса "Хранилище контактов"), понятия не имеет, какие такие фильтры, она другим занимается. Она просто перед тем, как получить список, передаёт его объекту, полученному в аргументе (если там не нуль). Если я подставлю туда объект, который фильтрует, то будет фильтровать, если который упорядочивает - будет упорядочивать. А могу делать комбинации благодаря (пока, потом может на другой сменю, как удобнее будет) паттерну "декоратор". Другое дело, мне немного не нравится, что все эти объекты-фильтровщики привязаны жёстко именно к этому хранилищу, но в этой задаче их никак не отвязать. Если бы в php были внутренние классы, как в C++ или Java, я бы их внутри и сделал.
mysql умеет. Doctrine 2 - штука удобная, конечно. Но её надо капец как учить. С её ленивыми\неленивыми запросами, маппингом, каким-то иногда непонятным и нелогичным на первый взгляд построением запросов (да блин, и на второй тоже), можно запросто выстрелить себе в ногу. В общем у меня есть довольно простые сущности в проектах, с простыми запросами. Для сложных запросов я использую библиотечку, которая умеет только экранировать вместо меня (ну и пару ещё простых нудных штучек). Т.е. сложные запросы всё равно предпочитаю ручками. и щас всё в пхп-доке
А индексы без адовых костылей она по ним научилась строить? --- Добавлено --- У нас раньше был мускуль, потом по ряду причин и желанию левой пятки было принято решение перебраться на pgsql. Слава PDO, фреймворкам и eloquent процесс занял... а ничего он не занял, одна строчка в конфиге. --- Добавлено --- Ты действительно думаешь, что люди берут orm от того, что не умеют писать запросы руками?
@mkramer я когда на ларе делал, там вроде класс полностью отражает бд. --- Добавлено --- @machetero я мускулем своими ручками уже полтора года шурудю надоело. Хочу элегантное решение, вот и всё. там всё просто и элементарно. Если понимаешь логику работы, то всё встаёт на свои места. --- Добавлено --- а можно пример в студию где такой в mysql есть тип данных json. Просто когда мне было нужно, а это было примерно 8 месяцев назад его там не было, но может что-то изменилось, но вроде как mysql не особо развивается. У меня стояла mysql 5.7 . Так что пожалуйста можно пример где там тип данных такой есть. в pgsql куча типов данных которых в мускуле просто нету. --- Добавлено --- @mkramer, @igordata спасибо. Ща композером тянуть буду.
1) Я постгришку не юзаль, к сожалению ли к счастью ли. MySQL брал, SQLite брал, PostgreSQL не брал. 2) ORM это не для воспарить как ласточка. ORM это для удобного использования данных, которые можно промапить на объект. Не везде это можно, не везде это нужно, не всегда оно на пользу. Если архитектура БД не пилилась изначально чисто под ORM, то можно огрести целый самосвал костылей и головняка. Да и как по мне, ORM на пхп не нужон. Вот правда, вообще никак. Работал я с JAVA и .NET, там да, там ок. Но там другие требования к производительности, плюс, это был не веб, а десктопные решения, и там БД обычно - это именно что хранилище объектов, аналог сериализации, но с поддержкой выборок. Ни JOIN-ов пятиэтажных, ни хитрозадых вьюх, никакого головняка. Строка в таблице - это перечень свойств какого-то конкретного объекта в системе. Вот на такие кейсы ORM-ка ложится вообще идеально. Для таких вещей, собственно, она и рождена. А в вебе я солидарен с Игорем - запрос ручками написать проще. Тут другие требования к выборкам данных, к гибкости этих выборок. И совершенно другие требования ко времени жизни объектов. В 99% случаев все результаты запросов одноразовые. ORM избыточное решение для таких вещей, как по мне. Плюс, ORM плохо ложится на всякие меморишардеры. И сами по себе объекты, в том числе и в PHP, по природе своей - заведомо менее гибкая структура, чем массив. Просто потому, что для другого созданы. Единственное известное мне исключение - JS, там в этом плане безумие.
А какая в фрейморке имеется, той и строю. Конкретно описанный проект пришлось делать на codeIgniter, желание заказчика, и там уже начали на нём делать. Поделка не нравится, но сойдёт. Я просто стараюсь бизнес-логику по-возможности от неё отвязать. Так, я люблю yii, но проект, который мне сейчас готовят, хочу попробовать на Laravel. Там есть и Query Builder, и ActiveRecord, можно выбирать под задачи. Только недавно прочитал практически всю доку на сайта Laravel.
предположу, что они работают подолгу, могут нажраться данными из бд, прогреть кеши, и перестать в неё лазить по каждому чиху.
Да, как-то так и есть. В ходе жизни востребованная часть БД мигрирует в оперативку. И мы работаем с ними как есть. Потом, по завершению работы мы синхронимся в БД и...все. Данные на месте, все ок, приложение закрылось. В данном случае ORM позволяет: 1) Не грузить в оперативку все все все все нужные данные разом, как если бы мы просто все сохранили в файлик и прочитали разом. 2) При этом экономим на долгой дистанции память, так как ORM-объект в ленивом режиме может быть сформирован вообще лишь частично. И ему будет норм. 3) Объект в памяти работает всяко быстрее, чем БД. И при этом он является полноценным объектом, у него даже методы можно нарефлексировать, что уж там. Но на таких коротких дистанциях, какие мы имеем в PHP, эти преимущества не раскроются никогда. А вот накладных расходов на этой короткой дистанции - полные карманы. --- Добавлено --- Ну и да, самая вишенка-на-тортике в том, что PHPшные массивы по удобству работы не уступают ORM-решениям. Те проблемы, которые ORM в этом плане решает в тех же Java и .NET, в пыхе попросту отсутствуют. А такая фича как ленивая загрузка, в случае с пыхом вообще контрпродуктивна. Накой ляд мне делать 2-3 запроса в ходе работы скрипта, если я могу дернуть данные разом и не париться? Они мне нужны на пару-тройку микросекунд всего.
зато можно не искать хорошего пхпшника среди вебадминов, а посадить любого джависта, коих жопой жуй - и он будет писать хороший код. А если че хреново работает - это не беда, у внутрекорпоративного сайта посещалка ниже плинтуса. --- Добавлено --- я когда писал форум так прикинул, что у здорового даже комьюнити разделов на форуме будет ну всяко меньше сотни, а обычно - меньше десятка. Т.е. я всегда выбираю всё дерево разделов форума одного сообщества из бд одним запросом. И збз. И кешируется ещё.
В общем, @askanim, серебряной пули нет, а ложка хороша к обеду. ORM-ы, кверибилдеры-хренилдеры, это вот все не панацеи. Это инструменты, у которых есть своя специфика и понятие "применимость". Крестовая отвертка не лучше плоской, все зависит от типа болта. А если у тебя не болт, а гвоздь, то отвертки вообще не в тему. Как-то так.
луддиты --- Добавлено --- Формально он есть, по нему можно даже искать, но это будет та ещё головная боль, особенно учитывая что нормальный индекс по json они пока так и не осилили. Кстати, не забудь раскурить вот этот раздел доки про отличие json от jsonb https://postgrespro.ru/docs/postgrespro/9.6/datatype-json