Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2004.05.16;
Скачать: [xml.tar.bz2];

Вниз

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

 
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]


 
Reindeer Moss Eater ©   (2004-04-19 10:37) [22]

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

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


 
Anatoly Podgoretsky ©   (2004-04-19 10:42) [23]

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

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


 
Nikolay M. ©   (2004-04-19 10:46) [24]


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

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


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

>Nikolay M. ©  (19.04.04 10:46) [24]

уже дошел. :-)
всем спасибо.


 
Anatoly Podgoretsky ©   (2004-04-19 11:01) [26]

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


 
Nikolay M. ©   (2004-04-19 11:08) [27]


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

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


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

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



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2004.05.16;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.51 MB
Время: 0.039 c
1-1083578385
Петя
2004-05-03 13:59
2004.05.16
Handle dll


3-1082459816
Oksana
2004-04-20 15:16
2004.05.16
Обмен данными между таблицами MSSQL и лок. dbf-таблицами


3-1082345098
Orange
2004-04-19 07:24
2004.05.16
Сохранение базы данных


14-1082613968
Style
2004-04-22 10:06
2004.05.16
Помогите решить проблему?


14-1083060913
syte_ser78
2004-04-27 14:15
2004.05.16
ping





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский