Цитата (twin @ 8.04.2016 - 15:37) |
Ты считаешь, что память СУБД не важна? Ты глубоко заблуждаешься. Это как раз более тонкое место. |
сам спросил - сам ответил. На проектах которые заботятся о нагрузки обычно субд на отдельном сервере, следовательно логично задействовать потенциал отдельного сервера будет гораздо правильней или для вас подсчет суммы уже весьма сложное действие? Но грузить в пыху данные и после считать их это глупо.
TMakeОткрою тебе страшную тайну. СУБД всегда находится на отдельном сервере.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
twin к сожалению не всегда.
Цитата (TMake @ 10.04.2016 - 17:12) |
twin к сожалению не всегда. |
Ты просто не понимаешь сути. Ты имеешь ввиду не разные сервера, а разные машины. Сервера разные
всегда. Находиться на одной машине они могут. Но это сути не меняет, так как такие варианты даже рассматривать не стоит.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Цитата (twin @ 11.04.2016 - 05:46) |
Ты имеешь ввиду не разные сервера, а разные машины. |
да верно, на разных серверах (серверных машин).
Цитата (twin @ 11.04.2016 - 05:46) |
Но это сути не меняет |
в каком случае удобно считать сумму на стороне пыхе?
что может быть критичного в подсчете суммы на стороне субд?
Цитата (TMake @ 11.04.2016 - 06:50) |
что может быть критичного в подсчете суммы на стороне субд? |
Особо ничего. Смотря какой запрос. Я соственно не столько про это, сколько про
Цитата (TMake @ 8.04.2016 - 10:17) |
то что можно сделать через выборку ты тянешь в память, а потом считаешь. |
Не всегда это выгодно. Особенно если
Цитата (TMake @ 8.04.2016 - 10:17) |
например в подзапросе |
Цитата (TMake @ 11.04.2016 - 06:50) |
в каком случае удобно считать сумму на стороне пыхе? |
Если один запрос тяжелее чем несколько атомарных.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
twin в данном примере не нужно ни чего стягивать и считать, ты растянул тему как кота за хозяйство. То что я написал, что можно в под запросе это всего лишь намек на то куда смотреть и что это более правильней чем предлагали выше. Если подсчет суммы велик то ясное дело что на лету не стоит делать и стоит уже иметь поле в котором будет указана сумма пользоваться как статическими данными, или менять по событию. Или опять не верно?
Делать отдельными запросами которые будут лежать в кэш, я не особый сторонник такие данные возлагать на кэш, т.к. если запрос тяжелый, то нужно решать вопрос более кардинально, чем разбить на чуть менее тяжелыми запросами и хранить в кэш. Конечно есть такие выборки где нужно хранить в кэш, например в выборке для выдачи на странице, особенно если имеется какая та группировка и данные часто меняются и еще чаше пересекаются с др. выборками.
Хорошо. Давай не будем кота тянуть.
Покажи свое решение, я свое. И сравним по полочкам.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Цитата (twin @ 11.04.2016 - 15:57) |
Покажи свое решение, я свое. |
решение чего? я выше пост писал что твое решение может быть, так же как и мое, все зависит от задачи.
ты пытаешься развить холивар и уже не трогать проблему тс, создай тему, опиши задачу и сделай пруф, тогда можно будет померяться животами, усами и чем захочешь, если будет время. Вообще с тобой бесполезно спорить, ты любитель развести длинные темы где теряется весь смысл.
TMake
Ты заявил, что решение с обсчетом на стороне PHP - глупость. Прямо такими словами:
Цитата (TMake @ 10.04.2016 - 10:40) |
Но грузить в пыху данные и после считать их это глупо. |
А я тебе прямо заявляю - глупо так рассуждать.
Знавал я таких парней, которые все решали хранимыми процедурами, считая, что раз MySQL - отдельный сервер, то нужно его и грузить по полной.
Всегда нужно искать оптимальный вариант. И далеко не всегда выгодно вычисления производить на стороне субд.
О том я и сказал. Никаких холиваров я не хочу. Это и без них очевидно тем, кто хоть раз сталкивался с большими нагрузками.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Цитата (twin @ 11.04.2016 - 16:45) |
А я тебе прямо заявляю - глупо так рассуждать |
$city = array();
$result = mysql_query($query);
while($row = mysql_fetch_assoc($result)){
$city[ $row['gorod'] ] += $row['count'];
}
echo '<pre>';
print_r($city);
echo '</pre>';
напиши в чем ты увидел прелесть здесь?
Цитата (twin @ 11.04.2016 - 16:45) |
Знавал я таких парней, которые все решали хранимыми процедурами |
я к таким не отношусь, но поддержка таких проектов была. Не особо понятно с чего ты взял что я решаю через хранимые процедуры?
Цитата (twin @ 11.04.2016 - 16:45) |
Всегда нужно искать оптимальный вариант. И далеко не всегда выгодно вычисления производить на стороне субд. |
читай пост выше, писал уже что все от задачи зависит.
Цитата (twin @ 11.04.2016 - 16:45) |
О том я и сказал. Никаких холиваров я не хочу. Это и без них очевидно тем, кто хоть раз сталкивался с большими нагрузками. |
не буду пытаться тебя в чем то убеждать.
Цитата (TMake @ 11.04.2016 - 13:16) |
напиши в чем ты увидел прелесть здесь? |
Тут ни в чем. Но по условиям задачи перебор результатов все равно нужен. Почему в него не затолкать эту строчку:
$city[ $row['gorod'] ] += $row['count'];
Элегантно, легко и просто. Теперь покажи, как бы ты решал на уровне запроса. Вместе посмеемся.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Цитата (twin @ 11.04.2016 - 17:26) |
Теперь покажи, как бы ты решал на уровне запроса. Вместе посмеемся. |
я бы наверняка не на уровни запроса сделал, а вынес в отдельное поле, так что можешь начинать смеяться без меня
Цитата (TMake @ 11.04.2016 - 13:32) |
я бы наверняка не на уровни запроса сделал, |
Да? И когда ты это придумал?
А как же это:
Цитата (TMake @ 8.04.2016 - 10:17) |
Цитата (grey4eg @ 7.04.2016 - 21:41) Как можно подружить две группировки сразу?
например в подзапросе |
И потом. Как бы ты сделал, это вопрос второй. Ты заявил безапелляционно, что вычисления на уровне PHP - глупость. И что все нужно решать запросами. А теперь судорожно ищешь другие решения, причем не самые лучшие. Отдельное поле увеличит вес таблицы. И с целостностью данных геморроя можно хапнуть.
Ты если полез в драку, отвечай за слова.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Цитата (twin @ 11.04.2016 - 17:44) |
Ты заявил безапелляционно, что вычисления на уровне PHP - глупость |
верно в том примере которые выше, полная глупость вытаскивать в пыху и после считать через цикл.
Да и сам ты уже прокомментировал
Цитата (twin @ 11.04.2016 - 17:26) |
Тут ни в чем. |
Цитата (twin @ 11.04.2016 - 17:44) |
А теперь судорожно ищешь другие решения, причем не самые лучшие. |
с каких пор ты в тролли подался?
Цитата (twin @ 11.04.2016 - 17:44) |
Отдельное поле увеличит вес таблицы |
не думал что поле с типом integer очень много требует места, ты хоть немного работал с большим проектом?
Цитата (twin @ 11.04.2016 - 17:44) |
Ты если полез в драку, отвечай за слова. |

ты серьезно? корвалол не забудь как будешь ехать ко мне
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.