|
|
|
|
|
для: Trianon
(06.06.2009 в 23:35)
| | >не смотря на легкую ересь в этом фрагменте, там всё же не предлагается использовать HAVING
Зато с WHERE выдает конкретную ошибку. :) | |
|
|
|
|
|
|
|
для: Valick
(07.06.2009 в 00:16)
| | так и есть. | |
|
|
|
|
|
|
|
для: Trianon
(06.06.2009 в 23:35)
| | когда я читал, то понял так что HAVING применяется когда нужно поставить условие грубо говоря для результата выборки (группировки)
надо будет пречитать | |
|
|
|
|
|
|
|
для: tAleks
(06.06.2009 в 23:16)
| | не смотря на легкую ересь в этом фрагменте, там всё же не предлагается использовать HAVING вне группирующего запроса.
Да и вычисляемыми столбцами там похоже называют агрегирующие выражения (выражения с применением агрегатных функций) .
Не иначе как затем, чтоб неподготовленному читателю было проще понять... | |
|
|
|
|
|
|
|
для: Trianon
(06.06.2009 в 22:23)
| | Может Вы расскажете всё же, где выкопали эту идею?
Все в той же книжке. Стр. 115-116. :) | |
|
|
|
|
|
|
|
для: tAleks
(06.06.2009 в 21:33)
| | Похоже, нашел я нечто, проливающее свет на.
Note
In a SELECT statement, each expression is evaluated only when sent to the client. This means that in a HAVING, GROUP BY, or ORDER BY clause, you cannot refer to an expression that involves variables that are set in the SELECT list. For example, the following statement does not work as expected:
mysql> SELECT (@aa:=id) AS a, (@aa+3) AS b FROM tbl_name HAVING b=5;
The reference to b in the HAVING clause refers to an alias for an expression in the SELECT list that uses @aa. This does not work as expected: @aa contains the value of id from the previous selected row, not from the current row.
The order of evaluation for user variables is undefined and may change based on the elements contained within a given query. In SELECT @a, @a := @a+1 ..., you might think that MySQL will evaluate @a first and then do an assignment second, but changing the query (for example, by adding a GROUP BY, HAVING, or ORDER BY clause) may change the order of evaluation.
The general rule is never to assign a value to a user variable in one part of a statement and use the same variable in some other part of the same statement. You might get the results you expect, but this is not guaranteed.
Если излагать коротко - так не выйдет.
...
Общее правило - никогда не делать так, что значение присваивается переменной в одной части оператора и используется в другой части того же оператора. Возможно, Вы даже получите ожидаемый результат, но этого никто не гарантирует.
Про чудесное поведение having я как-то не узрел нигде, даже в в хеопсовой книжке.
Хотя я искал не очень дотошно. Может Вы расскажете всё же, где выкопали эту идею? | |
|
|
|
|
|
|
|
для: tAleks
(06.06.2009 в 21:33)
| | пожалуй, придется пойти приобрести такой же травы скачать эту удивительную книгу.... | |
|
|
|
|
|
|
|
для: Trianon
(06.06.2009 в 21:21)
| | > Ну и что с того? В разделе WHERE нельзя помещать выражения?
Нельзя помещать вычисленные значения. | |
|
|
|
|
|
|
|
для: tAleks
(06.06.2009 в 21:04)
| | >> А по-моему Вам не нужен HAVING. Достаточно обычного WHERE.
>WHERE здесь точно не подойдет, потому что today_lesson это вычисляемое значение, а не столбец паблицы.
Ну и что с того? В разделе WHERE нельзя помещать выражения?
>> И это всё в контексте оператора SELECT?
>Ну да, а что в этом такого необычного?
Ничего обычного. Я просто пытаюсь понять, в каком разделе руководства искать описание синтаксиса этой конструкции. | |
|
|
|
|
|
|
|
для: Trianon
(06.06.2009 в 20:48)
| | > А по-моему Вам не нужен HAVING. Достаточно обычного WHERE.
WHERE здесь точно не подойдет, потому что today_lesson это вычисляемое значение, а не столбец паблицы.
> И это всё в контексте оператора SELECT?
Ну да, а что в этом такого необычного? | |
|
|
|
|