Номер по порядку...

← →
MakNik (2005-10-18 11:13) [0]

Подскажите, пожалуйста, как в запросе прономеровать полученные строки по порядку?

← →
Johnmen © (2005-10-18 11:16) [1]

А зачем?
Просто интересно...

← →
Ega23 © (2005-10-18 11:32) [2]

Через временную таблицу с добавлением Identity(1,1).
Как один из вариантов.

З.Ы. Присоединяюсь к Johnmen © (18.10.05 11:16) [1]

← →
evvcom © (2005-10-18 11:49) [3]

> Просто интересно...

По-моему, в WEB это используется довольно часто.

← →
isasa © (2005-10-18 11:57) [4]

А зачем?
Динамически получить порядковый номер записи в выборке.

← →
Slider007 © (2005-10-18 11:59) [5]

isasa © (18.10.05 11:57) [4]
RecNo ?

← →
stone © (2005-10-18 12:01) [6]

> evvcom © (18.10.05 11:49) [3]
>
> > Просто интересно...
>
> По-моему, в WEB это используется довольно часто.

Для чего?

← →
Johnmen © (2005-10-18 12:03) [7]

> isasa © (18.10.05 11:57) [4]
> А зачем?
> Динамически получить порядковый номер записи в выборке.

А зачем?

← →
Ega23 © (2005-10-18 12:03) [8]

2 Slider007 © (18.10.05 11:59) [5]

>
> isasa © (18.10.05 11:57) [4]
> RecNo ?

Не у всех потомков TDataSet будет работать. У TQuery, например - не будет. У TRxQuery - будет работать, но если нет BLOB-полей в выборке.
Короче, будет работать у тех потомков TDataSet, которые на ActiveChanged полностью выобрку фетчат.

← →
MOA © (2005-10-18 12:04) [9]

http://www.sql.ru/faq/faq_topic.aspx?fid=126
Удачи!

← →
isasa © (2005-10-18 12:20) [10]

> Динамически получить порядковый номер записи в выборке.
А зачем?

Для печати порядкового номера на персонализируемой странице(direct mail). Если какой-нибудь урод уронит пачку, можно легко собрать по порядковам номерам.

← →
Johnmen © (2005-10-18 12:27) [11]

>isasa © (18.10.05 12:20) [10]
>Для печати порядкового номера...

Для печати есть др.нормальные средства.

>...номера на персонализируемой странице(direct mail). Если какой-нибудь урод уронит пачку, можно легко собрать по порядковам номерам.

Не понял, это про что?

ЗЫ
Это обсуждение регулярно возникает.
Идеологически, данный номер не нужен (бесполезен). ИМХО.

← →
isasa © (2005-10-18 12:37) [12]

Идеологически, данный номер не нужен (бесполезен). ИМХО.
Печать со слиянием - письма одного содержания с разними обращениями и адресами. Переменная информация - SQL выборка (в крайнем случае View).
Должны лежать в определенном порядке. В случае смешивания, должны легко идентифицироваться и раскладываться.

Ты еще предложи GUID на них печатать.

← →
Sergey13 © (2005-10-18 12:45) [13]

2[12] isasa © (18.10.05 12:37)
>В случае смешивания, должны легко идентифицироваться и раскладываться
Для идентификации обычно используют нечто, что хранится. Для печати номер по порядку хранить не обязательно.

← →
dmitry501 © (2005-10-18 12:55) [14]

isasa © (18.10.05 12:20) [10]
<offtop> Рекомендуемый способ отвечать на "direct mail"-
http://www.vertical-visions.com/_temp/postagepaid/index2.html
</offtop>

← →
isasa © (2005-10-18 12:55) [15]

Для печати номер по порядку хранить не обязательно.

isasa © (18.10.05 11:57) [4]
Динамически получить порядковый номер записи в выборке.

А я о чем?

← →
isasa © (2005-10-18 13:06) [16]

dmitry501 © (18.10.05 12:55) [14]
:)
Это проблемы заказчика и его клиента.

← →
msguns © (2005-10-18 13:08) [17]

http://delphimaster.net/view/3-1129092338/

