Наиболее краткая и полная поддержка рекурсивных ассоциаций в CakePHP?

Question

В настоящее время я слоняюсь с CakePHP, решая, буду ли я использовать его в следующем веб-приложении.

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

Так, например, у меня есть таблицы «Пользователи», «Профиль», «Ранг», «Рейтинги», и я хочу получить профиль, рейтинг и рейтинги одного конкретного пользователя. CakePHP добьется цели, используя несколько отдельных операторов SELECT. Но это было бы возможно, используя один запрос с несколькими объединениями. Ожидается, что производительность будет очень важной, поэтому не слишком расточительно относиться к запросам SQL - главное преимущество.

Я нашел два хака ( одно поведение и один с использованием bindModel ) и аналогичный поток StackOverflow .

Я не знаю, использовать ли поведение или взломать bindModel. Кто-нибудь может пролить свет на то, что лучший подход - а именно. что лучше всего интегрируется в общую структуру CakePHP (доступны ли такие функции, как нумерация страниц)? Или есть другой подход, который в конечном итоге лучше. В потоке SO упоминается метод с использованиемableables.

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

Answer 1

Ссылка на эту статью о пекарне в другой упомянутой вами статье StackOverflow, вероятно, является лучшим методом для выполнения специальных объединений (без bindModel или специального поведения). Вы уже можете указать встроенные объединения (включая дополнительные лакомые кусочки, такие как тип объединения) в параметрах для любых вызовов метода find (), но их можно значительно упростить, создав новый тип поиска, который требует меньше записи в поиске ( ) опции. Об этом говорится в статье.

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

Answer 2

Самый простой способ сделать это - не беспокоиться о сокращении запросов SQL и реализовать некоторую форму кеширования.

Следующее решение - пропустить поведение Containable, так как оно не работает для сокращения ваших запросов, - это сделать несколько специальных соединений в вызовах find напрямую. Рекомендуется вставить их в модель, чтобы вы могли вызывать их из центрального места. Хорошая статья об этой технике находится в пекарне здесь: http://bakery.cakephp.org/articles/view/quick-tip-doing-ad-hoc-joins-in-model-find

Лучшее решение *1007*, которое я нашел на сегодняшний день, - это связанное поведение Рафаэля Бандейры: http://blog.rafaelbandeira3.com/2008/11/16/linkable-behavior-taking-it-easy-in-your-db/, которое позволяет вам использовать пользовательский ключ в массиве опций, который определяет поля и отношения для соединения в ясной форме и использует технику, описанную в 1 , для использования соединений вместо последовательных запросов.

Удачи в вашем проекте.

Answer 3

У меня были похожие проблемы, и, поскольку производительность была огромным фактором, я решил просто использовать сырой SQL, а не пытаться поиграть с решениями исключительно для поддержания «торта». Кроме того, иногда просто приятно знать, где находится узкое место (даже если режим отладки 2 немного помогает). Миграция БД никогда не будет проблемой.

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

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