Я прекрасно понимаю, как эти сервисы работают. Но фишка в том, что эти признаки косвенные. Потому к результатам нужно относиться соответственно.
Далее: если вы прочитаете комментарий, на который я отвечал, то вы поймёте, что в данном случае все ваши эвристики вообще работать не будут (благо на РОРе, да и любом другом фреймворке) клиент-сайд и урлы можно организовать как угодно.
Вполне вероятно. У меня пока для себя любимого в списке подарков на НГ:
a) htc 8s
b) iphone 4 (который стоит немного дороже, но зато экосистема там знакомая и устоявшаяся)
c) бросить заниматься фигнёй, продолжить использовать SE Elm, а деньги потратить на что-то действительно нужное
Хотел тоже его купить себе (как первый смартфон — до сих пор пользовался просто телефонами, в данный момент — Sonyericsson Elm), но как-то начитался о проблемах с со старшим HTC 8x и обеими люмиями, и как-то перехотелось превращать пользование телефона в бесконечные квесты :-)
> А что? Нормальная аналогия. Часто эффективнее выбирать данные по частям, чем сразу все. К сожалению, MySQL не поддерживает server-side cursors =(
Я в моей аналогии выражал другое, скорее не то, что не нужно выбирать много за раз, а что вообще не нужно выбирать много совсем. Никогда.
> Ещё один часто встречающийся пример: залить таблицу из бэкапа на боевом, скажем, слэйве. 100,000 записей. Имеет смысл разбить на несколько транзакций?
Зависит от задачи. Если с таблицей больше никто не работает — то 1 транзакция лучше. Но я с mysql давно уже не работаю плотно. В оракле 1 транзакция была бы лучше и правильнее.
Совет «не забываем закрывать транзакции» смысл имеет.
Совет «делайте транзакции короче» — нет. Никто в здравом уме не будет делать транзакции длиннее чем нужно. И наоборот — короче чем есть транзакцию сделать нельзя, потому что бизнес требует, чтобы определённые операции выполнялись в единой транзакции. Так что делать её короче — значит не выполнять бизнес-требования.
PS: я комментирую исходя из того, что программисты руководствуются здравым смыслом и понимают, что делают.
PPS: ещё аналогия — «делайте транзакции короче» это то же самое что и «выбирайте меньше записей» (в случае, например, если мы реализуем экспорт и нам физически нужно выбрать все записи).
Этот совет выглядит как «составляйте имена переменных подлиннее, чтобы наверняка не создать ещё одну переменную с таким же именем».
Транзакции должны быть такими, какими должны быть, не длиннее, не короче. Длина транзакции должна трактоваться бизнес-задачей и здравым смыслом. Слепое следование совету «короче-лучше» ни к чему хорошему не приведёт.
Тут дело в другом. вместо MIN(t.rgt) вы могли написать хоть AVG(42) и оно работало бы точно так же :-)
Т.е. я говорил не о том, что оно совершенно не дружит со стандартами, а о том, что в случае использования конструкции HAVING любая_агрегирущюая_функция(с_любым_аргументом_кроме_NULL) всегда будет возвращаться первая строка резалт сета.
Т.е. с MAX(t.rgt) вернётся тот же самый результат.
Но тут фишка в том, что конструкция `HAVING MIN(t.rgt)` работает не так, как автор считает. И ему просто повезло, что записи с минимальным t.rgt идут первыми.
Потому лучше увиденную конструкцию забыть и не вспоминать :-)
ps: а пользоваться ORDER BY + LIMIT 1
pps: в подавляющем большинстве популярных субд (постгре, sql server, оракл) запрос автора будет считаться некорректным и даже не выполнится.
Далее: если вы прочитаете комментарий, на который я отвечал, то вы поймёте, что в данном случае все ваши эвристики вообще работать не будут (благо на РОРе, да и любом другом фреймворке) клиент-сайд и урлы можно организовать как угодно.
a) htc 8s
b) iphone 4 (который стоит немного дороже, но зато экосистема там знакомая и устоявшаяся)
c) бросить заниматься фигнёй, продолжить использовать SE Elm, а деньги потратить на что-то действительно нужное
Вот и я в замешательстве :-)
Особенно огорчили пляски вокруг батарейки: forums.wpcentral.com/htc-8x/203318-battery-tricks-tips-htc-8x.html
www.guardian.co.uk/technology/datablog/interactive/2012/feb/28/undersea-internet-cable-map-interactive
img179.imageshack.us/img179/3374/seacablehibq4.jpg
en.wikipedia.org/wiki/List_of_international_submarine_communications_cables
ps: ветренность веллингтона преувеличивают :-)
ps: привет из облачного велика :-)
$sum = 1.005*$i->itsum;Магические константы — зло. Что такое 1.005? Почему именно столько? А вот если бы это была обычная именованная константа, то вопросов бы не возникло.
ps: если комиссия в 0.5% берётся с суммы $sum, то вы всё равно получите меньше, чем ожидаете.
Т.е. itunes синхронизируется с плеером/телефоном и обратно.
Судя по всему я не совсем верно понял, что именно вы обсуждаете, тогда пардон.
Я в моей аналогии выражал другое, скорее не то, что не нужно выбирать много за раз, а что вообще не нужно выбирать много совсем. Никогда.
> Ещё один часто встречающийся пример: залить таблицу из бэкапа на боевом, скажем, слэйве. 100,000 записей. Имеет смысл разбить на несколько транзакций?
Зависит от задачи. Если с таблицей больше никто не работает — то 1 транзакция лучше. Но я с mysql давно уже не работаю плотно. В оракле 1 транзакция была бы лучше и правильнее.
Совет «делайте транзакции короче» — нет. Никто в здравом уме не будет делать транзакции длиннее чем нужно. И наоборот — короче чем есть транзакцию сделать нельзя, потому что бизнес требует, чтобы определённые операции выполнялись в единой транзакции. Так что делать её короче — значит не выполнять бизнес-требования.
PS: я комментирую исходя из того, что программисты руководствуются здравым смыслом и понимают, что делают.
PPS: ещё аналогия — «делайте транзакции короче» это то же самое что и «выбирайте меньше записей» (в случае, например, если мы реализуем экспорт и нам физически нужно выбрать все записи).
Этот совет выглядит как «составляйте имена переменных подлиннее, чтобы наверняка не создать ещё одну переменную с таким же именем».
Транзакции должны быть такими, какими должны быть, не длиннее, не короче. Длина транзакции должна трактоваться бизнес-задачей и здравым смыслом. Слепое следование совету «короче-лучше» ни к чему хорошему не приведёт.
Т.е. я говорил не о том, что оно совершенно не дружит со стандартами, а о том, что в случае использования конструкции HAVING любая_агрегирущюая_функция(с_любым_аргументом_кроме_NULL) всегда будет возвращаться первая строка резалт сета.
Т.е. с MAX(t.rgt) вернётся тот же самый результат.
Потому лучше увиденную конструкцию забыть и не вспоминать :-)
ps: а пользоваться ORDER BY + LIMIT 1
pps: в подавляющем большинстве популярных субд (постгре, sql server, оракл) запрос автора будет считаться некорректным и даже не выполнится.