Такое впечатление, что некоторым Мастерам больше нечего делать, как навязывать всем подряд свое имхо

← →
evvcom © (2005-10-18 13:39) [18]

> stone © (18.10.05 12:01) [6]
>
> > evvcom © (18.10.05 11:49) [3]
> >
> > > Просто интересно...
> >
> > По-моему, в WEB это используется довольно часто.
>
> Для чего?

А сам прикинь, даже на этом сайте. Если посту в топике еще можно присвоить постоянный номер, то при выводе постов в конференции, они сначала должны отсортироваться по времени, а потом выбраться с такого-то по такой-то номер в зависимости от запрошенной страницы.

← →
Курдль © (2005-10-18 14:10) [19]

> Ega23 © (18.10.05 11:32) [2]
> Через временную таблицу с добавлением Identity(1,1).

Это что, шутка? 8-()

select number(), T.* from TABLE_NAME T
select rownum, T.* from TABLE_NAME T

← →
Ega23 © (2005-10-18 14:16) [20]

Это что, шутка? 8-()

Нет, не шутка.
Что такое number() и rownum?

← →
Курдль © (2005-10-18 14:17) [21]

> Что такое number() и rownum?

Я привел 2 рабочих запроса для Sybase и oracle. Неужели MS SQL не имеет аналога?

← →
Ega23 © (2005-10-18 14:21) [22]

> Я привел 2 рабочих запроса для Sybase и oracle. Неужели
> MS SQL не имеет аналога?

Нет. А зачем?

← →
Курдль © (2005-10-18 14:25) [23]

> Ega23 © (18.10.05 14:21) [22]
> Нет. А зачем?

Чтобы, как просил автор:

> ...в запросе прономеровать полученные строки по порядку

8-)

← →
Ega23 © (2005-10-18 14:28) [24]

>
> Чтобы, как просил автор:

Через временную таблицу с добавлением поля Identity(1,1)
Чем плох вариант?

← →
Курдль © (2005-10-18 14:31) [25]

> Ega23 © (18.10.05 14:28) [24]
> Через временную таблицу с добавлением поля Identity(1,1)
> Чем плох вариант?

Вы все шутите! :) Временная таблица - это уж совсем когда кризис жанра!
Вариант плох тем, что дергается функция Identity и создается временная таблица!

← →
Ega23 © (2005-10-18 14:32) [26]

Временная таблица - это уж совсем когда кризис жанра!

С фига-ли? Отличный инструмент, постоянно использую.

← →
Курдль © (2005-10-18 14:36) [27]

> Ega23 © (18.10.05 14:32) [26]
> С фига-ли? Отличный инструмент, постоянно использую.

За последние лет 5 - ни разу не понадобилось извращаться через временные таблицы. Правда я все больше по ораклу и сайбэйсу.

← →
Ega23 © (2005-10-18 14:42) [28]

> За последние лет 5 - ни разу не понадобилось извращаться
> через временные таблицы. Правда я все больше по ораклу и
> сайбэйсу.

В MS SQL это нормальный инструмент. Стандартный способ, так сказать...

← →
Sergey13 © (2005-10-18 14:43) [29]

2 [27] Курдль © (18.10.05 14:36)
Для Оракла ты привел запрос, который будет работать нормально только без сортировки. Если переделать его в
select rownum, * from (select)
то это будет практически аналог временной таблицы.
ИМХО

← →
Курдль © (2005-10-18 14:51) [30]

> Sergey13 © (18.10.05 14:43) [29]
> 2 [27] Курдль © (18.10.05 14:36)
> Для Оракла ты привел запрос, который будет работать нормально
> только без сортировки.

Как это понимать? Также нормально будет работать, только уже новые номера будут соответствовать другим записям.

> Если переделать его в
> select rownum, * from (select)
> то это будет практически аналог временной таблицы.

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

← →
Sergey13 © (2005-10-18 14:55) [31]

2 [30] Курдль © (18.10.05 14:51)
> Как это понимать?
Так и понимать. RowNum вычисляется при выборке записей и до сортировки. Если после сортировки все правильно, то тебе просто повезло.

← →
Ega23 © (2005-10-18 15:04) [32]

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

