- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
iopiop, спрашивали ЧТО ЭТО, а не как пишут люди, которым неудобно писать SQL.
iopiop, спрашивали ЧТО ЭТО, а не как пишут люди, которым неудобно писать SQL.
ну а я спросил ЗАЧЕМ.
а вы зачем-то стали рассказывать про негарантированность порядка выдачи, хотя в данном случае она гарантирована
iopiop, разные варианты можно предположить.
Я бы использовал здесь подзапрос для того чтобы отделить логику от представления. На php останется только приделать шаблонный цикл не загромождая его дополнительно логикой в виде еще одной сортировки.
Ну и подзапросы не всегда плохие. Поэтому двойной order by никак не хуже.
Так же, я обратил внимание на слова "записи-то уже отсортированы" - это неверно. Если убрать самый внешний order by, то порядок выдачи не гарантируется (в абстрактной реализации SQL). На php массив реально придется сортировать, не просто вывести в обратном порядке. Этот код был бы неемкий и только загромождает все.
iopiop, разные варианты можно предположить.
Я бы использовал здесь подзапрос для того чтобы отделить логику от представления. На php останется только приделать шаблонный цикл не загромождая его дополнительно логикой в виде еще одной сортировки.
не нужно еще одной сортировки, уже все отсортировано
Ну и подзапросы не всегда плохие. Поэтому двойной order by никак не хуже.
Так же, я обратил внимание на слова "записи-то уже отсортированы" - это неверно. Если убрать самый внешний order by, то порядок выдачи не гарантируется (в абстрактной реализации SQL). На php массив реально придется сортировать, не просто вывести в обратном порядке. Этот код был бы неемкий и только загромождает все.
ключевое слово "если". мы-то не рассматриваем коня в вакууме. "если" убрать селект, так вообще ничего выводиться не будет, не так ли? а "если" дроп поставить, так вообще таблица исчезнет ;-)
iopiop, просто покажи где в SQL92 прямо или косвенно написано, что ORDER BY указанный в подзапросе ДОЛЖЕН (а не может) привести к выдаче отсортированного результата во внешнем запросе. ну или любой другой доступный стандарт на SQL.
А убрать SELECT - это уже нарушение стандарта. Тогда ТОЧНО не будет ничего выводить.
Этот программист опирался на те вещи, которые явно зафиксированы, а не на экспериментальные данные о поведении mysql. И его код будет работать правильно во всех версиях mysql. А на что опирается твой вариант?
iopiop, просто покажи где в SQL92 прямо или косвенно написано, что ORDER BY указанный в подзапросе ДОЛЖЕН (а не может) привести к выдаче отсортированного результата во внешнем запросе. ну или любой другой доступный стандарт на SQL.
загадками говорите. при чем здесь SQL92, если я как раз и предлагаю подзапрос выбросить?
А убрать SELECT - это уже нарушение стандарта. Тогда ТОЧНО не будет ничего выводить.
Этот программист опирался на те вещи, которые явно зафиксированы, а не на экспериментальные данные о поведении mysql. И его код будет работать правильно во всех версиях mysql. А на что опирается твой вариант?
ну мне не сложно еще раз повторить
у какого вендора СКЛ этот запрос может работать не правильно (с поправкой на синтаксис ессно, limit -> top) ?
iopiop, теперь понял. ну если вообще избавиться, то всегда будет сортирован.
вот только ради чего? вывод в обратном порядке - отход от привычного шаблона, потенциальные ошибки и непонимание со стороны других программистов.
ето потому что тут задача изначально нестандартная - самые свежие записи должны снизу :-)
так что тут наоборот разрыв шаблона случится, как так, выводить надо наоборот, а шаблон стандратный :-)