Каков хороший баланс в модели MVC для эффективного доступа к данным? - PullRequest
2 голосов
/ 09 апреля 2009

Я работаю над несколькими PHP-проектами, которые используют MVC-фреймворки, и, хотя у всех них есть разные способы извлечения объектов из базы данных, всегда кажется, что ничто не сравнится с написанием ваших SQL-запросов вручную, так как скорость и сокращение количество запросов.

Например, один из моих веб-проектов (написанный младшим разработчиком) выполняет более 100 запросов только для загрузки домашней страницы. Причина в том, что в одном месте метод загружает объект, но позже, глубже в коде, он загружает некоторые другие объекты, связанные с первым объектом.

Это приводит к другой части вопроса: что делают люди в ситуациях, когда у вас есть таблица, в которой в одной части кода нужны только значения для нескольких столбцов, а в другой - что-то еще? Прямо сейчас (в том же проекте) есть один метод get () для каждого объекта, и он выполняет «SELECT *» (или явно перечисляет все столбцы в таблице), так что в любое время вам нужен объект по любой причине, Вы получаете все это.

Итак, другими словами, вы слышите все разговоры о том, как SELECT * плох, но если вы пытаетесь использовать класс ORM, который поставляется с платформой, он хочет делать это обычно. Вы застряли в выборе ORM с SELECT * против написания конкретных запросов SQL вручную? Мне просто кажется, что мы застряли между удобством и эффективностью, и если я вручную напишу запросы, если я добавлю столбец, мне, скорее всего, придется добавить его в несколько мест в коде.

Извините за длинный вопрос, но я объясняю фон, чтобы получить некоторые взгляды от других разработчиков, а не конкретное решение. Я знаю, что мы всегда можем использовать что-то вроде Memcached, но я бы предпочел оптимизировать то, что мы можем, прежде чем углубляться в это.

Спасибо за любые идеи.

Ответы [ 4 ]

2 голосов
/ 10 апреля 2009

Во-первых, если вы разбираетесь в SQL и разработке схем, очень мало случаев, когда какой-либо уровень абстракции, который удаляет вас из операторов SQL, превысит эффективность написания SQL вручную. Чаще всего вы получаете неоптимальный доступ к данным.

Нет оправдания для 100 запросов только для создания одной веб-страницы.

Во-вторых, если вы используете объектно-ориентированные функции PHP, у вас будут хорошие абстракции для коллекций объектов и виды расширенных свойств, которые сопоставляются с соединениями SQL. Но важно помнить о том, что вы должны писать лучшие абстрагированные объекты без учета стратегий SQL.

Когда я пишу код PHP таким образом, я всегда обнаруживаю, что могу сопоставить требования к данным для каждой веб-страницы с очень немногими, очень эффективными запросами SQL, если моя схема правильная и мои классы правильные. И не только это, но мой опыт показывает, что это самый простой и быстрый способ реализации. Помещение фреймворка между классами PHP и хорошим твердым тонким DAL (примечание: НЕ встроенные вызовы SQL или dbms) - лучший пример, который я могу придумать, чтобы проиллюстрировать концепцию «вытекающих абстракций».

0 голосов
/ 10 апреля 2009

Доверьтесь своему опыту.

Чтобы не повторяться так много в коде, вы могли бы написать несколько простых функций-моделей с вашим собственным SQL. Это то, что я делаю все время, и я счастлив этим.

Многие «удобные» вещи были написаны для людей, которым нужна магия, потому что они не могут делать это вручную или просто не имеют опыта.

А ведь это вопрос стиля.

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

0 голосов
/ 10 апреля 2009

Ни один каркас ORM даже не приблизится к написанному вручную SQL с точки зрения скорости , хотя 100 запросов кажутся нереальными (и, возможно, вы немного преувеличиваете), даже если у вас есть создатель написания каркаса ORM код, он всегда будет далек от скорости старого доброго SQL.

Мой совет, посмотрите на всю картину не только скорость:

  • Улучшает ли инфраструктура удобочитаемость кода?

  • Команде комфортно писать SQL и смешивать его с кодом?

  • Вы действительно понимаете, как оптимизировать каркасные запросы? (Я думаю, что get () для каждого объекта не является оптимальным способом их получения)

  • Имеют ли узкие места запросы (после оптимизации) платформы?

Я никогда ничего не разрабатывал с помощью PHP, но я думаю, что вы могли бы смешать оба подхода (ORM и обычный SQL), возможно, после тщательного профилирования приложения вы сможете определить реальные узкие места и только тогда замените этот код ORM для написанного от руки SQL (обычно в ruby ​​вы используете ActiveRecord, затем вы профилируете приложение с чем-то, как новую реликвию, и, наконец, если у вас сложный AR-запрос, вы заменяете его для некоторого SQL)

Regads

0 голосов
/ 10 апреля 2009

Я немного заблудился с вашим вопросом, но если вы ищете способ доступа к базе данных, вы можете сделать это несколькими способами. Ваш MVC может использовать Zend Framework, который поставляется с абстракциями доступа к базе данных, вы можете использовать это.

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

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

...