А я и так могу получить всё одним запросом. Через ХП. :о)

← →
msguns © (2005-10-18 15:20) [33]

извращенцы..
Неужели неясно, что № нужен только для отображения.

← →
msguns © (2005-10-18 15:21) [34]

Удалено модератором

← →
isasa © (2005-10-18 15:28) [35]

Неужели неясно, что № нужен только для отображения.
А какая разница. Он должен присутствовать в выходном потоке, как равноправное поле. Вот и все.

← →
Danilka © (2005-10-18 15:33) [36]

isasa © (18.10.05 15:28)
Неужели неясно, что № нужен только для отображения.
А какая разница. Он должен присутствовать в выходном потоке, как равноправное поле. Вот и все.

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

← →
Ega23 © (2005-10-18 15:47) [37]

В конце-концов никто не мешает написать своего потомка, например, TClientDataSet.

← →
evvcom © (2005-10-18 16:02) [38]

> Еслит только для отобращения, то он может "присутствовать
> в выходном потоке" как калькулирующее поле, например. Другой
> вариант, думаю не ошибусь, если скажу, что у всех существующих
> генераторов отчетов

Ну какое калькулирующее поле? Ну кто говорит про генератор отчетов? Как к примеру написать запрос для вывода такой странички:
http://www.delphimaster.ru/cgi-bin/forum.pl?n=1&p=2 ?

← →
isasa © (2005-10-18 16:21) [39]

Посмотрел, сколько у меня "временные" файлы занимают(С фига-ли? Отличный инструмент, постоянно использую. :))) ) - 4,5G (между прочим на SCSI HDD) - 22,5% общего объема.

← →
Danilka © (2005-10-18 16:22) [40]

evvcom © (18.10.05 16:02)

> Еслит только для отобращения, то он может "присутствовать
> в выходном потоке" как калькулирующее поле, например. Другой
> вариант, думаю не ошибусь, если скажу, что у всех существующих
> генераторов отчетов

Ну какое калькулирующее поле? Ну кто говорит про генератор отчетов? Как к примеру написать запрос для вывода такой странички:
http://www.delphimaster.ru/cgi-bin/forum.pl?n=1&p=2 ?

Я не пойму, зачем запрос, когда все делается элементарно на клиенте, за время, на порядок меньше времени существования этой ветки?
Как ты будешь формировать эту страничку? Я полагаю, открываешь набор данных и последовательно проходишь все записи, формируя эту страничку. При этом, в качестве номера ты можешь либо использовать ADOQuery.RecNo, либо заведя переменную-счетчик, которую обнуляешь перед циклом, в цикле прибавляешь по единичке и использешь на свое здоровье при формировании странички.
В чем проблема-то, никак не пойму?

← →
isasa © (2005-10-18 16:28) [41]

В чем проблема-то, никак не пойму?
В то, что на клиенте нет ADOQuery.

← →
Sergey13 © (2005-10-18 16:32) [42]

Интересно, автор хотя бы читает это? 8-)

← →
Курдль © (2005-10-18 16:41) [43]

> В чем проблема-то, никак не пойму?

Я прочувствовал эту проблему, когда пользовал какие-то навороченные, но и требовательные компоненты отображения типа гридов. Им обязательно надо было привязаться к уникальному целочисленному полю, иначе они работали в усеченном режиме

> Sergey13 © (18.10.05 16:32) [42]
> Интересно, автор хотя бы читает это? 8-)

Мы тут не ради счастья авторов бьемся, а ради ИСТИНЫ!!! :)))
.

← →
alex_*** (2005-10-18 16:41) [44]

что-то на клиенте же есть. в какой-то набор данные ловятся

isasa © (18.10.05 16:28)
В чем проблема-то, никак не пойму?
В то, что на клиенте нет ADOQuery.

А что есть на клиенте тогда? Ты уж не темни, говори что там есть, а я так уж и быть, разжую, как из того что есть на клиенте сделать нумерацию постов, не используя всякую ерунду в запросах.
:)

>Danilka © (18.10.05 16:22) [40]
>Я не пойму, зачем запрос, когда все делается элементарно на клиенте, за время, на порядок меньше времени существования этой ветки?

