Какую php библиотеку использовать для работы с БД?

Question

[Дмитрий Баскаков]

Какую php библиотеку использовать для работы с БД?

Нужен максимально гибкий инструмент с stmt, что посоветуете?

Есть самопальная, но местами её гибкости не хватает. Например, когда нужно сделать сложное сравнение или проверить регулярное выражение, или банально указать лимит. Просто изначально собирал набор функций в один класс для быстрой работы с БД для простых проектов, а тут пошли немного сложные и нужно что-то новое, причем желательно с комьюнити и документацией

Comments

[Дмитрий]

Тут сейчас напишет каждый свой совет. Может orm?

Answer 1

[FanatPHP]

Для начала надо определиться, о каком инструменте речь.
Есть три вида инструментов

1. DBAL - просто класс для выполнения запросов. PDO практически на 90% покрывает задачи такого класса.
Запросы пишутся вида

$user = $db->prepared_query("SELECT * FROM users WHERE id = ?", [$id])->fetch();

2. Query builder - построитель запросов.

$user = $db->select('*')->from('users')->where('id', $id);

3. ORM - запросы скрыты внутри, мы пишем только штуки типа $user = User::load($id);

Максимально гибким, разумеется, является первый.

Comments

[Arris]

Мне бы второе (хорошее, потому что плохих пруд пруди), потом скормлю первому. И без фреймворка.

[Дмитрий Свиридов]

Arris, второе хорошее и без фреймворка: можно использовать только DBAL из Doctrine (https://www.doctrine-project.org/projects/doctrine... и юзать без фреймворка, как, впрочем, и саму Doctrine целиком, если припрет. Ее вовсе не обязательно вместе с Симфони использовать.

Минус первого и второго варианта заключается в том, что тебе в итоге придется писать руками гидратор. То есть некие функции, которые будут результат выполнения запроса маппить на некий объект (entity) с методами get/set. Можно, конечно, просто напрямую работать с записями из базы, как с массивом, но это такое себе дело, потому что в большом проекте начнется полная каша, когда, например, столбец удаляют/переименовывают - придется по всему коду лазать и менять. И не факт, что где-то не забудешь. Эту проблему даже покрытие тестами не всегда решает, как показала практика.

Минус ORM заключается в том, что они всегда недостаточно гибкие. У меня есть проекты, где изначально была Доктрина, а сейчас я смотрю - и она там по итогу почти не используется, потому что запросы сложные (используют конструкции типа with из PostgreSQL и т.п., которые средствами ORM сложно делать), пришлось их руками писать.

[Arris]

в большом проекте начнется полная каша, когда, например, столбец удаляют/переименовывают - придется по всему коду лазать и менять. И не факт, что где-то не забудешь.

Я готов рискнуть :)

потому что запросы сложные (используют конструкции типа with из PostgreSQL и т.п., которые средствами ORM сложно делать), пришлось их руками писать.

Со сложными запросами понятно :)
Но с простыми - надоело их писать руками, хочется сладкого fluent-интерфейса.

Тем более что вотсейчас на одном проекте уже написан типа-DBAL (еще до меня), но такой кошмарный, что житьё с ним... нет, в общем можно, но он крайне избыточен.

[Игорь]

Дмитрий Свиридов, доктрина позволяет использовать наТивные запросы.
И маппить в ручную.

Я бы выбрал третье решение.
Хочешь использовать наивно, пожалуйста.

[Дмитрий Свиридов]

Игорь, так а смысл, когда у меня в микросервисе суммарно запросов штук 30 было, из низ лишь 2 или 3 шло через доктрину (ORM), остальное как раз нативно? Нет никакого смысла вообще в таком случае Доктрину оставлять. Только ради маппера разве что.

[Игорь]

Дмитрий Свиридов, Ну так доктрина не только для того, что бы выполнять запросы, вы сами прекрасно понимаете.

Да, запросы могут быть очень сложные.
Ну а как насчёт контроля полёй в базе.
Миграции.
А объектное представление чего только стоит.

Составил сложный запрос, замаппил вручную, получил объект.

Чувствуется потенциал...

[turone]

Arris,

хочется сладкого fluent-интерфейса

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

[Дмитрий Свиридов]

Игорь, миграции очень часто вообще делают сторонним инструментом или отдельной библиотекой. Например, phinx. Я в своем текущем проекте Доктрину не использую, и могу сказать, что мне только гидраторов разве что не хватает. В остальном, запросы достаточно хитрые - Доктрина избыточна (максимум квери билдер из нее кое-где можно приспособить). А юзать ее только для маппинга результата на объект особого смысла не вижу. По крайней мере, на текущий момент. Кстати, Вы пробовали мокать доктрину для unit-тестов?

[Игорь]

Кстати, Вы пробовали мокать доктрину для unit-тестов?

Нет, не пробовал.

Есть проблемы с этим?

Хз, нужно попробовать, как раз назревает задача.
В любом случае, мы же будем тестировать бизнес логику приложения, а не саму доктрину.

[Arris]

turone, пробовал, не зашло.

"Сладкий fluent-интерфейс" - это другое.

Answer 2

[index0h]

Doctrine

Comments

[Александр Сисюкин]

Гидрация большого объёма данных не останавливает ?

[index0h]

Нет конечно, для реально крупных объемов гидрируем в массив и радуемся жизни

Answer 3

[Антон Антон]

Eloquent и query builder под ним, а лучше совместно с laravel

Comments

[Arris]

Не лучше. Не подсаживайте человека на иглу фреймворков.

[Антон Антон]

Arris, человек сам просит подсадить его. Тем более, что ларавел не самый плохой вариант.

[Arris]

Антон Антон, э, ну, библиотека работы с БД - это не фреймворк, не?

[index0h]

Eloquent - это одна из худших ORM с точки зрения архитектуры и кривой сложности, не стоит ее использовать.

[Антон Антон]

index0h, а доктрина - одна из лучших?

[index0h]

Антон Антон, верно

[Антон Антон]

index0h, ну они делают разные вещи немного :)
eloquent - это active record, + под ним относительно нормальный query builder. Дата маппер можно свой нарисовать при необходимости. А доктрина - она часто оверкилл + её собственный sql подобный язык, не очень поддерживаемый IDE разными.

[index0h]

@Fragster

eloquent - это active record, + под ним относительно нормальный query builder.

nope, если уже сравнивать с AR - тогда хотя бы Yii-шная ORM.

А доктрина - она часто оверкилл

В чем часто проявляется оверкил?

её собственный sql подобный язык, не очень поддерживаемый IDE разными

Какими например?

Answer 4

[turone]

Я успешно пользуюсь SafeMySQL - очень быстрый, безопасный, удобный. Если нужно что либо вычурное, то лучше дописать пару функций самому, все равно под все ваши задачи универсальной библиотеки не найдете, а дописать пару SQL запросов быстрее будет. К тому же, если сами допишете, то сможете сделать более оптимизированный код под ваши задачи. К примеру насчет лимитов, стандартный запрос иногда можете быт очень медленный - вот тут подробнее, а немного подправив запрос можно избежать серьёзных задержек.