Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Номер по порядку... [MSSQL]

Страницы: 1 2 3 4 >
MakNik © (2005-10-18 11:13:00)
Подскажите, пожалуйста, как в запросе прономеровать полученные строки по порядку?

isasa (2005-10-19 13:56:00) [1]
Сделать ПК автоинкрементный,
Все, устал. :)
Сквозная нумерация в рамках выборки (1000..5000).
Всего выборок 400000/(1000..5000)=400..80.

Danilka (2005-10-19 13:46:00) [2]
isasa © (19.10.05 13:30)
следует заводить физ. поле в таблице.

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

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

isasa (2005-10-19 13:30:00) [3]
следует заводить физ. поле в таблице.

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

Danilka (2005-10-19 13:09:00) [4]
[59] isasa © (19.10.05 12:08)

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

isasa (2005-10-19 12:08:00) [5]
Почему-то все оппоненты тупо уверены, что эта информация отображается еа экране.
На экране она никому не нужна, и, действительно, вредна(потенциальный источник ошибки).
Как будто, никто не сталкивался, например, с лоторейными билетами.
Печатаем на здоровом листе, разрезаем и раскладываем по номерам.

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

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

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

Danilka (2005-10-19 09:45:00) [6]
evvcom © (19.10.05 09:22)
угу, а куда девать join-ы с другими таблицами?

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

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

evvcom (2005-10-19 09:22:00) [7]

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

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

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

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

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

:)))

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

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

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

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

evvcom (2005-10-19 08:43:00) [11]

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

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

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

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

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

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

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

isasa (2005-10-18 17:53:00) [13]
а юзверю вообще неизвестно чего надо
Это не дружеский подход к интерфейсу пользователя. :)

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

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

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

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

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

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

Danilka (2005-10-18 17:20:00) [16]
[46] msguns © (18.10.05 16:49)

:))

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

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

evvcom (2005-10-18 17:05:00) [17]

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

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

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

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

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

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

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

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

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

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

Danilka (2005-10-18 16:44:00) [19]
isasa © (18.10.05 16:28)
В чем проблема-то, никак не пойму?
В то, что на клиенте нет ADOQuery.

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

Курдль (2005-10-18 16:41:00) [20]

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

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

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

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

Страницы: 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »