PHP Lang
  1. PHP Lang
  3. Полезно ли использовать библиотеку Active Record для CodeIgniters для управления базами данных MySQL или просто использовать SQL?
Intereting Posts
повторяющиеся записи mysql и php Яркая загрузка, сдерживание жадных нагрузок, ленивая нетерпеливая загрузка Подстановочный IP-запрет с использованием MySQL Недействительный JSON в Chrome, без проблем в Firefox (так странно!) Почему mb_ereg () не обнаруживает арабские символы? Laravel 5 Дата и время в формате Carbon Переопределить общедоступный метод в подклассе таким образом, чтобы ограничивать доступ к общедоступным данным, сохраняя при этом доступ к родительскому классу? Проверка jQuery, если правильный элемент был «сброшен» Instagram Realtime update tag – получение пустых данных, почему? Запрос SOAP с использованием SoapClient Ajax и возвращаемое изображение, созданное PHP GD PHPExcel – Как я могу прочитать лист Excel по строкам PHP print () Арабская строка Как вызвать функции PHP из функции JavaScript для доступа к базе данных лучший способ получить блокировку в php

Полезно ли использовать библиотеку Active Record для CodeIgniters для управления базами данных MySQL или просто использовать SQL?

Я начинаю разбираться с CodeIgniter и наткнулся на его поддержку шаблона Active Record .

Мне нравится, что он генерирует SQL-код для вас, поэтому вы можете получать, обновлять и вставлять данные в базу данных, не привязывая приложение к определенному движку базы данных.

Это делает простые запросы очень простыми, но я обеспокоен тем, что он делает сложные запросы более сложными, если не невозможными (например, при необходимости для конкретных функций двигателя).

Мои вопросы

Каково ваше мнение об этой модели, особенно в отношении реализации CodeIgniters?

Существуют ли какие-либо проблемы с загрузкой базы данных на другом уровне?

Разве это (логика) становится беспорядочным при попытке построить очень сложные запросы?

Имеют ли преимущества недостатки?

Хорошо. Прежде всего, 99% ваших запросов будут простыми в выборе / вставке / обновлении / удалении. Для этой активной записи отлично. Он обеспечивает простой синтаксис, который можно легко изменить. Для более сложных запросов вы должны просто использовать метод запроса. Это для чего.

Во-вторых, он обеспечивает ускорение и безопасность для этих запросов. Посмотрите на это, ваше приложение, вероятно, будет иметь сотни, если не тысячи мест, где выполняются запросы. Твоя обязанность испортить и забыть, чтобы избежать некоторых из них. Активная запись не забывается.

В-третьих, производительность в моем опыте не сильно затронута. Конечно, это всего лишь около .00001 за запрос. Я думаю, что это вполне приемлемо для дополнительных проверок безопасности и здравомыслия, которые он делает для вас.

Наконец, я думаю, что ясно, что я считаю, что преимущества намного больше, чем недостатки. Наличие безопасных запросов, которые даже ваш самый младший разработчик может понять, а не испортить, – это отличная вещь.

Каково ваше мнение (sic) этой модели, особенно в отношении реализации CodeIgniters?

Не могу сказать много о реализации CI. Вообще я избегаю AR ни для чего, кроме простейших приложений. Если таблица не соответствует 1: 1 моим бизнес-объектам, я не использую AR, так как это затруднит моделирование приложения. Мне также не нравится идея связать слой persistence с моими бизнес-объектами. Это нарушение разделения проблем. Почему продукт должен знать, как сохранить себя? Дальше чтение: http://kore-nordmann.de/blog/why_active_record_sucks.html

EDIT после комментария @kemp, я просмотрел Руководство пользователя CI, чтобы узнать, как они реализовали AR:

Как вы можете видеть в PoEAA , AR – это объект, который обертывает строку в таблице базы данных или представлении, инкапсулирует доступ к базе данных и добавляет логику домена к этим данным. Это не то, что делает CI. Он просто предоставляет API для создания запросов. Я понял, что существует класс Model, который расширяет AR и который может использоваться для создания бизнес-объектов, но тогда это будет больше похоже на Row Data Gateway . Проверьте PHPActiveRecord для альтернативной реализации.

Существуют ли какие-либо проблемы с загрузкой базы данных на другом уровне?

Всякий раз, когда вы абстрагируетесь или обертываете что-то в нечто другое, вы можете быть уверены, что это связано с влиянием производительности на выполнение этого процесса. Вопрос в том, приемлема ли ваша заявка. Единственный способ узнать – это бенчмаркинг. Дальнейшее чтение: https://stackoverflow.com/search?q=orm+slow

РЕДАКТИРОВАНИЕ В случае простого API построения запросов, я предполагаю, что влияние производительности будет пренебрежимо. Сборка запросов логически займет больше времени, чем просто с помощью передачи необработанной строки SQL в адаптер db, но это должно быть только в микросекундах. И, насколько я видел это в Руководстве пользователя, вы также можете кэшировать строки запроса. Но когда есть сомнения, контрольный показатель.

Разве это (логика) становится беспорядочным при попытке построить очень сложные запросы?

Зависит от ваших запросов. Я видел довольно грязные SQL-запросы. Они не становятся красивее, когда выражаются через интерфейс OO. В зависимости от API вы можете найти запросы, которые вы не сможете выразить через него. Но опять же, это зависит от ваших запросов.

Имеют ли преимущества недостатки?

Это только вы можете решить. Если это делает вашу жизнь программистом легкой, то почему бы и нет. Если это соответствует вашим потребностям программирования, да. Ruby on Rails сильно зависит от этой концепции (AR), так что это не может быть так плохо (хотя об этом тоже можно было бы спорить :))