Как DESC LIMIT 3 вывести в цикле нарастающей а не по убыванию

@Афган · Регистрация: 12.01.2015

Студворк — интернет-сервис помощи студентам

Это выводит по убыванию а мне надо нарастающей, например в базе 100 записей сейчас выводит 100,99,98 а мне надо 98,99,100. база постоянно обновляется, и по этому мне надо вывести 3 последние записи нарастающей форме.

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
//Выводим данные из базы mysql
$resultat = mysql_query("SELECT * FROM chat ORDER BY id DESC LIMIT 3",$db);
$array = mysql_fetch_array($resultat);
do
{
echo '<div class="div_chat">'.
        '<div>'.
            $array['chat_name'].
            '<span style="float:right">'.$array['chat_date'].'</span>'.
        '</div>'.
        //Функция ищет в тексте обозначения смайликов и заменяет на картинки   
        '<br>'.$newtext = str_replace($smail, $grafic, $array['chat_textarea']).
     '</div>';   
}
while($array = mysql_fetch_array($resultat));

@pav1uxa · 15.02.2015, 11:19

Сообщение от Афган

Это выводит по убыванию а мне надо нарастающей

Убрать DESC Из SQL запроса

@Афган · 15.02.2015, 11:41 **[ТС]**

напиши как ты его уберёшь ?

@SkoTi · 15.02.2015, 13:23

Сущетсвует противоположная сторона. Это ASC

ASC = 1 2 3 4 5 6
DESC = 6 5 4 3 2 1
ps. с текстами тоже также рабтает в плане алфавита.

@pav1uxa · 15.02.2015, 13:46

Сообщение от Афган

напиши как ты его уберёшь ?

Очень тяжелая процедура. Нужно мышкой выделить слово "DESС", нажать кнопочку Delete и сохранить файл...

@Афган · 15.02.2015, 13:52 **[ТС]**

Сущетсвует противоположная сторона. Это ASC

ASC = 1 2 3 4 5 6
DESC = 6 5 4 3 2 1
ps. с текстами тоже также рабтает в плане алфавита.

Я знаю, но у меня много сообщений которые надо вывести последние, а с ASC только все выводить, мне все не надо только допустим 3 последние а цикл начинает считывать DESC 6 5 4 и по этому мои сообщения последние наверху в диве, а мне надо чтобы внизу было последнее. Надо чтобы DESC читал (или другой способ) 4 5 6 и шестое сообщение как раз будет внизу.

@Jewbacabra · 15.02.2015, 14:28

Сортировка по id - плохое решение.

SQL
1
SELECT * FROM (SELECT * FROM chat ORDER BY id DESC LIMIT 3) ORDER BY id ASC

@Афган · 16.02.2015, 10:59 **[ТС]**

Сортировка по id - плохое решение.

Почему ? и какой способ лучше ?

Добавлено через 4 минуты

Очень тяжелая процедура. Нужно мышкой выделить слово "DESС", нажать кнопочку Delete и сохранить файл...

Ч то такое мышка? как вы делить слово ? что такое Delete? как сохранить фаил ?
продолжай нести чуш (pav1uxa)

Добавлено через 6 минут

PHP
1
SELECT * FROM (SELECT * FROM chat ORDER BY id DESC LIMIT 3) ORDER BY id ASC

как это понимать ???

Добавлено через 15 часов 18 минут

Сортировка по id - плохое решение.

Код SQL
1
SELECT * FROM (SELECT * FROM chat ORDER BY id DESC LIMIT 3) ORDER BY id ASC

Зачем вы сами себе ставите (Сообщение было отмечено автором темы, экспертом или модератором как ответ ) это не так прочтите внимательнее вопрос.

Это выводит по убыванию а мне надо нарастающей, например в базе 100 записей сейчас выводит 100,99,98 а мне надо 98,99,100. база постоянно обновляется, и по этому мне надо вывести 3 последние записи нарастающей форме

Добавлено через 7 минут
DESC: выводит 10,9,8,7,6,5,4,3,2,1
ASC: выводит 1,2,3,4,5,6,7,8,9,10 (это вы посчитали за ответ, это не ответ)
Надо: выводить 8,9,10 не 10,9,8 а (8,9,10)
Вопрос актуален как это реализовать ?

@Jewbacabra · 16.02.2015, 15:38

