ограничение кол-ва записей

← →
Viktor (2004-04-18 14:18) [0]

подскажите пожалуйста, как с помошью SQL запроса ограничить количество записей в выборке.

← →
Vlad © (2004-04-18 14:27) [1]

select first 5 ...

← →
Viktor (2004-04-18 14:32) [2]

спасибо.

← →
Vemer © (2004-04-18 15:32) [3]

Попутный вопрос - в 1-м диалекте SQL FIRST пашет?

← →
Vlad © (2004-04-18 16:01) [4]

> Vemer © (18.04.04 15:32) [3]

AFAIK - нет.

← →
Jack128 © (2004-04-18 16:09) [5]

> AFAIK - нет.
а практика показала, что да ;-)

← →
Johnmen © (2004-04-18 18:00) [6]

И теория и практика показывает, что в IB6 нет такой конструкции... И диалект тут непричем...
:)

← →
Viktor (2004-04-19 09:03) [7]

>Johnmen © (18.04.04 18:00) [6]

как же быть если юзаешь IB6?

← →
Nikolay M. © (2004-04-19 09:10) [8]

> Viktor (19.04.04 09:03) [7]
> как же быть если юзаешь IB6?

SELECT id, name
FROM table AS tab1
ORDER BY name
HAVING (SELECT count(1) FROM table AS tab2 WHERE tab2.name <= tab1.name) <= 20

← →
Johnmen © (2004-04-19 09:12) [9]

>Viktor (19.04.04 09:03) [7]

В чем проблема, что заставляет ограничивать ?
(Решений несколько, всё зависит от необходимости...)

← →
Reals © (2004-04-19 09:15) [10]

Можно еще попробовать SELECT TOP 10 * FROM Table1
В MSSQL это работает, в IB нет возможности проверить.

← →
Sergey13 © (2004-04-19 09:16) [11]

2Viktor (19.04.04 09:03) [7]
>как же быть если юзаешь IB6?

Работать над фразой where независимо от сервера БД.

← →
Anatoly Podgoretsky © (2004-04-19 09:18) [12]

Reals © (19.04.04 09:15) [10]
Может тогда не стоит советовать?
В ИБ6 не такой возможности ограничить количество записей кроме реляционных, или переходить на другую базу, хоть тот же ИБ но выше номером.

← →
Viktor (2004-04-19 09:56) [13]

>Johnmen © (19.04.04 09:12) [9]

запрос может возвращать очень большое количество данных (>100000 записей)

>Nikolay M. © (19.04.04 09:10) [8]

спасибо, сейчас попробую.

← →
Johnmen © (2004-04-19 09:58) [14]

>Viktor (19.04.04 09:56) [13]
>запрос может возвращать очень большое количество данных (>100000 записей)

А вот этого не должно быть. см.Sergey13 © (19.04.04 09:16) [11]

← →
Viktor (2004-04-19 10:11) [15]

>Johnmen © (19.04.04 09:58) [14]

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

← →
Anatoly Podgoretsky © (2004-04-19 10:16) [16]

Не позволять делать такие запросы, пусть вводит не менее 3 символов. Не хочет, тогда пусть ждет, можешь об этом его предупредить в диалоге. К тому же ограничение TOP все равно будет выполнять весь запрос, оно влияет только на количество данных возвращаемых клиенту, а для этого существует такое понятие как Fetch

← →
Johnmen © (2004-04-19 10:18) [17]

>Viktor (19.04.04 10:11) [15]

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

← →
Sergey13 © (2004-04-19 10:18) [18]

2Viktor (19.04.04 10:11) [15]
>пользователь в качестве условия отбора ввел символ "К"
Ну и пошли его на букву "Х", в смысле "не хватает информации для поиска".

>вот в этих случаях желательно иметь возможность ограничивать количество записей в выборке.
Это чем же это желательно? Запрос вернул 10000 записей, а юзер видит 5. Что он делает? Правильно - вводит нового. Хотя нужный был шестым. 8-)

← →
Nikolay M. © (2004-04-19 10:19) [19]

> теперь представим что пользователь в качестве условия отбора
> ввел символ "К" (название организации) вот в этих случаях
> желательно иметь возможность ограничивать количество записей
> в выборке

В этом случае желательно сделать предварительно SELECT count(1)... и, если записей больше 500-1000, вежливо послать пользователя "Задайте более строгое условие для поиска".

← →
Viktor (2004-04-19 10:23) [20]

>Anatoly Podgoretsky © (19.04.04 10:16) [16]

не позволять - это хорошо. только в моем случае наверное проще сделать ограничение. :-(
Fetch? К сожалению не знаком с этим понятием.

>Johnmen © (19.04.04 10:18) [17]
почему? запрос вернет всех покупателей у которых имя организации начинается на "К".

← →
Viktor (2004-04-19 10:25) [21]

>Johnmen © (19.04.04 10:18) [17]

вы имели в виду - неполны потому что "включено" ограничение?
да, но это будет решать сам пользователь.

в некотором смысле такой вариант и есть то о чем говорил Anatoly Podgoretsky © (19.04.04 10:16) [16]

не позволять - это хорошо. только в моем случае наверное проще сделать ограничение. :-(

Ну сделаешь ты ограничение. Что дальше?
Юзер ввел запрос LIKE "K%"
Запросу удовлетворяет 100 записей, а ты покажешь 10.
На основании этой выборки юзер сделает направильный вывод.
А именно твоя программа и предназначена помогать делать правильный вывод.
Нужна будет юзеру такая программа как у тебя?
Нафик не нужна

Nikolay M. © (19.04.04 10:19) [19]
Этот Count потребует столько же времени, сколько и выполнение запроса и без него, в итоге удвоение времени выполнения запроса. Речь конечно не о простых линейных запросах.
Надо бороться ограничениями на уровне пользователя, пусть он сам принимает решение, ждать ему или нет, ответив на это в диалоге, а определить необходимость этого несложно, если выборка идет по имени и указано мало буквЮ менее трех тогда запрашивать пользователя. Для простых запросов допустимо и Count сделать для предварительной оценки, конечно если запрос осуществляется доли секунды, иначе пользователь не поблагодарит за такую медвежью услугу. Решать в каждом конкретном случае индивидульно, но решение с подверждением пользователем очень эффективно, через некоторое время он начинает сам делать очень эффективные запросы.

Это могут подтвердить ведущие собаководы.

> если выборка идет по имени и указано мало буквЮ менее трех
> тогда запрашивать пользователя.

Это настолько очевидно, что я не стал этого писать. А если и неочевидно, то автор сам дойдет до этого после нескольких минут ожидания результатов поиска.

← →
Viktor (2004-04-19 10:49) [25]

Nikolay M. © (19.04.04 10:46) [24]
Хорошо если минут, а не часов, результатом будет аварийное снятие процесса со всеми вытекающими последствиями.

> результатом будет аварийное снятие процесса со всеми вытекающими
> последствиями.

Обычное дело, не первый раз замужем :)

← →
Женя (2004-04-19 12:23) [28]

Удалено модератором
Примечание: Задай свой вопрос в отдельной ветке

ограничение кол-ва записей Найти похожие ветки