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

← →
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]

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

← →
Danilka © (2005-10-18 16:44) [45]

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

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

← →
msguns © (2005-10-18 16:49) [46]

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

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

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

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

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

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

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

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

← →
evvcom © (2005-10-18 17:05) [47]

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

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

← →
Danilka © (2005-10-18 17:20) [48]

[46] msguns © (18.10.05 16:49)

:))

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

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

← →
isasa © (2005-10-18 17:27) [49]

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

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

← →
msguns © (2005-10-18 17:33) [50]

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

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

← →
isasa © (2005-10-18 17:53) [51]

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

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

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

← →
Danilka © (2005-10-19 08:08) [52]

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

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

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

← →
evvcom © (2005-10-19 08:43) [53]

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

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

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

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

← →
Anatoly Podgoretsky © (2005-10-19 09:08) [54]

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

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

← →
Danilka © (2005-10-19 09:12) [55]

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

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

← →
Danilka © (2005-10-19 09:13) [56]

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.

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