Сообщение от Афган

Зачем вы сами себе ставите

Во-первых я себе ничего не ставил.
Во-вторых может сперва нужно попробовать разобраться с тем как это работает?
Разве что я забыл добавить имя к вложенному запросу

KOPOJI · 16.02.2015, 17:30

Сообщение от Jewbacabra

Сортировка по id - плохое решение

Чем?

Сообщение от Jewbacabra

SQL
1
SELECT * FROM (SELECT * FROM chat ORDER BY id DESC LIMIT 3) ORDER BY id ASC

Можно еще укоротить

SQL
1
(SELECT * FROM chat ORDER BY id DESC LIMIT 3) ORDER BY id ASC

Тогда и алиас можно не добавлять..

@Jewbacabra · 16.02.2015, 18:14

Сообщение от KOPOJI

Чем?

id не для этого предназначен
Захочет TC поменять две строчки местами, придется id менять, данный id может использоваться в других таблицах, там тоже менять. Логичнее было бы добавить дату создания добавления и сортировать по ней

KOPOJI · 16.02.2015, 18:27

Сообщение от Jewbacabra

id не для этого предназначен

Он как раз предназначен для уникальной идентификации. Почитайте про ключ PRIMARY - что это такое и с чем его едят, как говорится..

Сообщение от Jewbacabra

Захочет TC поменять две строчки местами, придется id менять, данный id может использоваться в других таблицах, там тоже менять

Это неверно, id не должен меняться. ID в SQL - это именно уникальный идентификатор, а не просто идентификатор (как я уже говорил выше). Собственно, его вообще не должны трогать модифицирующими запросами.
Иначе, представьте такую ситуацию.
Вот есть у вас интернет-магазин, который торгует множеством разнообразных товаров.
И была у вас запись с id=357 (из головы), и эта запись про молоток с фиберглассовой рукояткой.
Была еще одна запись, про кухонный комбайн, с id 358. Предположим, что поисковик уже проиндексировал эти страницы (раз уж мы определились с тематикой), они хранятся у него в БЗ/БД. Вы взяли и поменяли их местами. В итоге, получаем следующее:
1 ситуация: я хочу гвозди в стенку позабивать, сунулся - а молоток сломался

Я к вам на сайт - а мне по запросу "молоток" вылезает.. ..комбайн, который мне нафиг не нужен.
2 ситуация, обратная: хочу купить кухонный комбайн, а мне предлагают молоток (несмотря на то, что я заходил на страницу с описанием комбайна).
Результаты сих действий:
1) Нерелевантность сайта => падение позиций в поисковиках (переиндексация и т.п. + возможно штрафные баллы)
2) Я ухожу с сайта, который предлагает мне какую-то фигню вместо искомого, друзьям и знакомым тоже сообщу при необходимости свое мнение.
Что, в итоге, совместно с первым пунктом выйдет в падение прибыли, и, следовательно, программа является "глючной", некачественной продукцией.

@Jewbacabra · 16.02.2015, 18:33

Сообщение от KOPOJI

Он как раз предназначен для уникальной идентификации

Вот именно, идентификации а не упорядочивания

Сообщение от KOPOJI

Это неверно, id не должен меняться.

А где я написал, что так надо делать?
А вот напрмер такая ситуация: У меня выводится значения в порядке 8 9 10, но по каким-либо причинам захотелось 8 10 9. И если данные упорядочены по ид, кроме изменения ид другого варианта не вижу, а в сообщении выше ты написал почему это плохо. Если бы упорядочивание производилось по дате, достаточно было бы поменять только ее, не трогая ид

KOPOJI · 16.02.2015, 18:48

Сообщение от Jewbacabra

идентификации а не упорядочивания

одно другому не мешает. Ключ создается не просто так -> поиск будет куда оптимальнее, нежели по дате.

Сообщение от Jewbacabra

где я написал, что так надо делать?

Сообщение от Jewbacabra

Захочет TC поменять две строчки местами, придется id менять, данный id может использоваться в других таблицах, там тоже менять

Собственно, уже и по этому предложению виден еще один минус данного подхода - придется везде искать этот id и менять (каскадное обновление).

Сообщение от Jewbacabra

по каким-либо причинам захотелось 8 10 9

