Поисковая форма:) поиск по free-lance.ru Топ/история/обновления фриланса, по разным параметрам (темы, сообщения, пользователи...) Автоматическое удаление постов от ненужных юзеров в топике (php скрипт) Досье(точный ник)
 

Ник (или часть ника):
?
Какой текст ищем:
?
Раздел блогов:
За срок
дней
Тип поиска: (по вхождению: по тексту гуг выдаст посты с "гуг", "гугл", "огугл"; "полнотекстовый": по тексту "гуг" выдаст посты только с "гуг")
По вхождению строки:  Полнотекстовый: 
(поиск не 100% актуальный, есть определённая задержка при обновлении данных для поиска. )
0 Всего найдено: 18
vvv333 Сообщение 21/11/2012 14:27 Копия темы
Совет знатоков по Yii. DAO или AR ? Пару недель назад было принято решение, что следующий модуль приложения будет реализован на DAO, чтобы получить возможность контролировать запросы, и таким образом снизить нагрузку.

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

И за этого возник вопрос. Стоит ли использовать DAO для проекта у которого сейчас посещаемость не очень, но в будущем предполагается 100 тыс. уников в день. Или же смело можно делать все на AR только оптимизируя его правильно ?

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

Как правильно поступить ?

Буду благодарен вашим ответам.
csky Сообщение 21/11/2012 14:45 Копия темы
ru.wikipedia.org/wiki/%D0...
Как будет у вас посещаемость 100 т. так и думайте что делать дальше, где вводить кеш и что оптимизировать.
vvv333 Сообщение 21/11/2012 14:51 Копия темы
Ну это понятно . Но идея состоит в том чтобы сделать изначально правильную основу, ибо как проект давольно масивный, и в будущем его можно будет уже оптимизировать легче.

Но если честно суть вопроса состоял не в 100к уников а в разнице между DAO и AR.
Стоит ли сипользовать DAO или же тот же результат можно получить правильным конфигом AR-а ?
csky Сообщение 21/11/2012 15:12 Копия темы
AR не предоставляет решения всех задач, касающихся работы с базами данных. Лучше всего использовать AR для моделирования таблиц в конструкциях PHP и для несложных SQL запросов. В сложных случаях следует использовать Yii DAO.
Из документации.
vvv333 Сообщение 21/11/2012 15:14 Копия темы
Хорошо, спасибо за ответ.
ElisDN Сообщение 21/11/2012 15:54 Копия темы
Тормоза возникает при использовании жадной загрузки, то есть когда в запросе фигурируют поля из нескольких отношений (relations) сразу. Разница в том, что AR позволяет очень удобно работать с данными, а DAO – это простое написание запросов вручную. Отказываться от AR глупо. AR достаточно умна.

При особо сложных выборках удобно разбивать загрузку на два этапа: сначала делать выборку массива айдишников с DAO и потом подсовывать этот массив «в WHERE id IN (...)» AR (или вложенным SQL подзапросом). Что-то типа:

$criteria = new CDbCriteria();
$criteria->addInCondition('t.id', new CDbExpresiion('SELECT id FROM ... ', array(':param1'=>$val1)));
$items = Model::model()->findAll($criteria);

Так как жадная загрузка не используется, никаких JOIN'ов в AR не будет. При этом Вы полностью контролируете подзапрос и используете все прелести AR (методы, отношения и т.д.). Такой подход в совокупности с кэшем очень разгрузит БД.

А вообще, гадость на чём угодно сделать можно.
vvv333 Сообщение 21/11/2012 15:58 Копия темы
Спасибо Дмитрий за грамотный ответ.
Так наверное и будем делать.

А идея возникла и за красивого рецепта : yiiframework.ru/doc/cookb...
ElisDN Сообщение 21/11/2012 16:55 Копия темы
Ну это тоже удобно, только больше вещей придётся эмулировать вручную.
terrainc Сообщение 22/11/2012 21:05 Копия темы
Вы, кстати, знаете, что AR у Yii это само умеет делать ;)
www.yiiframework.com/doc/...
terrainc Сообщение 22/11/2012 21:11 Копия темы
Как уже сказали – AR+DAO.
90% задач AR решает. На моей практике прямые запросы применяются когда нужно перелопатить большие массивы данных и делать это хочется на стороне SQL сервера. Например, банальную загрузку дампа какого-нибудб каталога можно или читая файл на PHP и обновляя нужные модели – очень медленно, или загрузив этот файл во временную таблицу и несколькими сложными SQL запросами раскидать эти данные по нужным таблицам.
В большинстве же своем AR хватает.
ElisDN Сообщение 23/11/2012 07:46 Копия темы
Знаю. Но автор именно желает полностью контролировать запросы.
ElisDN Сообщение 23/11/2012 08:36 Копия темы
И это совсем не то. Я, например, хочу вывести топ-50 объявлений по введённому городу и имени, но без жадной загрузки города и автора. То есть такой выдуманный запрос: 