Осподи, хоть один здравомыслящий на всю ветку нашелся (не считая меня ;)))

Какое к лешему "калькулирующее" поле ?
Какие нафиг временные НД ?

Вы че, с дуба рухнули ?

А если юзер пересортирует нафик свой НД ? Чисто у себя на компе, то что, сервер должон у себя перемолотить весь энтот временный НД ?

Другой пример: есть вьха, которую смотрит надцать человек и каждый не всю ее, а подмножество (запрос типа селест фром вью), к тому упорядоченное как им захотелось.
И что, сервак должен создать надцать временных НД и за каждым вот это следить, чтоб чисто перенумеровать ?

Блин, ну хлебом не корми дай поспорить на "вечные" темы типа "Номер документа" или "нумерация строк"

Безельники - МАРШ РАБОТАТЬ !!!
ВСЕХ УВОЛЮ !!!!!!!!!!!

> Я не пойму, зачем запрос, когда все делается элементарно
> на клиенте, за время, на порядок меньше времени существования
> этой ветки?
> Как ты будешь формировать эту страничку? Я полагаю, открываешь
> набор данных и последовательно проходишь все записи, формируя
> эту страничку.

Вот этого как раз и не надо делать на клиенте! А если у тебя запрос вернет миллион строк? Для этого и придумано в SQL множество различных функций и прочих прибамбасов, чтобы не тащить на клиента миллион строк, не грузить сетку под самое не балуйся, а отсечь еще на сервере то, что клиенту пока не нужно.

[46] msguns © (18.10.05 16:49)

:))

[47] evvcom © (18.10.05 17:05)
Вот этого как раз и не надо делать на клиенте! А если у тебя запрос вернет миллион строк? Для этого и придумано в SQL множество различных функций и прочих прибамбасов, чтобы не тащить на клиента миллион строк, не грузить сетку под самое не балуйся, а отсечь еще на сервере то, что клиенту пока не нужно.

Вообще о разных вещах говорим.
Я имею ввиду случай, когда есть запрос, который возвращает только необходимые записи.
Пример - вывести все посты этой ветки.
И эти записи надо пронумеровать.
Только их. А не все, что есть в исходной таблице.

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

Вопрос в другом
который возвращает только необходимые записи.
содержащие порядковый номер записи в выборке в отдельном поле.

>isasa © (18.10.05 17:27) [49]
>Вопрос в другом
>содержащие порядковый номер записи в выборке в отдельном поле.

А вот этот "порядковый номер записи" точно нафиг никому не нужен. Ибо серверу вообще плевать на любой "порядок", а юзверю вообще неизвестно чего надо (по крайней мере серверу). Об этом знает клиентское приложение. Вот пусть оно и заморачивается на этот счет.

а юзверю вообще неизвестно чего надо
Это не дружеский подход к интерфейсу пользователя. :)

Об этом знает клиентское приложение.

Особенно задалбывает, насколько клиентских приложений, делающих одну и ту же выборку... в каждом из которых...

[49] isasa © (18.10.05 17:27)
который возвращает только необходимые записи.
.....
И эти записи надо пронумеровать.
Это решается тривиально.

Вопрос в другом
который возвращает только необходимые записи.
содержащие порядковый номер записи в выборке в отдельном поле.

Хм, вообще ниразу с такой задачей не встречался и не могу представить ее необходимость.
Я могу понять, когда есть таблица с автоинкрементным ПК и нам надо выводить значение ключа в отчеты/грид и т.д.
Но когда есть какая-то выборка, котора пронумерована и из нее делают еще одну выборку... в чем полезность такого? Я только вред вижу, например, когда удалили какую-то запись из таблицы в выборке и вся нумерация сдвинулась...

> Хм, вообще ниразу с такой задачей не встречался и не могу
> представить ее необходимость.

Я недавно встретился с необходимостью. Написал select, возвращающий дерево (в Оракле это connect by) - по смыслу полное меню, потом по inner join соединил с другой выборкой - менюшек, которые могут быть доступны текущему пользователю (там еще много было условий, не важных для этого поста), ну а потом надо всю эту выборку-результат отсортировать нужным образом. Как? Так и пришлось первый select нумеровать и уже по этому номеру сортировать результат.