Это не такая уж и тривиальная "хотелка". Чаще всего хотят либо как есть, либо отсортированно, либо в случайном порядке.

Сообщение от Jewbacabra

Если бы упорядочивание производилось по дате, достаточно было бы поменять только ее, не трогая ид

Т.е., в любую таблицу мне надо лепить дату?

Может, у меня это чисто "таблица-разгрузчик" РБД с тремя полями (или вообще обычная табличка с категориями - id, category). Зачем мне таблица с категориями, которые еще и с датой?)
Далее. Опять же, захотелось добавить сортировку - пожалуйста. Так причем тут дата? Если надо, можно добавить специальное числовое поле `order` или наподобие, и сортировать по нему - будет куда лучше и быстрее, нежели сортировать дату.
Иначе, опять же, следует помнить про формат даты в конкретной СУБД (недавний пример - Преобразование строки в дату и сортировка выборки по полученной дате).
И еще. Сейчас вы захотите сортировать так, завтра так - это одно. А если у вас зависит от полученных GET-параметров? Вы на каждый GET-запрос будете делать подзапрос с UPDATE ? Это опять приведет все к той же нерелевантности запросу.
Вообще, про возможность подобной сортировки можно сказать насчет любого поля. И я в упор не вижу разницы между числом и датой (кроме как скорости поиска). На крайняк - имхо, лучше на стороне ЯП это организовать, чтоб сервер не гонять впустую.

@Афган · 16.02.2015, 19:56 **[ТС]**

Спасибо всем за участие.

@Jewbacabra · 16.02.2015, 20:58

Сообщение от KOPOJI

одно другому не мешает

Логически ключ никак не связан с упорядоченностью. То что id одной сущности id1 < id2 никакой смысловой нагрузки не несет. Кроме того сущности могут быть упорядоченны по нескольким параметрам, 1 id тут не обойтись.

Сообщение от KOPOJI

Собственно, уже и по этому предложению виден еще один минус данного подхода

Я изначально привел данный пример как нежелательный, но из-за сортировка по id приходит к нему, хотя есть более правильный подход

Сообщение от KOPOJI

Т.е., в любую таблицу мне надо лепить дату?

Не в любую, а в ту, сущности которой должны быть упорядочены по какому-либо критерию.
И не обязательно дату. Помимо даты могут быть любые количественные характеристики, как например, цена, масса, скорость и т.д, или упомянутый ваше order, это уже от задачи зависит

Сообщение от KOPOJI

опять же, следует помнить про формат даты в конкретной СУБД

опять же, подходящий формат нужно выбирать исходя из задачи

Сообщение от KOPOJI

И я в упор не вижу разницы между числом и датой

Не числом, уникальным идентификатором, повторюсь, логически не имеющий никакого отношения к упорядоченнности

Сообщение от KOPOJI

Это не такая уж и тривиальная "хотелка".

Почему-же? Интернет магазин. Добавили новые товары. На сайте магазина есть блок, в котором выводится N последних добавленных товаров. Менеджер, добавляя товары ошибся, и внес их в неправильном порядке. Начальство требует поставить их по другому. А программист реализовал их вывод таким способом:

SQL
1
SELECT * FROM products ORDER BY product_id DESC LIMIT 10

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

KOPOJI · 16.02.2015, 21:21

Сообщение от Jewbacabra

То что id одной сущности id1 < id2 никакой смысловой нагрузки не несет

То, что AUTO_INCREMENT генерируется в порядке возрастания, ничего не меняет? UPDATE не трогаем, говорим лишь про INSERT. Какую смысловую нагрузку вы желаете получить? "То что дата одной сущности date1 < date2 никакой смысловой нагрузки не несет" - имхо, вполне себе равнозначно (буковок больше разве). Только я еще могу спокойно поставить одинаковые даты, и гадать, какая должна вывестись первая. Кстати, а что вы собираетесь делать в таком случае? Вот есть у вас две разных записи с одинаковой датой. Составили запрос, он вывел в одном порядке. А вышеупомянутый начальник говорит "нет, хочу наоборот их видеть". И что? Дата - одна и та же. Менять ее нельзя (к примеру, дата добавления). При использовании id такой вариант невозможен в принципе. И, повторюсь, эти самые хотелки - "хочу так, а не иначе" крайне редки и нетривиальны. Если же это требуется - то изначально это обговаривается и добавляется соответствующее поле для сортировки.

