Вложенные запросы при помощи Zend_Db_Select

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

Вложенные запросы при помощи Zend_Db_Select

Ну до этого все понимали, что я просто привёл пример вложенного запроса. Или у вас всегда расстреливают за них вне зависимости от того увеличивают они быстродействие или нет? =)

Zend Framework: стремимся к MVC для Javascript, CSS

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

Жёстко подключая только один файл вы слегка облегчаете себе жизнь. Если страница имеет сложный клиентский интерфейс, тогда файлов по-хорошему будет много (склеивание в один, сжатие — это другой вопрос для production варианта). Идея высказанная выше про папку в таком случае намного лучше.

Ускоряем разработку ч.1 (Расиширяем Zend_Db_Table)

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

Если пришло пусто, значит где-то шагом или несколькими шагами раньше сформировалось это пустое значение как результат какой-то ошибки. Без использования исключений отловить её будет очень непросто.

Ускоряем разработку ч.1 (Расиширяем Zend_Db_Table)

Речь о поиске. Имеется в виду, что typeId в array(1,...,5), но тот метод работает только с 2мя из них (такая у него специфика, такое бывает).

Но как быть если данный метод используется в 10ти местах стразу и везде на входные данные наложены одни теже ограничения? Писать отдельный метод валидации для этого поиска тоже не выглядит очень логично.

Ускоряем разработку ч.1 (Расиширяем Zend_Db_Table)

С таким простым случаем я согласен — если условие задано таким, что ничего не возвращает, то метод должен продолжить своё выполнение и вернуть значение. Но если передан пустой идентификатор, то это тоже нарушает правила использования функции.

Ускоряем разработку ч.1 (Расиширяем Zend_Db_Table)

> А в данном случае метод должен вернуть 0, он ведь не затронул ни одну строку?
С этим согласен, но я другое имею в виду. Допустим есть функция с 2мя параметрами: id, typeId, sortKey. Я проверяю, что id > 0, typeId в array(1, 2). Если id < 0, то не будет записи и в принципе ничего страшного. В тоже время передавая typeId не в заданном диапазоне я не получу данных, но это не то, т.к. в этом случае функция в принципе неправильно используется.

Вложенные запросы при помощи Zend_Db_Select

Сдаётесь? =)

Ускоряем разработку ч.1 (Расиширяем Zend_Db_Table)

А в чём будет разница между выходом из функции с null вместо результата или выброса исключения в этом месте? Человек который потом будет использовать эту функцию по тексту поймёт что пошло не так, а получив не то значение потратит ещё уйму времени на определение причины.

Согласен, что не стоит делать проверку if(count($result) > 0) { чтобы бросить исключение — здесь ясно, что ничего не найдено, но вот throw new Exception(«Необходимо указать id для выбора элемента»); что-то вроде этого намного правильнее, чем return null;.

Вы согласны?

Ускоряем разработку ч.1 (Расиширяем Zend_Db_Table)

> throw new Exception(«Необходимо указать id обновляемого элемента»);
Это будет лишнее?

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

Исключения при правильном использовании более информативны.

Ускоряем разработку ч.1 (Расиширяем Zend_Db_Table)

А где на ваш взгляд грань между использованием исключений и возвращаемых значений? С наборами всё ясно, но в случае если входные данные указаны неправильно — логичнее использовать исключения, тогда результирующее значение получено всё равно не будет.

Ускоряем разработку ч.1 (Расиширяем Zend_Db_Table)

Согласен, что это не бизнес логика. И всё же это некоторое ужесточение правил работы с таблицами, которые лучше закладывать в модель, на мой взгляд. Но вы правы в одном — если это делает кому-то работу с данными удобнее, то имеет право на жизнь. Мне же хватает доступных методов для работы с картой базы.

Ускоряем разработку ч.1 (Расиширяем Zend_Db_Table)

Я это понимаю. Поэтому и говорю, что не имеет особого смысла расширять функциональность шлюза до логики модели.

Вложенные запросы при помощи Zend_Db_Select

Но это всё равно не спасёт от сложных условий.

Вложенные запросы при помощи Zend_Db_Select

Думаете зря потратили время? =)

Ускоряем разработку ч.1 (Расиширяем Zend_Db_Table)

Абсолютно согласен по поводу того, что намного удобнее, когда методы имеют одно и тоже название при условии, что выполняют одинаковые функции. Но на этом можно и остановиться. Основная проблема всех методов, предложенных выше заключается в том, что модель = таблица, а это зачастую не так. Поэтому лучше создать интерфейс для модели, в котором описать все основные методы (при этом я подразумеваю, что одна модель работает сразу с несколькми таблицами), и работать с таблицами через защищённые свойства, например.

Приведу небольшой пример: есть процесс, параметры и связь процесса с параметрами. В этом случае логичнее создать одну модель процесса, которая будет работать с данными трёх таблиц и реализовать в ней методы, описанные в статье. Разница будет в том, что в этих методах будут использоваться зачастую уникальные конструкции (в этом и будет заключаться моделирование процесса).

Вложенные запросы при помощи Zend_Db_Select

Ну зато потом можно будет юзать для любого запроса. Только в случае миграции на какую-нить другую БД они порушатся…

Вложенные запросы при помощи Zend_Db_Select

Я полностью согласен, что ясность теряется абсолютно. Просто задумался… все основные логические операции введены и не может так получаться, что какое-то условие реализовать нельзя. =)

Вложенные запросы при помощи Zend_Db_Select

Дык может и SQL_CALC_FOUND_ROWS будет как-то поддерживаться. А пока можно расширить класс для себя, добавив свою константу следующим образом:

class My_Db_Select extends Zend_Db_Select
{
  const SQL_CALC_FOUND_ROWS = 'sql_calc_found_rows';

  public function __construct(Zend_Db_Adapter_Abstract $adapter)
  {
    self::$_partsInit = array_merge(array(
      self::SQL_CALC_FOUND_ROWS => false
    ), self::$_partsInit);
    parent::__construct($adapter);
  }

  public function calcFoundRows($flag)
  {
    $this->_parts[self::SQL_CALC_FOUND_ROWS] = (bool)$flag;
    return $this;
  }
}

* This source code was highlighted with Source Code Highlighter.

Не проверил работоспособность, но логика правильная.

Вложенные запросы при помощи Zend_Db_Select

> ->where('((A or (B and C)) and D) or E)')
Кстати, можно раскрыть скобки (A and D or B and C and D or E) и записать при помощи соответствующих методов:

$query = $db->select()
      ->from('test')
      ->where('A')
      ->where('D')
      ->orWhere('B')
      ->where('C')
      ->where('D')
      ->orWhere('E');
echo $query->assemble();

* This source code was highlighted with Source Code Highlighter.

Получим:

SELECT `test`.* FROM `test` WHERE (A) AND (D) OR (B) AND (C ) AND (D) OR (E)

* This source code was highlighted with Source Code Highlighter.

Приоритеты операций — наше всё =)