Чистая структура OO по сравнению с производительностью sql

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

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

Честно говоря, просто создайте метод в вашем блоге класс getBlogsWithAuthors (), а затем запустите

SELECT  *
FROM    blogs
JOIN    authors 
        ON authors.id = blogs.author

. Я знаю, что писать подобные вещи для каждого класса моделей может показаться сложной задачей, но на самом деле другого пути нет. Однако вы можете сделать его немного более динамичным:

//this is a method of a model class. 
//Assume $this->table is the table name of the model (ie, Blog)
public function getWith($joinTable, $pivot1, $pivot2)
{
    $sql="SELECT    *
            FROM    {$this->table}
            JOIN    $joinTable 
                    ON $pivot1 = $pivot2";

    return executeQuery($sql);    
}

$blog=new Blog();
$result=$blog->getWith('authors', 'authors.id', 'blogs.author');
[play with results here]

Это это классическая проблема ORM. Многие школы мысли. Не уверен в специфике php, но есть несколько стратегий для устранения этого «несоответствия импеданса». Google orm.

Вы уже ответили на вопрос:

Используя простой SQL, я мог бы получить эту информацию с помощью простого запроса

У вас есть выбор между SQL, который извлекает только сообщения блога и SQL, который извлекает сообщения блога и авторов. Точно так же у вас есть выбор между некоторым PHP-кодом, который извлекает только сообщений в блоге, или PHP-кодом, который извлекает сообщения в блогах и авторов. Вы должны сделать выбор в отношении своего кода PHP, так же как вы должны сделать выбор в отношении своего SQL.

Выше есть множество примеров, демонстрирующих, как это будет работать на практике. Рекомендация использовать Doctrine или Propel также хорошая.

Propel - это пример PHP ORM, который может с этим справиться. Я уверен, что Doctrine должна быть в состоянии это сделать, хотя я никогда не смотрел на это.

Зачем изобретать велосипед?

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

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

Я большой сторонник ORM, и вот мое мнение:

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

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

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

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

Я использовал некоторые другие привязки .. Пример:

Если вы не знаете, что неэффективные операции sql не будут иметь реального влияния, например, количество повторяющихся итераций или затронутые строки всегда будут небольшими (например, повторение операции над числом детей в семье, которых, за исключением очень редких случаев, таких как Дуггары, можно считать менее 10), я всегда отдавал предпочтение эффективности реляционного запроса красоте объектно-ориентированного кода.

Хотя некрасивый объектно-ориентированный код код может усложнить обслуживание, неэффективный доступ к данным может поставить систему на колени, обычно когда вы в отпуске или пытаетесь уснуть. И в большинстве случаев можно найти хороший компромисс, благодаря которому наиболее эффективные операции SQL будут иметь достаточно «объектный» интерфейс. Это может стоить вам немного больше времени, когда дело доходит до рефакторинга или добавления функций, если ваша объектная модель не красива, но это стоит вашим клиентам времени каждый раз, когда они нажимают эту кнопку (или денег с точки зрения более крупного оборудования для запуска app - никогда не бывает хорошим методом оптимизации), и человеко-часы, потраченные на использование приложения, должны намного превосходить человеко-часы, затраченные на его разработку (можно было бы надеяться).

Что касается ваших опасений по поводу того, понадобится ли интерфейс ( заставляя вас выяснять все возможные модели потребления), я справился с этим, выполнив все мои изменения данных с помощью хранимых процедур, но разрешив доступ к данным напрямую против таблиц и представлений, предоставив всем пользователям только права выбора. Это полу-спорная позиция, поскольку многие люди хотели бы заблокировать все операции доступа к данным от последующих потребителей во имя обеспечения того, чтобы все выполняемые sql соответствовали их стандартам. Но всегда появляются новые способы просмотра данных, и если вам нужно добавить новую сохраненную процедуру, обновлять библиотеки основных классов и обновлять код клиента каждый раз, когда кто-то хочет реализовать новую функцию, развертывание и квалификация могут вырасти до быть настоящим бременем - гораздо больше, чем иметь дело с объектной моделью, не соответствующей религиозным идеалам. И намного проще реализовать процесс проверки кода, который проверяет, что новые операторы выбора, написанные нижестоящими потребителями, являются кошерными.

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

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

Рассмотрите разделение команд и запросов, как описано Грегом Янгом и Мартином Фаулером. В вашей модели запроса могут быть денормализованы Блог и Автор в единую таблицу, оптимизированную для извлечения DTO для вашего уровня представления.

Грег Янг сделал отличную презентацию по CQS на InfoQ.