SQL-запрос

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

WebDesignStudio, если сомневаетесь что такое количество там есть - то не значит, вот если там нет такого количества - то да, экономия на спичках будет неоправдана.

Цитата ("uniq-ip"):

SET @i:=0, @max:=0;
SELECT @i:=IF(milan='+', @i+1, 0), @max:=IF(@i>@max ,@i, @max) FROM table;

Как-то так.

Спасибо! Все работает.

Цитата ("WebDesignStudio"):

Цитата (uniq-ip):
SET @i:=0, @max:=0;
SELECT @i:=IF(milan='+', @i+1, 0), @max:=IF(@i>@max ,@i, @max) FROM table;

Как-то так.

а зачем так издеваться то?

это не извращения это норм. когда идет интенсивная работа с большим кол. данных.
И это элем. запрос.


Цитата ("SmartDesign"):

WebDesignStudio, не только вы, до тех пор пока в таблице нет миллионов записей - нет никакого смыал уносить это в БД. Скриптом это проще-гибче-нагляднее.

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

Как-то все сложно... А если проще? Как пример, подобная выборка из моей таблицы.

$sql = "select count(*) as `cnt`, `rubric_id` from `mytab` where `title` like '%р%' group by `rubric_id` order by `cnt` desc limit 1";

$rs = mysql_query($sql);

if ($rs and mysql_num_rows($rs)) {

	while ($row = mysql_fetch_assoc($rs)) {

		echo $row.'='.$row.'<br />';

	}

}

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

$sql = "select count(*) as `cnt`, `rubric_id` from `mytab` where `title` like '%р%' group by `rubric_id` order by `cnt` desc limit 1";

$rs = mysql_query($sql);

if ($rs and mysql_num_rows($rs)) {

   while ($row = mysql_fetch_assoc($rs)) {

      echo $row.'='.$row.'<br />';

   }

}

VS

SET @i:=0, @max:=0;

SELECT @i:=IF(milan='+', @i+1, 0), @max:=IF(@i>@max ,@i, @max) FROM table;

Короче не значит проще)
Тем более, что выборка без внешних условий выполняется быстрее.

Gritskif, это надо еще тестировать как оно будет работать. Цитата ("Gritskif"):

Есть только один аргумент - PHP ложит выделенный сервер если обрабатывать данные скриптом, а не SQL запросами

это не совсем правильно.

Цитата ("Gritskif"):

Спасибо! Все работает.

Не за что. К такому виду запроса просто пришлось прибегнуть в своё время, т.к. perl-у в какой-то момент просто перестало хватать оперативки (не говоря уж о создаваемой им нагрузке) при обработке подобной таблицы.

uniq-ip, перестаньте выбирать сразу все результаты запроса в скрипте =) Памяти будет хватать.
Gritskif, ПХП ложит сервер? Скорее всего дело в том как написан скрипт.

SmartDesign, работа через скрипт всегда более затратна, в смысле ресурсов, чем работа непосредственно с СУБД.
По аналогии из жизни: работа через посредника более накладна, чем напрямую

Цитата ("uniq-ip"):

По аналогии из жизни: работа через посредника более накладна, чем напрямую

иногда дешевле кому то заплатить что бы сделал работу, чем самому научится как это сделать, вам это не кажется? Тут примерно такая же ситуация. Может скорость там и будет на каких то 0.1% выше, но поддерживать такую систему будет сложнее, не говоря уже о переносе.

WebDesignStudio, при больших таблицах выигрыш в скорости может быть и на порядок выше.
Вы, для эксперимента, пройдитесь скриптом по таблеце, скажем в 100.000.000 строк, а потом сравните с проходом самой СУБД - разница будет существенной.

Цитата ("uniq-ip"):

Вы, для эксперимента, пройдитесь скриптом по таблеце, скажем в 100.000.000 строк, а потом сравните с проходом самой СУБД - разница будет существенной.

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

Цитата ("uniq-ip"):

SmartDesign, работа через скрипт всегда более затратна, в смысле ресурсов, чем работа непосредственно с СУБД.
По аналогии из жизни: работа через посредника более накладна, чем напрямую

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

Более того, если эти данные нужно получать часто - то каждый раз их получать нельзя и нужно делать кеш (использовать другого посредника).

WebDesignStudio, пример дал ТС. Поэкспериментируйте с большими таблицами.
SmartDesign, просто подумайте: СУБД работает в любом случае, а вот скрипт - это доп. нагрузка.

Цитата ("uniq-ip"):

Поэкспериментируйте с большими таблицами.

я не думаю что у ТЗ миллион записей. Дайте реальный пример который требует такого усложнения

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

WebDesignStudio, сделайте таблицу из примера ТС в 100.000.000 записей.
SmartDesign, в нашем случае СУБД делает примерно те же операции, что делал бы и скрипт. Т.е. СУБД в любом случае подключается к таблице и читает оттуда данные.
Вы предлагаете передать эти данные скрипту, на что уйдет время и дополнительные ресурсы API - и это будет работать быстрее по-Вашему?
Или Вы хотите выкинуть из цепочки СУБД и сделать так, чтобы скрипт обращался напрямую к файлам таблицы: индексному файлу, файлу данных и т.п. Если нет, то о чем спор?

Цитата ("uniq-ip"):

WebDesignStudio, сделайте таблицу из примера ТС в 100.000.000 записей.

зачем? Мне просто интересен пример из жизни где такое понадобиться.

WebDesignStudio, в любом случае перебор таблицы в СУБД будет быстрее, чем при помощи скрипта. А эксперимент проведите, чтобы в этом не только качественно, но и количественно убедиться