> в чем полезность такого? Я только вред вижу, например, когда
> удалили какую-то запись из таблицы в выборке и вся нумерация
> сдвинулась...

Заметь, в вышеприведенном примере мне начхать на то, что нумерация может куда-то "сдвинуться". :)
Есть другие идеи, как реализовать такое?

Danilka © (19.10.05 08:08) [52]
Но когда есть какая-то выборка, котора пронумерована и из нее делают еще одну выборку... в чем полезность такого? Я только вред вижу, например, когда удалили какую-то запись из таблицы в выборке и вся нумерация сдвинулась...

Очень весело выглядят эти обсуждения по телефону - Варя что это у тебя за ерунда в записи под номером 5, да все в порядке, выдано 5 чайников. Какие к черту чайники, ты же списала три стола.

evvcom © (19.10.05 08:43)
Заметь, в вышеприведенном примере мне начхать на то, что нумерация может куда-то "сдвинуться". :)
Есть другие идеи, как реализовать такое?

Заметь, в твоем примере также нет никакой необходимости передавать это поле на клиента, не так-ли? :)
Коме того, твоя задача решается просто и другими средствами - перед connect by prior ставишь условие WHERE EXISTS (...), и неизвестно еще, что будет быстрее - твой или мой способ. :)

Anatoly Podgoretsky © (19.10.05 09:08)
Очень весело выглядят эти обсуждения по телефону - Варя что это у тебя за ерунда в записи под номером 5, да все в порядке, выдано 5 чайников. Какие к черту чайники, ты же списала три стола.

:)))

> Заметь, в твоем примере также нет никакой необходимости
> передавать это поле на клиента

Ну, тут ты прав.

> и другими средствами - перед connect by prior ставишь условие
> WHERE EXISTS (...),

угу, а куда девать join-ы с другими таблицами?

evvcom © (19.10.05 09:22)
угу, а куда девать join-ы с другими таблицами?

Ну, тут конечно только 2 варианта - либо твой, либо вытаскивать необходимые поля подзапросами, чем больше таких полей, тем более привлекательный твой вариант.
Да вобщем-то никто и не спорит на счет полезности rownum в запросах, например есть мастер-таблица: счет, есть детальная таблица - оплата счета, как правило, один счет оплачивается одной оплатой, но может быть вариант, когда оплат несколько. Пользователи просят в мастер-таблицу добавить поле - номер и дата оплаты. Причем, если оплат несколько, то показывать любую.
Решается элементарно: делаем подзапрос, в котором указываем условие where rownum=1.

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

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

Вариант два.
Имеем одного клиента. Печатает письма, по два на А4. Потом режем и раскладываем в пачки по номерам для конвертовальной машины.
Переменную информацию выбирает Word-ом - печать со слиянием.

Имеем второго клиента. Печатает сопроводительную документацию на эти письма(по 35 писем в одном документе) - Excel.

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

[59] isasa © (19.10.05 12:08)

Честно говоря, не очень-то понял твои примеры, но по-моему, если нужна сковзная нумерация и выборки внутри нее, следует заводить физ. поле в таблице.
Шоб небыло проблем, как в случае с Варей, чайниками и тремя столами. :)

следует заводить физ. поле в таблице.

В таблице 400000 записей. Каждая выборка 1000..5000 записей двум клиентам. Естественно они используют один и тот-же запрос. Как потом разгребать номера среди 400000?

isasa © (19.10.05 13:30)
следует заводить физ. поле в таблице.

В таблице 400000 записей. Каждая выборка 1000..5000 записей двум клиентам. Естественно они используют один и тот-же запрос. Как потом разгребать номера среди 400000?

В смысле, что значит "разгребать"? Сделать ПК автоинкрементный, его и использовать..

Сделать ПК автоинкрементный,
Все, устал. :)
Сквозная нумерация в рамках выборки (1000..5000).
Всего выборок 400000/(1000..5000)=400..80.

Номер по порядку... Найти похожие ветки