Сообщение от Jewbacabra

Интернет магазин. Добавили новые товары. На сайте магазина есть блок, в котором выводится N последних добавленных товаров

На хорошем инет-магазине и десяток менеджеров не успеет забить поступившие пару миллионов товаров по каждой категории

Это давно уже все автоматизировано и товары для вывода определяет программа-скрипт, а не человек-менеджер.
Это высосанная из пальца проблема, чесслово.
Если продолжать далее, то таким макаром можно дойти до чего угодно - вплоть до того, что программист и не обязан был ни это делать, ни это предусматривать вообще. Есть в ТЗ - пожалуйста. Нет в ТЗ - до свидания. И никакой отсебятины не надо.
Повторюсь, если не требуется никакой сортировки, кроме вывода нескольких последних добавленных записей - то никакие дополнительные поля не нужны. Если требуется какой то супер-пупер отсортированный вывод - тогда используются дополнительные поля для сортировки (или сортировка на стороне ЯП). Но все это зависит от потребностей, а не хотелки. Здесь нет единого верного решения - и я это не отрицаю. Но нельзя однозначно сказать, что использовать id неверно. Я вот вам могу сказать, что из-за внесенного поля даты (например, DATETIME, + 8 байт на запись) база весит непомерно много. 1000000 записей * 8 байт = 8 мегабайт, грубо говоря. А зачем мне дополнительные 8 мегабайт на каждый миллион записей с каждой таблицы, где "может быть, когда-нибудь, будет использоваться сортировка - но вероятность стремится к нулю.." ? Десяток миллионов записей, плюс пара-тройка таких таблиц - и вот уже четверти гига нет..

@Jewbacabra · 16.02.2015, 21:38

Сообщение от KOPOJI

То, что AUTO_INCREMENT генерируется в порядке возрастания, ничего не меняет?

это физическая реализация уникальности ид. к тому же порядок в котором сущности добавлены не всегда соответствует их "логическому" порядку.

Сообщение от KOPOJI

То что дата одной сущности date1 < date2 никакой смысловой нагрузки не несет"

Предположим, что data - дата добавления сущности в таблицу. Тогда data1 < date2 означает, что 1 сущность добавлена раньше 2.

Сообщение от KOPOJI

Это высосанная из пальца проблема, чесслово.

если не нравится интернет магазин, то заменить можно практически на что угодно, где есть вывод последних <чего-то-там>, и изменение их порядка

Сообщение от KOPOJI

Кстати, а что вы собираетесь делать в таком случае? Вот есть у вас две разных записи с одинаковой датой. Составили запрос, он вывел в одном порядке. А вышеупомянутый начальник говорит "нет, хочу наоборот их видеть". И что? Дата - одна и та же. Менять ее нельзя (к примеру, дата добавления).

Почему нельзя? Изменили на 1 секунду, и проблемы нет.

Сообщение от KOPOJI

что из-за внесенного поля даты (например, DATETIME, + 8 байт на запись) база весит непомерно много. 1000000 записей * 8 байт = 8 мегабайт

Рискну предположить, что эти 8 МБ по сравнению с остальными полями таблицы это капля в море. Опять же пример с товаром, если есть такое поле как "описание товара".

KOPOJI · 16.02.2015, 21:58

Сообщение от Jewbacabra

к тому же порядок в котором сущности добавлены не всегда соответствует их "логическому" порядку.

Зато для них всегда выполняется условие, что

Сообщение от Jewbacabra

1 сущность добавлена раньше 2

Априори. И не может получиться того, что там будут одинаковые значения. В случае с датой (особенно при использовании DATE, без TIME) этого гарантировать не сможет никто (кроме, конечно же, UNIQUE и всяких INSERT IGNORE / INSERT ON DUPLICATE).
А на названный вами логическим порядок ("человеческий", как его называют, или еще "natural") никто не смотрит. Тем более не понимаю, каким образом это связано с сортировкой..

Сообщение от Jewbacabra

Предположим, что data - дата добавления сущности в таблицу. Тогда data1 < date2 означает, что 1 сущность добавлена раньше 2.

