Общий механизм взаимодействия с бд

193

17 августа 2018, 05:20

Решил написать проект (учебный) на laravel. И так как это известный фреймворк естественно посмотрел как он устроен. Конкретно интересовала реализация механизма:

работы c базой данных
сессий
CSRF

Сейчас меня интересует общий вопрос по базам данных.

Посмотрев пару фалов реализации работы с базой данных для себя понял следуюющее:

в файле конфигурации хранятся данные для подключения к базе данных; и выбрано драйвер.
так как реализована поддержка множества известный бд, то и написаны классы которые выполняют подключение ( возвращают объект PDO) с учетом специфики каждой бд (MySQLi - файл ; MySQL - сокет / удалено) и т.д.
после чего реализован общий интерфейс работы с бд ( общая грамматика SQL ), соответственно и реализован этот интерфейс для каждой бд с учетом их специфики работы. ( поддержка транзакций и т.д. )

Сам принцип взаимодействия с бд построен по шаблону ActiveRecords, с этим ясно так так такой принцип и в других фреймворках ( тот же Yii ).

После чего у меня возник вопрос: если на каждую таблицу создана модель, то как тогда делать сложные запросы? ( запросы с подзапросами, соединение таблиц и т.д.).

Посмотрев документацию Laravel нашел ответ на свой вопрос здесь.

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

Если что-то понял не так, пожалуйста исправте, именно для этого и создан этот вопрос.

И на основе всего выше сказанного сами вопросы:

В чем преимущество использования ActiveRecords кроме того, что каждое свойство объекта соответствует названию столбца в таблице бд?
Есть множество книг по оптимизации работы баз данных ( к примеру Шварц Б., Зайцев П., Ткаченко В. и др. - MySQL. Оптимизация производительности), по SQL в которых тоже есть много "умного" по правильной работе с тем же NULL т.д, нормальные формы бд... Тогда почему не пишут SQL? Не спорю удобно написать один раз код где-то и потом использовать везде, но что насчет оптимизации?
У каждой бд своя специфика работы, поддержка как стандартизированных функций так и нет ( тот же MySQL). Опять таки написано уйму книг по их настройке и оптимизации. Тогда правильно ли все сводить к одному общему интерфейсу? Как по мне тогда нет никакого смысла использовать что-то лучше чем MySQLi для блога и MySQL для крупного проекта. (Имею введу поддержку Oracle бд, это мощная бд, ресурсоемкая, но ее использовать будут для вставки и обновления)

Answer 1

ActiveRecords - это ORM.

Преимущества отсюда очевидные:

1) Независимость от СУБД. (т.е. если БД у вас сменится на тот-же постгрю, то не надо будет переписывать).

2) ООП подохд.

3) Связи, валидация, удобство работы и куча других мелочей.

Недостатки офк тоже есть:

Если опустить всякие аргументы типа, больше времени нужно, памяти и т.д. то главный минус это то, что паттерн нарушает некоторые другие, например: Принцип единственной ответственности. Так-же могут быть лишние запросы, но это уже второстепенное.

P.S.:

В принципе вы все описали. Так работает ActiveRecord, в целом, он удобен при разработке. Про оптимизацию нечего сказать ибо ничего конкретного вы не спросили, ActiveRecord, как и любая ORM не гарантирует оптимальность SQL-запроса но 99% зависит именно от вас. От того как вы составите запрос с помощью ActiveRecord и настроите БД.

P.S.2:

Если вам не нравится ActiveRecord используйте DataMapper. Надо понимать, что Laravel хочет стандартизировать свои проекты, а за любым стандартом кроется куча камней и минусов (всем не угодишь). Для очень нагруженных сайтов, возможно ORM не используется, но чтобы так нагрузить, надо еще постараться.