$items = Model::model()->findAll(array(
    'condition'=>'city.title LIKE :city AND profile.name LIKE :name',
    'params'=>array(':city'=>'%гра%', ':name'=>'%три%'),
    'limit'=>50,
    'with'=>array(
        'author',
        'author.profile',
        'city'
    ),
));

Никакие together здесь не помогут вообще. Если поля отношений присутствуют в condition, то эти таблицы автоматом подтянутся в запрос. То есть при любом шаманстве этот запрос с LIKE будет производиться по джойну четырёх таблиц (!), а не по одной без джойна:

SELECT * FROM `post` `t` LEFT OUTER JOIN `user` `author` ON (`t`.`author_id`=`author`.`id`) LEFT OUTER JOIN `userprofile` `profile` ON (`profile`.`id`=`author`.`id`) LEFT OUTER JOIN `post_city` `city` ON (`t`.`city_id`=`city`.`id`) WHERE (city.title LIKE '%гра%' AND profile.name LIKE '%три%') LIMIT 50

А нам бы хотелось выбрать из одной таблицы без джойнов. AR не достаточно умна, чтобы преобразовать это в такой трёхшаговый запрос:

SELECT * FROM post t WHERE city_id IN (SELECT id FROM city c WHERE c.name LIKE '%гра%') AND author_id IN (SELECT id FROM userprofile p WHERE p.name LIKE '%три%') LIMIT 50

А мы его можем собрать так:

$items = Model::model()->findAll(array(
    'condition'=>'t.city_id IN (SELECT id FROM {} c WHERE c.name LIKE :city) AND t.author_id IN (SELECT id FROM {} p WHERE p.name LIKE :name)',
    'params'=>array(':city'=>'%гра%', ':name'=>'%три%'),
    'limit'=>50,
));
terrainc Сообщение 23/11/2012 10:57 Копия темы
Во-первых, вам ничего не мешает сделать 3 джойна, прописав связь сразу на профайл.
Во-вторых, я бы вам советовал очень осторожно делать такие оптимизации. Джойны внутри мускуля оптимизируются много лучше и вполне может оказаться, что отказавшись от джойна в похерили производительность. google: mysql join vs subquery
vvv333 Сообщение 23/11/2012 11:14 Копия темы
Да именно так. Про релайшен в Yii я знаю. Уже прочитал не мало доков по этому фрейму. Но Именно и за таких громадных запросов как показали ниже, я и хотел попробовать DAO. Есть еще такой момент который я наверное ще не понял, например есть модель с релэйшыном, но мне в запросе он не нужен, а нужен чистый быстрый отор даных только из одной таблицы модели. Через AR же это вроде не получится сделать , или я не прав ?
ElisDN Сообщение 23/11/2012 12:23 Копия темы
Просто не используйте with(). yiiframework.ru/doc/guide...
ElisDN Сообщение 23/11/2012 12:33 Копия темы
В моём случае подзапросы с LIKE простые, поэтому они выполнятся всего один раз. А иначе будет куча джоинов и, в добавок, LIKE будет выполнятся к каждой строке?
vvv333 Сообщение 23/11/2012 12:42 Копия темы
Спасибо понял. Я перечитал мануал. И понял суть своего вопроса. Я просто несмотря на то что делал поиск без with() мог в представлении получать информацию о пользователе, по этому думал что он всегда подгружается, но теперь понял что это ленивая загрузка, и что я делал неправильно.
terrainc Сообщение 23/11/2012 13:12 Копия темы
Не, не будет. В данном случае планы выполнения будут весьма схожие.
Но вообще таким же способом можно критерий с джойном сделать, да и в связях можно дополнительные джойны описывать.
0

©2008 edogs egods
Выразить восторг, поругаться
или предложить что-нибудь можно на форуме
Для обсуждения этого сервиса так же есть темы на фрилансе по
поиску , флудотопу ,и по удалённым сообщениям ,и по Актуальным/популярным темам , и по топу "кто кому больше наотвечал"