Выше я про это писал, ну да ладно, повторюсь. Видоизменю ваше высказывание:
Предположим, что data - дата добавления сущности в таблицу, тип поля - DATE. За сегодня пришло миллион товаров. Тогда data1 == date2 означает что ...? Дата у них у всех будет одинаковая, абсолютно. И никакой сортировки тут не может быть в принципе: данные одинаковы, чего сортировать-то

Сообщение от Jewbacabra

Почему нельзя? Изменили на 1 секунду, и проблемы нет.

Да много почему может быть нельзя. Это могут быть данные, которые смотрятся снаружи. Это может быть сортировка по убыванию-возрастанию, как часто делают. Вы на каждый такой запрос будете писать UPDATE ?

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

Сообщение от Jewbacabra

Рискну предположить, что эти 8 МБ по сравнению с остальными полями таблицы это капля в море

С миру по нитке - голому рубаха (с). Да и есть такая фраза, как "Это было последней каплей"
Это просто-напросто нерациональная трата ресурсов. Зачем мне что-то, занимающее мою память, если я могу запросто обойтись и без этого, ничего не теряя при этом? Зачем мне эта самая последняя капля, пусть и теоретически?

@stepanenkoalex · 14.07.2016, 13:33

Подскажите пожалуйста.
Есть вывод из бд:

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<div id=\"statji_$myrow[0]\" name=\"statji_$myrow[0]\" class=\"statji\">&nbsp;\n";
                $db_query2 = "SELECT id, name, alias, upd, avatar, title, introtext FROM page_pages WHERE catid = '$myrow[0]' AND published = '1' ORDER BY sort, upd DESC LIMIT 0, 1000";
                $db_result2 = @mysql_query($db_query2, $db);
                if ( $myrow2 = @mysql_fetch_array($db_result2) ) {
                    
                    do $output_page .= '
 
                        <div class="blog">
                            <a href="statji/'.$myrow2[2].'" title="'.$myrow2[1].'">
                                <div class="blog_img" style="background-image: url('.$myrow2[4].')"></div>
                            </a>
                            <div class="blog_ling">
                                '.$myrow2[3].'&nbsp;|&nbsp;'.$myrow2[1]."<br/>
                            </div>
                            <div class=\"text_blog\">
                                <h2>$myrow2[5]</h2>
                                <div class=\"text\">
                                    $myrow2[6]
                                </div>
                            </div>
                        </div>
                        \n";
 
 
                    while ( $myrow2 = @mysql_fetch_array($db_result2) );
                }

сейчас выводятся все записи с 0 по 1000 - их очень много.

Хотелось бы разделить все записи слайдером.
то есть: DESC LIMIT 0, 10

при нажатии на <a href="next">:
DESC LIMIT 11, 20

и т.д.

Спасибо

Новые блоги и статьи Все статьи Все блоги /
Учёным и волонтёрам проекта «Einstein@home» удалось обнаружить четыре гамма-лучевых пульсара в джете Млечного Пути Programma_Boinc 01.01.2026 Учёным и волонтёрам проекта «Einstein@home» удалось обнаружить четыре гамма-лучевых пульсара в джете Млечного Пути Сочетание глобально распределённой вычислительной мощности и инновационных. . .	Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .	Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Нашел на реддите интересную статью под названием Anyone know where to get a free Desktop or Laptop? Ниже её машинный перевод. После долгих разбирательств я наконец-то вернула себе. . .	Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Рецензия / Мнение/ Перевод Нашел на реддите интересную статью под названием The Thinkpad X220 Tablet is the best budget school laptop period . Ниже её машинный перевод. Thinkpad X220 Tablet —. . .	PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .
Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .

@Афган -48 / 3 / 2 Регистрация: 12.01.2015 Сообщений: 182
	15.02.2015, 11:41 [ТС]
	напиши как ты его уберёшь ? 0

@SkoTi -15 / 10 / 6 Регистрация: 03.10.2012 Сообщений: 532
	15.02.2015, 13:23
	Сущетсвует противоположная сторона. Это ASC ASC = 1 2 3 4 5 6 DESC = 6 5 4 3 2 1 ps. с текстами тоже также рабтает в плане алфавита. 0

@Афган -48 / 3 / 2 Регистрация: 12.01.2015 Сообщений: 182
	16.02.2015, 19:56 [ТС]
	Спасибо всем за участие. 0

Как DESC LIMIT 3 вывести в цикле нарастающей а не по убыванию

Решение