Глупый, конечно, вопрос, но все же...
Alex Gotlib
Subj.
MS SQL 2000. Простая табличка. Простой запрос.
SELECT * FROM bla_bla WHERE bla = bla_bla_bla OFFSET xx LIMIT yy;
Облом. MS SQL 2000 не соответствует ANSI стандарту.
А как, пардон, быть тогда? Я с MS SQL по большому счету первый
раз связался, т.ч. прошу не материца. Интересует постраничный вывод
записей.
--
WBR, Alexander B. Gotlib,
mailto:al...@cca.usart.ru / ICQ# 13043204.
-|- -|-
Dmitry Kuzmenko
Alex Gotlib wrote:
> MS SQL 2000. Простая табличка. Простой запрос.
>
> SELECT * FROM bla_bla WHERE bla = bla_bla_bla OFFSET xx LIMIT yy;
>
> Облом. MS SQL 2000 не соответствует ANSI стандарту.
>
> А как, пардон, быть тогда? Я с MS SQL по большому счету первый
> раз связался, т.ч. прошу не материца. Интересует постраничный вывод
> записей.
с чего ты взял, что offset и limit - это СТАНДАРТНЫЕ конструкции SQL ???
А может, стандартные это first/skip ? Или rows/to ?
и вообще, ограничение выборки имеет смысл только при ORDER BY.
В твоем случае, без order by, это похоже на выбор "случайных" записей,
потому что порядок записей без order by не гарантируется ни в одной РСУБД.
--
Dmitri Kouzmenko, www.ibase.ru, 953-13-34
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Andrew Lesnichenko
> Hail there All!
>
> Subj.
>
> MS SQL 2000. Простая табличка. Простой запрос.
>
> SELECT * FROM bla_bla WHERE bla = bla_bla_bla OFFSET xx LIMIT yy;
>
> Облом. MS SQL 2000 не соответствует ANSI стандарту.
>
> А как, пардон, быть тогда? Я с MS SQL по большому счету первый
> раз связался, т.ч. прошу не материца. Интересует постраничный вывод
> записей.
>
--
Andrew Lesnichenko
Alex Gotlib
Tue, 20 Dec 2005 at 06:10 GMT Dmitry Kuzmenko wrote:
>> MS SQL 2000. Простая табличка. Простой запрос.
SELECT * FROM bla_bla WHERE bla = bla_bla_bla OFFSET xx LIMIT yy
ORDER BY bla-bla-bla;
>> Облом. MS SQL 2000 не соответствует ANSI стандарту.
>> А как, пардон, быть тогда?
DK> с чего ты взял, что offset и limit - это СТАHДАРТHЫЕ конструкции SQL ???
Скажем так, что MS SQL первый из более менее распространенных СУБД, с
которыми я сталкивался, не поддерживает данную конструкцию.
DK> и вообще, ограничение выборки имеет смысл только при ORDER BY.
Само собой с сортировкой. Hе суть важно. Вопрос в том, как должен
выглядеть запрос, которые буждет возвращать только yy записей начиная с
xx-ой.
Alex Gotlib
Tue, 20 Dec 2005 at 07:26 GMT Andrew Lesnichenko wrote:
>> SELECT * FROM bla_bla WHERE bla = bla_bla_bla OFFSET xx LIMIT yy;
AL> IMHO, постраничный вывод, это функция не сервера, а клиента.
Разумеется это задача клиента. А задача сервера по запросу отдать
ровно столько записей, сколько нужно для отображения текущей страницы.
Вопрос - как будет выглядеть такой запрос в контексте MS SQL 2000?
P.S.: Я прекрасно понимаю, что вполне можно дергать чохом все записи и
потом уже с ними возиться, как вздумается. Hо это не всегда удобно. Hе
всегда нужно. Да и вообще хотелось бы на будущее разобраться.
Dmitry Kuzmenko
Alex Gotlib wrote:
> Само собой с сортировкой. Hе суть важно. Вопрос в том, как должен
> выглядеть запрос, которые буждет возвращать только yy записей начиная с
> xx-ой.
ms sql books? online?
--
Dmitri Kouzmenko, www.ibase.ru, 953-13-34
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Alexander Goldun
> MS SQL 2000. Простая табличка. Простой запрос.
> SELECT * FROM bla_bla WHERE bla = bla_bla_bla OFFSET xx LIMIT yy;
Так никто и не ответил? Вместо LIMIT используется TOP:
SELECT TOP yy * FROM bla_bla WHERE bla = bla_bla_bla
А вот для смещения не уверен, что это есть в MSSQL 2000 - не трогал его
ни разу.
Для MSSQL на эту тему есть FAQ, как раз про постраничную выборку:
http://sql.ru/faq/faq_topic.aspx?fid=105
Victor Metelitsa
> Hail there Dmitry!
>
> Tue, 20 Dec 2005 at 06:10 GMT Dmitry Kuzmenko wrote:
>
> >> MS SQL 2000. Простая табличка. Простой запрос.
>
> SELECT * FROM bla_bla WHERE bla = bla_bla_bla OFFSET xx LIMIT yy
> ORDER BY bla-bla-bla;
>
> >> Облом. MS SQL 2000 не соответствует ANSI стандарту.
> >> А как, пардон, быть тогда?
> DK> с чего ты взял, что offset и limit - это СТАHДАРТHЫЕ конструкции SQL ???
>
> Скажем так, что MS SQL первый из более менее распространенных СУБД, с
> которыми я сталкивался, не поддерживает данную конструкцию.
>
--
Alex Gotlib
Tue, 20 Dec 2005 at 11:13 GMT Victor Metelitsa wrote:
DK>> с чего ты взял, что offset и limit - это СТАHДАРТHЫЕ конструкции SQL ???
>> Скажем так, что MS SQL первый из более менее распространенных СУБД, с
>> которыми я сталкивался, не поддерживает данную конструкцию.
VM> Вау!?! А какие СУБД "это" поддерживают? (Примечание: СУБД, а не MySQL;-)
PostgreSQL, Oracle. Хватит?
Вы мне чего доказать то пытаетесь? Что если MS SQL такого не
поддерживает, то сие отсутствие есть рулез несусветный?
У меня был вполне конкретный вопрос - как оформить вполне
определенный запрос. Ответ я уже получил, причем даже со ссылкой на подробный
разбор подобных примеров.
Andrew Lesnichenko
> DK>> с чего ты взял, что offset и limit - это СТАHДАРТHЫЕ конструкции SQL ???
> >> Скажем так, что MS SQL первый из более менее распространенных СУБД, с
> >> которыми я сталкивался, не поддерживает данную конструкцию.
> VM> Вау!?! А какие СУБД "это" поддерживают? (Примечание: СУБД, а не MySQL;-)
>
> PostgreSQL, Oracle. Хватит?
В какой версии Oracle? В 7-8-9 такого нет.
> Вы мне чего доказать то пытаетесь? Что если MS SQL такого не
Полагают, что это нестандартная конструкция, очевидно...
PS. На вопрос, насколько я видел, уже ответили...
--
Andrew Lesnichenko
Alex Gotlib
Tue, 20 Dec 2005 at 13:19 GMT Andrew Lesnichenko wrote:
VM>> Вау!?! А какие СУБД "это" поддерживают? (Примечание: СУБД, а не MySQL;-)
>> PostgreSQL, Oracle. Хватит?
AL> В какой версии Oracle? В 7-8-9 такого нет.
Хммм, в самом деле. У меня почему то в памяти отложилось, что есть.
Hо по большому счету суть то не в этом. Оракл вполне себе дает возможность
порционной выборки данных, причем влегкую дает. Чтобы с MS SQL такого
добяться, нужно извращаться.
Hипарядок! :-)
>> Вы мне чего доказать то пытаетесь? Что если MS SQL такого не
AL> Полагают, что это нестандартная конструкция, очевидно...
Разве это не ANSI SQL стандарт?
AL> PS. Hа вопрос, насколько я видел, уже ответили...
Да. Я свою задачу уже решил.
Dmitry Kuzmenko
Alex Gotlib wrote:
> AL> Полагают, что это нестандартная конструкция, очевидно...
>
> Разве это не ANSI SQL стандарт?
например, некоторые думают, что ANSI SQL - это то, что поддерживает
MS Access.
в стандарте SQL-99 я не нашел таких конструкций, вообще.
В стандарте SQL 2002 есть конструкции ROWS/RANGE применительно
к концепции Window (см. window clause).
Кроме того, поскольку операция ограничения выборки никаким
образом не участвует в реляционной модели, поскольку там
используются операции над множествами (и order by как такового
в реляционной алгебре нет), то здесь конкретный синтаксис
зависит от производителя.
MySQL - offset, limit
Firebird - first, skip
InterBase - rows, to...
MS SQL - top
и так далее.
А еще стандарт SQL подразделяется на уровни. Entrly Level,
Intermediate и Full. Почти все коммерческие сервера поддерживают
целиком только Entry Level. Также все поддерживают те или иные
части Intermediate. И никто не поддерживает Full.
Если есть интерес к стандарту, купи себе справочник Грабера:
SQL Справочное руководство. Это не "Введение в SQL" или
"SQL" его же, а голый справочник, с перечислением уровней стандарта и т.п.
В инете не наблюдался никогда.
--
Dmitri Kouzmenko, www.ibase.ru, 953-13-34
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Alexander Goldun
>>Hо по большому счету суть то не в этом. Оракл вполне себе дает возможность
>>порционной выборки данных, причем влегкую дает. Чтобы с MS SQL такого
>>добяться, нужно извращаться.
>
> Hе понял. Разъясни.
А что тут разъяснять? Глянь сам ту ссылку, которую я давал:
http://sql.ru/faq/faq_topic.aspx?fid=105
и сравни "изящество" этих извратов с конструкцией типа
SELECT TOP nn START AT mm * FROM tablename ORDER BY...
Andrew Grachyov
Wednesday December 21 2005, Alexander Goldun writes to Pavel V. Pasechnik:
AG> А что тут разъяснять? Глянь сам ту ссылку, которую я давал:
AG> http://sql.ru/faq/faq_topic.aspx?fid=105
AG> и сравни "изящество" этих извратов с конструкцией типа
AG> SELECT TOP nn START AT mm * FROM tablename ORDER BY...
AG> -+- ifmail v.2.15dev5
AG> + Origin: (http://news.cca.usart.ru/) USURT's FidoNET<->
AG> (2:5080/1003@fidonet)
Сакpаментальный вопpос - "а на фига"? То есть, я не могу пpедставить себе
ситуацию, когда мне нужно вытащить запись из таблицы "с 21-й по 31-ю",
пpопустив пpи этом пеpвые 20 (то есть когда куpсоpом пользоваться неудобно).
Поясните, плз, зачем нужна такая констpукция?
Пока.
Andrew Grachyov.
Nick Gazaloff
Web-приложения.
--
Best regards,
Nick
(GPG Key ID: 4396B2D0)
Andrew Lening
AG> Поясните, плз, зачем нужна такая констpукция?
Постраничный вывод. В веб-приложениях, в частности. Притом что юзер может
посмотреть третью страницу, и не посмотреть при этом все остальные.
Bye.
Anton Baklanov
02 Января 2006 года ты писал(а) к Alexander:
AG> Сакpаментальный вопpос - "а на фига"? То есть, я не могу пpедставить
AG> себе ситуацию, когда мне нужно вытащить запись из таблицы "с 21-й по
AG> 31-ю", пpопустив пpи этом пеpвые 20 (то есть когда куpсоpом
AG> пользоваться неудобно).
AG> Поясните, плз, зачем нужна такая констpукция?
Для примера: хотя бы для экономия трафа. Даже по локольной сети.
Утверждение, что для 30 записей в таблице это не неужно, я согласен. А когда
_локальная_ сетка забиватеся трафом, изза кривых рук разработков - это вполне
реальная ситуация.
[√] Пока, Andrew, счастливого тебе коннекта ! ...
Alex Gotlib
Wed, 04 Jan 2006 at 13:00 GMT Vadim Rumyantsev wrote:
>>> Постраничный вывод. В веб-приложениях, в частности. Притом что юзер
>>> может посмотреть третью страницу, и не посмотреть при этом все
>> остальные.
VR>> Это ошибка в проектировании интерфейса пользователя. Откуда он узнает,
VR>> что ему нужна именно третья страница?
>> Во-первых, в самом деле может знать. Во-вторых, это может знать
>> не пользователь, а индексатор поисковой системы, который уже был на
>> сайте до пользователя.
VR> Тогда тем более содержимое базы с тех пор могло измениться, и
VR> пользователь
VR> попадёт не туда, куда хотел (типичная ситуация с некоторыми неграмотно
VR> спроектированными досками объявлений). В отличие от выборки по ключу.
А могло не измениться и пользователь попадет туда, куда хотел.
Без всякой выборки по ключам.
Фильтры по ключам это хорошо и удобно. Только вот зачастую
пользователь либо не знает, что конкретно фильтровать, либо намерянно
хочет листать именно все записи. Тут без постраничного вывода никак
Ты чего доказать то пытаешься? Что раз MS SQL такого не
позволяет нормально делать, то такое и не следует делать? :-)
>> В третьих, даже по подробному фильтру результат запроса может
>> получиться таким объемным, что все равно придется его разбивать по
>> страницам. Если конечно есть желание предоставлять пользователю удобный
>> интерфейс, а не абы какой.
VR> Я не против разбивки по страницам. Я говорю о том, что страницу должен
VR> идентифицировать диапазон ключей находящихся на ней записей, а не номер
VR> страницы.
Представь себе ситуацию. Вводит пользователь фильтр по ключам.
Результат выборки пять тысяч записей. Все пять тысяч будешь выводить?
--
WBR, Alexander B. Gotlib, mailto:al...@cca.usart.ru
ICQ: 13043204 / Jabber: al...@jabber.usurt.ru
-|- -|-
Alex Gotlib
Wed, 04 Jan 2006 at 17:11 GMT Vadim Rumyantsev wrote:
>> Представь себе ситуацию. Вводит пользователь фильтр по ключам.
>> Результат выборки пять тысяч записей. Все пять тысяч будешь выводить?
(*)
VR> Попробуй понять: выводить страницами. Hо на страницу ссылку давать не
VR> номером, а диапазоном ключей на этой странице.
VR>
VR> Hапример, если это список фамилий, то страницы называть не "1", "2",
VR> "3"..., а "Абрамов", "Васильев", "Дашин"... (или, сокращая до
VR> наименьшего различного, "А", "В", "Д"...).
VR>
VR> Тогда и запросы у тебя будут вида: ... WHERE FAMILY BETWEEN 'Абрамов' AND
VR> 'Васильев'.
См выше. Типичная ситуация, когда по такому запросу записи
нельзя показывать пользователю одним куском, а нужно делить на части.
Alex Gotlib
Wed, 04 Jan 2006 at 19:27 GMT Vadim Rumyantsev wrote:
>>> Представь себе ситуацию. Вводит пользователь фильтр по ключам.
>>> Результат выборки пять тысяч записей. Все пять тысяч будешь выводить?
>> (*)
VR>> Попробуй понять: выводить страницами. Hо на страницу ссылку давать не
VR>> номером, а диапазоном ключей на этой странице.
VR>> Hапример, если это список фамилий, то страницы называть не "1", "2",
VR>> "3"..., а "Абрамов", "Васильев", "Дашин"... (или, сокращая до
VR>> наименьшего различного, "А", "В", "Д"...).
VR>> Тогда и запросы у тебя будут вида: ... WHERE FAMILY BETWEEN 'Абрамов' AND
VR>> 'Васильев'.
>> См выше. Типичная ситуация, когда по такому запросу записи
>> нельзя показывать пользователю одним куском, а нужно делить на части.
VR> Hу и подели на части. Если у тебя вдруг пять тысяч Абрамовых - подели их
VR> по
VR> инициалам, затем по номеру паспорта, или как там вообще пользователь их
VR> различает. Автоматически подели, в своей программе, формирующей
VR> веб-страницы, а
VR> не в задаваемом пользователем фильтре. Иными словами, это не пользователь
VR> задаёт такой запрос, а твоя программа автоматически разбивает фамилии на
VR> поддиапазоны, увидев, что пользователь хочет посмотреть всех людей из
VR> базы.
Да. Именно так. Пользователь хочет посмотреть всех людей (в
твоем примере) из базы. Для чего это ему нужно, вопрос отдельный. Hо
это нужно постоянно. И разбиванием списка на поддиапазоны это не
решается. Пользователю не нужно разбивать на поддиапазоны, ему нужно
именно всех подряд в определенном порядке смотреть.
VR> Уж не знаю, как ещё объяснить :( Если вдруг задумаешь отвечать на это
VR> письмо,
VR> прочти ещё раз все предыдущие и попытайся понять, что в них написано.
По-моему, это ты совершенно не понимаешь для чего используется
постраничный вывод в веб-интерфейсах.
Alexander Goldun
>> По-моему, это ты совершенно не понимаешь для чего используется
>>постраничный вывод в веб-интерфейсах.
>
> Это клиника :(
Hу, если ты доктор, то глянь для примера ссылку:
http://sql.ru/forum/actualtopics.aspx?bid=30
смотри под таблицей строчку "Страницы: 1 2 3..."
Было бы интересно услышать твою идею, как более правильно реализовать
эти страницы не используя номера страниц, если на каждой нужно
отобразить по 50 записей.
Или возьмем для примера не форум, а длинный топик:
http://sql.ru/forum/actualthread.aspx?tid=233233
По каким критериям разбивать? Hапример, я помню, что там вчера было 5
страниц. Сегодня их 10. Очевидно, мне есть смысл начинать смотреть его
не ранее чем с 5-й страницы.
Разумные идеи будут? Как ты себе представляешь использование там
диапазона ключей?
Andrew Lesnichenko
> Hу, если ты доктор, то глянь для примера ссылку:
> http://sql.ru/forum/actualtopics.aspx?bid=30
> смотри под таблицей строчку "Страницы: 1 2 3..."
> Было бы интересно услышать твою идею, как более правильно реализовать
> эти страницы не используя номера страниц, если на каждой нужно
> отобразить по 50 записей.
>
> Или возьмем для примера не форум, а длинный топик:
> http://sql.ru/forum/actualthread.aspx?tid=233233
> По каким критериям разбивать? Hапример, я помню, что там вчера было 5
> страниц. Сегодня их 10. Очевидно, мне есть смысл начинать смотреть его
> не ранее чем с 5-й страницы.
>
> Разумные идеи будут? Как ты себе представляешь использование там
> диапазона ключей?
>
Данные примеры иллюстрируют необходимость доступа к страницам в
произвольном порядке, полагаю? Как уже было сказано, сама такая
необходимость является типичным "поджопным" способом, к которому
вынуждены прибегать пользователи в условиях скудости предоставленного им
web-интерфейса. Он не дает им возможности сформировать более гибкие
условия отбора и сортировки.
По обоим примерам не стало ясно, как именно пользователь узнает номер
нужной ему страницы в условиях постоянного изменения содержания. Он
может только примерно догадываться и далее действовать методом
последовательных приближений. Нормальными же критериями отбора являются
дата последнего чтения, прочитанные/непрочитанные сообщения, объединения
их в цепочки обсуждений и пр. - все, что есть в нормальном news reader'е.
--
Andrew Lesnichenko
Alexander Goldun
> Данные примеры иллюстрируют необходимость доступа к страницам в
> произвольном порядке, полагаю? Как уже было сказано, сама такая
> необходимость является типичным "поджопным" способом, к которому
> вынуждены прибегать пользователи в условиях скудости предоставленного им
> web-интерфейса.
Возможно именно так. Так ведь изначально причиной такой потребности была
скорее всего именно необходимость реализации web-интерфейса
> По обоим примерам не стало ясно, как именно пользователь узнает номер
> нужной ему страницы в условиях постоянного изменения содержания. Он
> может только примерно догадываться и далее действовать методом
> последовательных приближений.
По второму примеру я показал достаточно реальный путь узнавания нужной
мне страницы. Пусть даже и с погрешностью на то, что в прошедших
страницах могут быть удалены или отредактированы сообщения.
> Hормальными же критериями отбора являются
> дата последнего чтения, прочитанные/непрочитанные сообщения, объединения
> их в цепочки обсуждений и пр. - все, что есть в нормальном news reader'е.
Hу вот, осталось от обсуждения конструкции SELECT TOP n START AT m
плавно перейти к флейму Web-форумы vs NNTP :)
Alexander Goldun
>>Было бы интересно услышать твою идею, как более правильно реализовать
>>эти страницы не используя номера страниц,
> По времени написания сообщений (в данном случае, исходя из фактического
> трафика, достаточно дат).
>
> Страницы: 14.12-06.01 24.11-13.12 07.11-23.11
Hу-ну, любопытно :) Можешь привести пример такого "правильного"
web-форума? Или хотя бы пример, как будут выглядеть обозначения, если за
час вдруг наконопатят сообщений на несколько страниц (а такое бывает)?
А еще любопытно увидеть реализацию такого чуда правильного
проектирования. Хотя бы процедуру получения перечня страниц с обозначениями.
Конечно, web-разработка может накладывать специфический отпечаток на
разработчиков, многие вещи могут показаться дикостью тем, кто
разрабатывал только классические клиентские приложения. Hо такова
специфика Web-разработки. И считать всех безграмотными не очень
правильно. По твоему все бездарно проектируют, делают страничный вывод,
а большинство производителей СУБД в угоду рынку потакает этой
безграмотности? Один лишь MSSQL не дал нормальной конструкции ибо нафиг
не нужна? Тогда еще ссылка от Microsoft:
http://search.microsoft.com/results.aspx?mkt=en-US&setlang=en-US&q=media+player
Как здесь нужно было реализовать?
>>если на каждой нужно
>>отобразить по 50 записей.
> Кому нужно?
Очевидно, всем, кроме тебя. Это просто эмпирически подобранное значение,
компромисс между кол-вом страниц и размером каждой страницы.
Andrew Lesnichenko
> Andrew Lesnichenko пишет:
>>произвольном порядке, полагаю? Как уже было сказано, сама такая
>>необходимость является типичным "поджопным" способом, к которому
>>вынуждены прибегать пользователи в условиях скудости предоставленного им
>>web-интерфейса.
> Возможно именно так. Так ведь изначально причиной такой потребности была
> скорее всего именно необходимость реализации web-интерфейса
Скорее, движение по пути наименьшего сопротивления в виде повторения
чужих решений.
> По второму примеру я показал достаточно реальный путь узнавания нужной
> мне страницы. Пусть даже и с погрешностью на то, что в прошедших
> страницах могут быть удалены или отредактированы сообщения.
Это не реальный путь, а костыль в условиях кривого интерфейса.
>>Hормальными же критериями отбора являются
>>дата последнего чтения, прочитанные/непрочитанные сообщения, объединения
>>их в цепочки обсуждений и пр. - все, что есть в нормальном news reader'е.
> Hу вот, осталось от обсуждения конструкции SELECT TOP n START AT m
> плавно перейти к флейму Web-форумы vs NNTP :)
Не одно против другого, а почему бы не взять в web-интерфейс грамотные и
удобные для пользователя решения.
Andrew Lesnichenko
> Конечно, web-разработка может накладывать специфический отпечаток на
> разработчиков, многие вещи могут показаться дикостью тем, кто
> разрабатывал только классические клиентские приложения. Hо такова
> специфика Web-разработки. И считать всех безграмотными не очень
> правильно. По твоему все бездарно проектируют, делают страничный вывод,
По-моему это называется оправданием кривой разработки. Один слепил
барахло на коленке, а остальные повторяют, чтобы самим не работать. А
пользователи "хавают" то, что дают, поскольку ничего больше нет.
Если клиент "попросил" 500 строк, то собирается читать их все - пусть
читает последовательно постранично. Если ему не нужно столько или нужна
страница из середины, значит он ГАДАЕТ, потому что в интерфейсе ему не
дали возможности выбрать только то, что ему нужно.
Alexander Goldun
>>>Страницы: 14.12-06.01 24.11-13.12 07.11-23.11
>>Hу-ну, любопытно :) Можешь привести пример такого "правильного"
>>web-форума?
> Без понятия, я веб-форумами не пользуюсь.
Hу если "без понятия", тогда может не стоило хотя бы в этой области
обвинять других в ощибочном проектировании?
>>Или хотя бы пример, как будут выглядеть обозначения, если за
>>час вдруг наконопатят сообщений на несколько страниц (а такое бывает)?
> Сегодня 13:43-13:53 Сегодня 13:30-13:42
Много места свободного на страницах?
>>А еще любопытно увидеть реализацию такого чуда правильного
>>проектирования. Хотя бы процедуру получения перечня страниц с
>>обозначениями.
> Я готов обсудить сумму.
А я готов с ходу бесплатно выдать решение для нумерованных страниц:
Получение кол-ва страниц:
SELECT ceiling(count(*)/N) FROM table_name
Где N - кол-во записей на страницу (плавающего типа, чтобы учесть
последнюю неполную страницу, если она есть)
Получение записей для M-й страницы:
SELECT TOP N start at K * FROM table_name ORDER BY key_name
где K=1+(M-1)*N
И все. Hе нужно торговаться с доктором :)
>>http://search.microsoft.com/results.aspx?mkt=en-US&setlang=en-US&q=media+player
>>Как здесь нужно было реализовать?
> Это не выборка из базы, не надо переводить стрелки.
А что же это, как не выборка из базы, отсортированная, например, по
релевантности или дате?
>>Это просто эмпирически подобранное значение,
>>компромисс между кол-вом страниц и размером каждой страницы.
> Ты думаешь, пользователи обидятся, если на странице окажется 49 или 51
> запись?
Hе обидятся. Hо удивятся, если на страницах будет 5,1,1563,49 записей.
Hикто не пытается тут сказать, что нумерация страниц - единственное
верное рещение. У него есть недостатки, которые надо иметь в виду. Hо
для веба во многих случаях оно самое оптимальное. В обычных клиентских
приложениях (не web) пользователи тоже не так часто заморачиваются
скурпулезной фильтрацией до получения единственсвенно нужной записи.
Часто просто уменьшают размер выборки до некоей приемлемой величины
(зависит от контекста - это может быть и 50 и 500 записей), а потом
просто скролят грид руками и ищут глазами. Оговорюсь сразу: даже при
наличии мощных и удобных фильтров. Hу выберет клиента в журнале счетов.
Hу укажет период в месяц. А потом просто отсортирует например по сумме и
проскролит быстро пару-тройку экранов. Так вот для веба выборка в 500
записей на одной странице может оказаться великоватой, а реализовывать
функционал типа грида - проблематично. Тогда бьем ее на 10 по 50 и
выдаем в таком виде. Последовательное щелканье по страницам - аналог
скроллинга в гриде. И там уже может оказаться не важно для пользователя,
какие там критерии выборки по страницам, ему просто нужно иметь
возможность последовательно получить данные. Hо специфика веба в том,
что там нет такого жесткого понятия сессии, как в обычном клиенте. Т.е.
утрированно получение каждой новой порции данных (новой страницы) -
практически отдельный сеанс работы с бд: подключился, получил данные,
сформировал страницу, отключился. Это, конечно, очень грубое
утрирование, но оно хорошо показывает главное отличие. Соответственно,
классические способы получения выборки, типа курсора, тут не подходят.
Для таких случаев и сделана возможность постраничного получения данных.
Впрочем, нафига я это все разжевываю? "Это клиника" (с) Vadim Rumyantsev
:)
Alexander Goldun
>>разрабатывал только классические клиентские приложения. Hо такова
>>специфика Web-разработки. И считать всех безграмотными не очень
>>правильно. По твоему все бездарно проектируют, делают страничный вывод,
> По-моему это называется оправданием кривой разработки. Один слепил
> барахло на коленке, а остальные повторяют, чтобы самим не работать. А
> пользователи "хавают" то, что дают, поскольку ничего больше нет.
Может быть и так. Web-разработкой не занимаюсь и не задавался целью искать
более удобный вариант, чем нумерованные страницы, но навскидку для
большинства случаев ничего лучшего не вижу.
> Если клиент "попросил" 500 строк, то собирается читать их все - пусть
> читает последовательно постранично. Если ему не нужно столько или нужна
> страница из середины, значит он ГАДАЕТ,
Да даже при последовательном постраничном просмотре, как ты предлагаешь
выдавать после первой 2-ю, 3-ю и т.д. страницы с учетом специфики веба?
Alexander Goldun
>>А я готов с ходу бесплатно выдать решение для нумерованных страниц:
>>И все. Hе нужно торговаться с доктором :)
> Правильно, именно в этом и разница между двумя методами - бесплатно,
> по-простецки и плохо, либо за деньги, с умом и хорошо.
А судьи кто? Кому плохо и кому хорошо? И чем именно плохо?
>>Hу выберет клиента в журнале счетов.
>>Hу укажет период в месяц. А потом просто отсортирует например по сумме и
>>проскролит быстро пару-тройку экранов.
> Писать программы для большого (и/или ответственного) предприятия я бы тебя с
> таким подходом не взял.
Взаимно. Мне не нужны упертые теоретики. Практика - это бесконечные
компромиссы. Я специально сделал оговорку "даже при наличии мощных и
удобных фильтров". Если у пользователя есть возможность отфильтровать по
любому критерию или набору критериев, это не значит, что он будет
пользоваться ими до победного конца. Бывают ситуации, когда просмотреть
оставшееся глазами быстрее, чем придумывать и задавать еще уточняющие
условия. А иногда просто нужна вся выборка для просмотра.
Andrew Lesnichenko
> Да даже при последовательном постраничном просмотре, как ты предлагаешь
> выдавать после первой 2-ю, 3-ю и т.д. страницы с учетом специфики веба?
Читать из курсора не годится?
Alex Gotlib
Sun, 08 Jan 2006 at 09:44 GMT Alexander Goldun wrote:
AG> Может быть и так. Web-разработкой не занимаюсь и не задавался целью
AG> искать
AG> более удобный вариант, чем нумерованные страницы, но навскидку для
AG> большинства случаев ничего лучшего не вижу.
А для большинства случаев ничего лучше и нет. Оптимальным
решением является фильтр по ключевым полям (например в случае гостевой
книги это могут быть поля "дата" и "автор") + все тот же постраничный
вывод. Иначе получается гавно, а не веб-интерфейс.
Господа просто теоретизируют и гнут пальцы. Заняться видно в
праздники больше нечем. :-)
Alexander Goldun
>>>Правильно, именно в этом и разница между двумя методами - бесплатно,
>>>по-простецки и плохо, либо за деньги, с умом и хорошо.
>>А судьи кто? Кому плохо и кому хорошо?
> Пользователям, очевидно.
Отучайся говорить за пользователей. Мои, по крайней мере, в восторге.
> Если пользователь не пользуется фильтрами - значит, они не удобные. По
> определению.
По какому такому определению? Демагогия чистейшая. Простой пример. Есть
журнал счетов. Есть возможность фильтровать по любому набору полей.
Hужно найти определенный счет. Известен клиент, месяц, сумма около
$10000 и помню, что в примечаниях что-то написал. В фильтре в пару
кликов выбираю месяц, по 2-3 начальным буквам клиента. Получаю выборку,
которая не умещается в форме журнала, но судя по полосе прокрутки
составляет около 3-х этих самых журналов по высоте. Могу, конечно, еще
задать фильтр по сумме, например >9000 и <11000 и признак непустого
примечания или даже вспомнить и задать входящее слово и получить
минимальную выборку с искомой записью (если не ошибусь в задании
критерия :). А могу просто один или два раза нажать PageDown или
кликнуть по скролл-бару и увидеть нужную мне запись. Что проще? Виновато
неудобство фильтров? Здесь я, в отличие от тебя, не теоретизирую. Мне
часто приходилось наблюдать работу персонала и даже самому на время
вживаться в роли на разных рабочих местах, чтобы посторить наиболее
оптимальный интерфейс, обеспечить эффективную методологию работы как раз
для случаев, когда приходится работать с большими объемами информации.
Вплоть до подсчета необходимых телодвижений на операцию.
Ладно, надоело мне все это. Я тут пытаюсь объяснить, мотивировать,
привести наглядные примеры, а ты отмахиваешься абстрактными наездами
типа "ошибка проектирования", "клиника", "по определению" и т.п. Все
останутся при своих мнениях, плюс получат некое представление о
профессиональном уровне собеседников.
Возвращаясь к исходному вопросу зачем нужна такая конструкция в SQL,
добавлю лишь, что она не помешает, даже если захотим выдать постранично,
но не с номерами, а диапазонами ключей, как ты предлагаешь. Если
например надо выдать постранично по 50 записей на страницу с ключем
фамилия, то получить перечень этих самых граничных фамилий проще всего
при помощи рассматриваемой конструкции, примерно так (в цикле по N):
SELECT TOP 1 START AT 1+(N-1)*50 last_name
FROM some_table ORDER BY last_name
А уже выборки для конкретных страниц делать по ключу.
P.S. А в DB2 подобная конструкция имеется?
Andrew Lesnichenko
> Возвращаясь к исходному вопросу зачем нужна такая конструкция в SQL,
> добавлю лишь, что она не помешает, даже если захотим выдать постранично,
> но не с номерами, а диапазонами ключей, как ты предлагаешь. Если
> например надо выдать постранично по 50 записей на страницу с ключем
> фамилия, то получить перечень этих самых граничных фамилий проще всего
> при помощи рассматриваемой конструкции, примерно так (в цикле по N):
>
> SELECT TOP 1 START AT 1+(N-1)*50 last_name
> FROM some_table ORDER BY last_name
>
> А уже выборки для конкретных страниц делать по ключу.
>
> P.S. А в DB2 подобная конструкция имеется?
Насколько я представляю, подобные вещи (выбрать N строк из середины
полученного множества) пишутся и безо всяких там 'TOP', 'START' и пр.
Если найду пример, отправлю...
Andrew Lesnichenko
> А для большинства случаев ничего лучше и нет. Оптимальным
> решением является фильтр по ключевым полям (например в случае гостевой
> книги это могут быть поля "дата" и "автор") + все тот же постраничный
> вывод. Иначе получается гавно, а не веб-интерфейс.
>
> Господа просто теоретизируют и гнут пальцы. Заняться видно в
> праздники больше нечем. :-)
Скорее, господ напрягает пользоваться тем говном, которое вы называете
web-интерфейсом.
Nick Gazaloff
> Alexander Goldun wrote:
>
>> Да даже при последовательном постраничном просмотре, как ты
>> предлагаешь выдавать после первой 2-ю, 3-ю и т.д. страницы с учетом
>> специфики веба?
>
>
> Читать из курсора не годится?
А пропускать строки в курсоре через MOVE? Это тоже не сильно переносимо
между разными СУБД...
Nick Gazaloff
> Alex Gotlib wrote:
>
>> А для большинства случаев ничего лучше и нет. Оптимальным решением
>> является фильтр по ключевым полям (например в случае гостевой книги
>> это могут быть поля "дата" и "автор") + все тот же постраничный вывод.
>> Иначе получается гавно, а не веб-интерфейс.
>>
>> Господа просто теоретизируют и гнут пальцы. Заняться видно в
>> праздники больше нечем. :-)
>
>
> Скорее, господ напрягает пользоваться тем говном, которое вы называете
> web-интерфейсом.
Ну конечно... Все п...сы, а вы один Д'Артаньян... Будьте проще, поручик.
Меньше снобизма.
Alexander Goldun
>>Да даже при последовательном постраничном просмотре, как ты предлагаешь
>>выдавать после первой 2-ю, 3-ю и т.д. страницы с учетом специфики веба?
>
>
> Читать из курсора не годится?
И для каждой последующей страницы открывать по новой курсор и скроллить
его соответственно номеру страницы? Элегантное решение :)
Andrew Lesnichenko
А зачем его открывать каждый раз? Открыть один раз, вернуть из процедуры
массив в N строк. Потом следующие N строк. Не пойдет?
Andrew Lesnichenko
> Andrew Lesnichenko wrote:
>
>> Alexander Goldun wrote:
>>
>>> Да даже при последовательном постраничном просмотре, как ты
>>> предлагаешь выдавать после первой 2-ю, 3-ю и т.д. страницы с учетом
>>> специфики веба?
>> Читать из курсора не годится?
> А пропускать строки в курсоре через MOVE? Это тоже не сильно переносимо
> между разными СУБД...
1. Зачем пропускать? Я имел в виду, читать курсор последовательно с
начала, но показывать записи частями. Поскольку из середины не читаем,
ничего проскакивать не надо.
2. Насчет переносимости - уже же выяснили, что синтаксис MySQL с
проскакиванием строк непереносим и вообще в этой задаче переносимости нет.
3. Но с другой стороны, можно сделать и на простейшем SQL, если я
конечно не попутал что-то. Еще в Oracle7 это решалось традиционным
синтаксисом. Если найду на работе пример, отправлю. Хотя, там вроде бы
rownum использовался...
Nick Gazaloff
> Nick Gazaloff wrote:
>
>> Andrew Lesnichenko wrote:
>>
>>> Alexander Goldun wrote:
>>>
>>>> Да даже при последовательном постраничном просмотре, как ты
>>>> предлагаешь выдавать после первой 2-ю, 3-ю и т.д. страницы с учетом
>>>> специфики веба?
>
>
>>> Читать из курсора не годится?
>
>
>> А пропускать строки в курсоре через MOVE? Это тоже не сильно
>> переносимо между разными СУБД...
>
>
> 1. Зачем пропускать? Я имел в виду, читать курсор последовательно с
> начала, но показывать записи частями. Поскольку из середины не читаем,
> ничего проскакивать не надо.
Может, я не понял ваш вариант, но как читать "последовательно с начала"
для Web-страницы, выводящей записи с 11 по 20?
>
> 2. Насчет переносимости - уже же выяснили, что синтаксис MySQL с
> проскакиванием строк непереносим и вообще в этой задаче переносимости нет.
>
> 3. Но с другой стороны, можно сделать и на простейшем SQL, если я
> конечно не попутал что-то. Еще в Oracle7 это решалось традиционным
> синтаксисом. Если найду на работе пример, отправлю. Хотя, там вроде бы
> rownum использовался...
>
--
Best regards,
Nick Gazaloff
> Alexander Goldun wrote:
>
>>>> Да даже при последовательном постраничном просмотре, как ты
>>>> предлагаешь выдавать после первой 2-ю, 3-ю и т.д. страницы с учетом
>>>> специфики веба?
>>>
>>>
>>> Читать из курсора не годится?
>>
>>
>> И для каждой последующей страницы открывать по новой курсор и
>> скроллить его соответственно номеру страницы? Элегантное решение :)
>>
> А зачем его открывать каждый раз? Открыть один раз, вернуть из процедуры
> массив в N строк. Потом следующие N строк. Не пойдет?
Почитайте что-нибудь о протоколе HTTP. Он stateless, и при переходе
пользователя между страницами кое-что сохранить можно (через т.н.
"сеансы"), но уж никак не курсор. Соединение с СУБД разрывается по
окончании генерации страницы.
Victor Metelitsa
[...]
> Почитайте что-нибудь о протоколе HTTP. Он stateless, и при переходе
> пользователя между страницами кое-что сохранить можно (через т.н.
> "сеансы"), но уж никак не курсор. Соединение с СУБД разрывается по
> окончании генерации страницы.
>
рвать при окончании генерации страницы. Сервера приложений обычно
поддерживают понятие сеанса. Используя это, даже для каждого юзера (!)
можно держать отдельный коннект и открытый курсор. Правда, это годится
для интранета, но для интернета едва ли. Есть также понятие connection
pooling, но курсор-таки для каждого юзера нужен отдельный.
Ещё можно получить запросом SELECT ключ WHERE ... все ключи в массив (и
держать его в переменной сеанса), чтобы при просмотре произвольной
страницы брать ключи из массива и выполнять SELECT ... WHERE ключ IN
(...ключи...). Между прочим, так работает MS Access. Но какова будет
величина массива ключей? Не имеет ли смысл сохранять его на диск / во
временной таблице базы данных? It dependents.
Так что лично я предпочту брать записи с N по M средствами СУБД, если
такая возможность есть. Большая область применения, в сравнении с первым
случаем. Проще в реализации и быстрее выдаётся первая страница, в
сравнении со вторым.
--
Andrew Lesnichenko
> Так что лично я предпочту брать записи с N по M средствами СУБД, если
> такая возможность есть. Большая область применения, в сравнении с первым
> случаем. Проще в реализации и быстрее выдаётся первая страница, в
> сравнении со вторым.
>
В частности, в Oracle это делается так (взято из FAQ на sql.ru):
select o.*
from (select rownum rn, o.*
from (select o.* from "таблица" o order by "что нужно") o
where rownum <= :M) o
where o.rn >= :N;
--
Andrew Lesnichenko
Andrew Lesnichenko
> Почитайте что-нибудь о протоколе HTTP. Он stateless, и при переходе
> пользователя между страницами кое-что сохранить можно (через т.н.
> "сеансы"), но уж никак не курсор. Соединение с СУБД разрывается по
> окончании генерации страницы.
>
Хотел бы я посмотреть как вы, начитавшись про http, зайдете по нему в
тот же Oracle, создадите и разорвете соединение...
Andrew Lesnichenko
>> 1. Зачем пропускать? Я имел в виду, читать курсор последовательно с
>> начала, но показывать записи частями. Поскольку из середины не читаем,
>> ничего проскакивать не надо.
>
> Может, я не понял ваш вариант, но как читать "последовательно с начала"
> для Web-страницы, выводящей записи с 11 по 20?
Вы перед этим прочитали записи с 1 по 10...
Nick Gazaloff
> Nick Gazaloff wrote:
>
>> Почитайте что-нибудь о протоколе HTTP. Он stateless, и при переходе
>> пользователя между страницами кое-что сохранить можно (через т.н.
>> "сеансы"), но уж никак не курсор. Соединение с СУБД разрывается по
>> окончании генерации страницы.
>>
> Хотел бы я посмотреть как вы, начитавшись про http, зайдете по нему в
> тот же Oracle, создадите и разорвете соединение...
>
Намек непонятен. Скажите тогда, какие средства разработки Web-приложений
(PHP, ASP.NET, ColdFusion, JSP etc...) позволяют хранить дескрипторы
курсоров в данных сеанса.
Alexander Goldun
>>>1. Зачем пропускать? Я имел в виду, читать курсор последовательно с
>>>начала, но показывать записи частями. Поскольку из середины не читаем,
>>>ничего проскакивать не надо.
>>
>>Может, я не понял ваш вариант, но как читать "последовательно с начала"
>>для Web-страницы, выводящей записи с 11 по 20?
> Вы перед этим прочитали записи с 1 по 10...
Перед чем этим? Кто именно перед этим прочитал 10 записей и каких из
нескольких сотен пользователей, запрашивавших "перед этим" какие-то
страницы с частями выборок? Когда их прочитал? Час назад?
Я пожалуй, самоустранюсь от сего бесплодного обсуждения. Хоть я и не
спец в Web-программировании, вы, похоже, еще больше не спец в нем же.
Мне хотя бы знакомы ключевые специфические моменты и я в пробных целях
делал подобные интерфейсы.
Хотя ключевой момент, пожалуй, один: отсутствие в HTTP такого жесткого
понятия сессии, как при обычном подключении клиента к SQL-серверу. Об
этом уже говорил и я и Nick Gazaloff. Если этот момент непонятен в
теории, то остается только на практике хотя бы попробовать реализовать
подобное постраничное чтение. После этого можно продолжить обсуждение,
хотя, скорее всего, этот вопрос отпадет сам собой.
Victor Metelitsa
Все Smalltalk'и (VAST, VW, Squeak и т.д.) это могут (им просто-напросто
безразлично, каких классов объекты - атрибуты сеанса). И
java.lang.Object getAttribute(java.lang.String key)
void setAttribute(java.lang.String name, java.lang.Object value)
тоже наводит на определённые мысли.
--
Nick Gazaloff
> Nick Gazaloff wrote:
>
>> Andrew Lesnichenko wrote:
>>
>>> Nick Gazaloff wrote:
>>>
>>>> Почитайте что-нибудь о протоколе HTTP. Он stateless, и при переходе
>>>> пользователя между страницами кое-что сохранить можно (через т.н.
>>>> "сеансы"), но уж никак не курсор. Соединение с СУБД разрывается по
>>>> окончании генерации страницы.
>>>>
>>> Хотел бы я посмотреть как вы, начитавшись про http, зайдете по нему в
>>> тот же Oracle, создадите и разорвете соединение...
>>>
>>
>> Намек непонятен. Скажите тогда, какие средства разработки
>> Web-приложений (PHP, ASP.NET, ColdFusion, JSP etc...) позволяют
>> хранить дескрипторы курсоров в данных сеанса.
>
>
> Все Smalltalk'и (VAST, VW, Squeak и т.д.) это могут (им просто-напросто
> безразлично, каких классов объекты - атрибуты сеанса). И
Что-то я не слышал о сайтах на Smalltalk.
> java.lang.Object getAttribute(java.lang.String key)
> void setAttribute(java.lang.String name, java.lang.Object value)
>
> тоже наводит на определённые мысли.
С JSP я не работал, может, вы скажете: там есть возможность не закрывать
соединение с БД и курсор при переходах между страницами? Вопрос именно в
этом.
Nick Gazaloff
> Nick Gazaloff wrote:
>
>> (PHP, ASP.NET, ColdFusion, JSP etc...) позволяют хранить дескрипторы
>> курсоров в данных сеанса.
>
>
> А ASP.NET разве не держит открытыми пул сессий? В любом случае, не
> браузер же сессии открывает...
Пул -- возможно. Со случайным выбором из пула и с меньшим числом
коннектов в пуле по сравнению с числом Web-клиентов. Думаю, понимаете,
что это означает в контексте задачи?
В общем, все ясно. Web-приложения вы не писали.
Andrew Lesnichenko
>>> (PHP, ASP.NET, ColdFusion, JSP etc...) позволяют хранить дескрипторы
>>> курсоров в данных сеанса.
>> А ASP.NET разве не держит открытыми пул сессий? В любом случае, не
>> браузер же сессии открывает...
> Пул -- возможно. Со случайным выбором из пула и с меньшим числом
> коннектов в пуле по сравнению с числом Web-клиентов. Думаю, понимаете,
Не вижу противоречия ни со случайным выбором ни, тем более, с меньшим
числом клиентов (соб-но для этого пул и существует).
Например, оракловые пулы всегда держат контекст сессий при выполнении
обоих условий - кооперативная обработка многих клиентов меньшим числом
серверных процессов. При этом не требуется никаких изменений на клиенте.
Далее, все J2EE сервера приложений держат контекст. И даже умеют
мигрировать этот контекст с одного хоста на другой в кластере серверов
приложений. ASP.NET, это, насколько я понимаю, виндовозный конкурент
J2EE. Значит и он должен уметь.
Nick Gazaloff
> Nick Gazaloff wrote:
>
>>>> (PHP, ASP.NET, ColdFusion, JSP etc...) позволяют хранить дескрипторы
>>>> курсоров в данных сеанса.
>
>
>>> А ASP.NET разве не держит открытыми пул сессий? В любом случае, не
>>> браузер же сессии открывает...
>
>
>> Пул -- возможно. Со случайным выбором из пула и с меньшим числом
>> коннектов в пуле по сравнению с числом Web-клиентов. Думаю, понимаете,
>
>
> Не вижу противоречия ни со случайным выбором ни, тем более, с меньшим
> числом клиентов (соб-но для этого пул и существует).
>
> Например, оракловые пулы всегда держат контекст сессий при выполнении
> обоих условий - кооперативная обработка многих клиентов меньшим числом
> серверных процессов. При этом не требуется никаких изменений на клиенте.
А открытый курсор глобально доступен из любых сессий?
>
> Далее, все J2EE сервера приложений держат контекст. И даже умеют
> мигрировать этот контекст с одного хоста на другой в кластере серверов
> приложений. ASP.NET, это, насколько я понимаю, виндовозный конкурент
> J2EE. Значит и он должен уметь.
>
--
Best regards,
Andrew Lesnichenko
>>> Пул -- возможно. Со случайным выбором из пула и с меньшим числом
>>> коннектов в пуле по сравнению с числом Web-клиентов. Думаю, понимаете,
>> Например, оракловые пулы всегда держат контекст сессий при выполнении
>> обоих условий - кооперативная обработка многих клиентов меньшим числом
>> серверных процессов. При этом не требуется никаких изменений на клиенте.
> А открытый курсор глобально доступен из любых сессий?
Данный пример (Oracle-пулы) я привел для того, чтобы показать, что пул
может сократить число коннектов и при этом сохранить весь контекст (не
только открытый курсор). Т.е., с т.зрения приложения он прозрачен. Если
вы имеете приложение 1:1 (одно клиентское соединение выливается в одно
ответное серверное) и в нем глобально открытый курсор будет доступен из
любых сессий, то и используя пул вы все это сохрание. И наоборот.
Victor Metelitsa
[...]
>>
>> Все Smalltalk'и (VAST, VW, Squeak и т.д.) это могут (им
>> просто-напросто безразлично, каких классов объекты - атрибуты сеанса). И
>
> Что-то я не слышал о сайтах на Smalltalk.
>
>
>> java.lang.Object getAttribute(java.lang.String key)
>> void setAttribute(java.lang.String name, java.lang.Object value)
>>
>> тоже наводит на определённые мысли.
>
>
> С JSP я не работал, может, вы скажете: там есть возможность не закрывать
> соединение с БД и курсор при переходах между страницами? Вопрос именно в
> этом.
Кто вам мешает сохранить коннект и курсор в атрибуте сеанса? Ведь они
принадлежат классам, порождённым от Object.
Victor Metelitsa
Ничего не понимаю. Какой смысл имеет "глобально открытый курсор",
доступный из всех сеансов (sessions)? У каждого сеанса должен быть свой
курсор (предположим, что мы делаем свой yandex).
--
Andrew Lesnichenko
> Ничего не понимаю. Какой смысл имеет "глобально открытый курсор",
> доступный из всех сеансов (sessions)? У каждого сеанса должен быть свой
> курсор (предположим, что мы делаем свой yandex).
>
Я этого тоже не понял. Но это вопрос дизайна приложения, а не вопрос
разницы между web и не-web приложением :)
--
Andrew Lesnichenko
Andrew Grachyov
Tuesday January 03 2006, Andrew Lening writes to Andrew Grachyov:
AL> Постраничный вывод. В веб-приложениях, в частности. Притом что юзер может
AL> посмотреть третью страницу, и не посмотреть при этом все остальные.
А это как? Он либо выбиpает что-то по условию, либо листает от начала.
Я до сих поp не вижу (не понимаю) бизнес-задачи, в котоpой такое может
потpебоваться. Hа упоминавшемся sql.ru я никогда не хожу на стpаницу
под опpеделенным номеpом.
Даже в упоминашихся фоpумах, pазбитых по стpаницам, мне бы было удобно
попасть не на опpеделенную стpаницу, а на опpеделенный фоpум. И сделать
это пpавильнее не сpедствами СУБД, а сpедствами Web-интеpфейса.
Более того, если все-таки надо начать "отлистывать" с какого-то момента,
то это пpедполагает какую-то упоpядоченность и всегда можно использовать
сpавнение (типа, какое-то поле больше дpугого). Если упоpядоченности нет,
или она может измениться, то тогда и пеpеход на (к пpимеpу) 5-ю стpаницу
бессмысленен.
Как показывает мой опыт общения с поисковиками и/или стpаницами,
постpоенными с учетом возможности пеpехода на нужную стpаницу (www.price.ru,
google), то типичный алгоpитм моей pаботы - посмотpел пеpвую стpаницу,
затем втоpую, если не нашел - то меняю условие. Я никогда (навеpное :-) )
не заходил на 4-ю или 18-ю стpаницу.
В случае с фоpумами, там где по 10 стpаниц на экpан, все pешается более
логичной выбоpкой по условию (BETWEEN).
В общем, так - я допускаю, что констpукция "выбpать с 34 по 48-ю" записи
будет востpебованной. С дpугой стоpоны, я пока не вижу ситуации, где эта
констpукция будет пpавильным pешением. Хотя...... все возможно.
Пока.
Andrew Grachyov.
Andrew Lening
AG> А это как?
Знаешь фразу "практика - критерий истины"? Так вот, такой механизм применяет в
веб-приложениях практически ВЕЗДЕ. В том числе гугль, яндекс и прочие
поисковики, все известные мне веб-форумы и так далее. Утверждать, что это все
делается от неспособности придумать что-то более удобное - по-меньшей мере
самонадеянно. Вся эта заумь просто не прижилась, потому что обычному
пользователю (который этим всем пользуется, а не абстрактно теоретизирует)
нужен ПРОСТОЙ интерфейс. И пролистать пару-тройку экранов ему обычно
действительно проще, чем переформулировать, например, условие поиска на
какое-то более навороченное. Кроме того, запомнить, например, на какой странице
он закончил чтение такой-то ветки форума на порядок проще, чем запомнить,
например, диапазон ключей. В общем, простота - залог успеха интерфейса.
Bye.
Andrew Lesnichenko
1. Пролистать 2-3 экрана действительно проще, чем переформулировать
запрос. Но только тогда, когда этих экранов 2-3, а не 10. Потому что на
2-3 экрана терпения хватает, а на больше - уже нет. И когда он их читает
подряд.
2. Как, интересно, проще запомнить страницу ветки форума, если
содержимое постоянно меняется?
3. Пример в гуглом (поисковиком), который возвращает результаты поиска,
некорректен, поскольку это свободный поиск, качество которого целиком
определяется качеством вопроса, и раз уж вернулось 200 экранов ссылок,
то никуда не денешься. И еще раз - какой физический смысл выбирать из
этих 200 экранов 3-й, потом 15-й, потом 8-й, вместо чтения подряд?
4. Насчет "практика - критерий истины" можно сказать следующее: все
известные мне веб-форумы действительно пользуются таким методом. И я как
пользователь этих форумов утверждаю, что это с т.зрения интерфейса
примитивное и неудобное убожество. Пользователю нужен не только простой,
но и удобный интерфейс, а его принуждают пользоваться неудобным
барахлом. И делается это не от того, что нельзя придумать удобнее, а
потому, что неудобное барахло уже есть и использовать его гораздо проще,
быстрее и дешевле для владельцев форума.
Vladimir Pavlikov
You wrote to Andrew Lening on Sat, 14 Jan 2006 12:25:00 +0300:
AG> Как показывает мой опыт общения с поисковиками и/или стpаницами,
AG> постpоенными с учетом возможности пеpехода на нужную стpаницу
AG> (www.price.ru, google), то типичный алгоpитм моей pаботы - посмотpел
AG> пеpвую стpаницу, затем втоpую, если не нашел - то меняю условие. Я
AG> никогда (навеpное :-) ) не заходил на 4-ю или 18-ю стpаницу.
Да тот же прайс, к примеру. Указываешь нежесткие критерии, и получаешь
20 страниц, отсортированных по ценам. Первая половина, состоящая, как
правило, из сомнительных подвалов, малоинтересна. Последняя четверть
тоже - зачем платить лохоразводителям? Т.е. я, к примеру, иду сразу на 12-ю
страницу. Затем по ипсилон-окрестности. Странно, что тебе незнаком этот
сценарий.
With best regards, Vladimir Pavlikov. E-mail: v...@soil.msu.ru
--
Victor Metelitsa
[...]
>
> 1. Пролистать 2-3 экрана действительно проще, чем переформулировать
> запрос. Но только тогда, когда этих экранов 2-3, а не 10. Потому что на
> 2-3 экрана терпения хватает, а на больше - уже нет. И когда он их читает
> подряд.
>
К сожалению, мне приходилось читать даже и по 20 страниц подряд.
> 2. Как, интересно, проще запомнить страницу ветки форума, если
> содержимое постоянно меняется?
>
Это помнит браузер. Поэтому, когда я читал, например, страницы 1..9, а
позднее появилась страница 10, это сразу видно, потому что браузер
показывает цветом.
> 3. Пример в гуглом (поисковиком), который возвращает результаты поиска,
> некорректен, поскольку это свободный поиск, качество которого целиком
> определяется качеством вопроса, и раз уж вернулось 200 экранов ссылок,
> то никуда не денешься. И еще раз - какой физический смысл выбирать из
> этих 200 экранов 3-й, потом 15-й, потом 8-й, вместо чтения подряд?
>
Да, читается подряд. Как это отменяет номера страниц?
> 4. Насчет "практика - критерий истины" можно сказать следующее: все
> известные мне веб-форумы действительно пользуются таким методом. И я как
> пользователь этих форумов утверждаю, что это с т.зрения интерфейса
> примитивное и неудобное убожество. Пользователю нужен не только простой,
> но и удобный интерфейс, а его принуждают пользоваться неудобным
> барахлом. И делается это не от того, что нельзя придумать удобнее, а
> потому, что неудобное барахло уже есть и использовать его гораздо проще,
> быстрее и дешевле для владельцев форума.
Я так и не понял, как можно сделать лучше.
--
Andrew Lesnichenko
>> 2. Как, интересно, проще запомнить страницу ветки форума, если
>> содержимое постоянно меняется?
>
> Это помнит браузер. Поэтому, когда я читал, например, страницы 1..9, а
> позднее появилась страница 10, это сразу видно, потому что браузер
> показывает цветом.
В данном случае есть ряд неявных предположений:
1. Все сообщения отсортированы в порядке возрастания времени отправки.
2. Все сообщения расположены плоским списком, подряд.
П.1 не всегда выполняется. Я, например, могу захотеть отсортировать по
датам в обратном порядке. Более того, обычно таким образом сортируются
темы (сперва идут темы, на которые есть самые свежие ответы).
П.2 предполагает отсутствие всякой иерархии ответов друг другу, а это
крайне неудобно.
>> 3. Пример в гуглом (поисковиком), который возвращает результаты
>> поиска, некорректен, поскольку это свободный поиск, качество которого
>> целиком определяется качеством вопроса, и раз уж вернулось 200 экранов
>> ссылок, то никуда не денешься. И еще раз - какой физический смысл
>> выбирать из этих 200 экранов 3-й, потом 15-й, потом 8-й, вместо чтения
>> подряд?
>>
> Да, читается подряд. Как это отменяет номера страниц?
А кто говорит про отмену номеров страниц? Я говорю про то, что читают
эти страницы подряд, а не вразнобой.
> Я так и не понял, как можно сделать лучше.
>
Ну вы же Mozilla'ой читаете :) Как там сделан интерфейс ньюсов :) ?
--
Andrew Lesnichenko
Ivan Frolkov
AL> барахлом. И делается это не от того, что нельзя придумать удобнее, а
AL> потому, что неудобное барахло уже есть и использовать его гораздо проще,
AL> быстрее и дешевле для владельцев форума.
Альтернативы? ЖЖ? Так там не удобней - и, забавно, что явно видно, как у них
база сообщений лежит в двух таблицах :-)
Alexander Goldun
> Да мне наплевать на Microsoft, я их продукцией практически не пользуюсь.
> Пусть
> (к слову о проектировании интерфейсов) сначала научатся в Windows сортировать
> имена файлов так, чтобы "9. Девятая песня.mp3" шло впереди "10. Десятая песня
> ..mp3" (что давным-давно сделано, например, в MacOS).
Совершенно случайно только что обнаружил, что оказывается в WinXP именно
так и сортирует. Только корректность такой сортировки не менее спорна,
чем вывод нумерованных страниц на сайтах. Если я буду так же упираться в
догмы и теории, то скажу что пофиг удобство юзера, сортировка
некорректна - не по алфавиту по имени. Может эти цифры в имени имеют для
меня другой смысл, отличный от нумерации песен?
Andrew Grachyov
Monday January 16 2006, Vladimir Pavlikov writes to Andrew Grachyov:
VP> Да тот же прайс, к примеру. Указываешь нежесткие критерии, и получаешь
VP> 20 страниц, отсортированных по ценам. Первая половина, состоящая, как
VP> правило, из сомнительных подвалов, малоинтересна. Последняя четверть
VP> тоже - зачем платить лохоразводителям? Т.е. я, к примеру, иду сразу на
VP> 12-ю страницу. Затем по ипсилон-окрестности. Странно, что тебе незнаком
VP> этот сценарий.
Hожет быть и так. Hо все pавно, для pеализации доступа такого pода
использовал бы куpсоp, а не констpукцию "select c n-й по m-ю". В котоpой,
кстати, почти навеpняка эти паpаметpы не паpаметpизуемы.
Пока.
Andrew Grachyov.
Andrew Grachyov
Sunday January 15 2006, Andrew Lening writes to Andrew Grachyov:
AG>> А это как?
AL> Знаешь фразу "практика - критерий истины"?
Фpазу знаю - и в школе и в унивеpситете учил. Вот только пpи чем здесь это?
AL> Так вот, такой механизм
AL> применяет в веб-приложениях практически ВЕЗДЕ. В том числе гугль,
AL> яндекс и
AL> прочие поисковики, все известные мне веб-форумы и так далее.
Какой такой механизм? Вначале показывается пеpвые (скажем) 10, затем
следующие и т.д. FETCH NEXT pулит. Впpочем, если кому-то обсуждаемый
механизм нужен - пусть будет, я не возpажаю.
Вот только одно описание конкpетного синтаксиса SQL тепеpь занимает по 500
стаpниц, и все больши и больше из него ISAM начинает тоpчать. Пpо
совместимость и поддеpжку стандаpтов я вообще не говоpю.....
AL> Утверждать,
AL> что это все делается от неспособности придумать что-то более удобное
AL> -
AL> по-меньшей мере самонадеянно.
Енто, товаpищ, не ко мне. И не по делу - pечь не совсем об этом.
Пока.
Andrew Grachyov.
Vladimir Pavlikov
You wrote to Vladimir Pavlikov on Thu, 26 Jan 2006 20:54:00 +0300:
AG> Monday January 16 2006, Vladimir Pavlikov writes to Andrew Grachyov:
VP>> Да тот же прайс, к примеру. Указываешь нежесткие критерии, и получаешь
VP>> 20 страниц, отсортированных по ценам. Первая половина, состоящая, как
VP>> правило, из сомнительных подвалов, малоинтересна. Последняя четверть
VP>> тоже - зачем платить лохоразводителям? Т.е. я, к примеру, иду сразу на
VP>> 12-ю страницу. Затем по ипсилон-окрестности. Странно, что тебе
VP>> незнаком этот сценарий.
AG> Hожет быть и так. Hо все pавно, для pеализации доступа такого pода
AG> использовал бы куpсоp, а не констpукцию "select c n-й по m-ю". В
AG> котоpой, кстати, почти навеpняка эти паpаметpы не паpаметpизуемы.
Констpукция "select c n-й по m-ю" возвращает курсор. Или ты о каком-то
другом курсоре?
Не вижу причин, по которым конструкция д.б. непараметризуема.
Соответственно, откуда "почти навеpняка"?
Ну и, наконец - контекст. Который легко потерять при реагировании
с 10-дневной задержкой :), напоминаю :
> Как показывает мой опыт общения с поисковиками и/или стpаницами,
> постpоенными с учетом возможности пеpехода на нужную стpаницу
> (www.price.ru, google), то типичный алгоpитм моей pаботы - посмотpел
> пеpвую стpаницу, затем втоpую, если не нашел - то меняю условие. Я
> никогда (навеpное :-) ) не заходил на 4-ю или 18-ю стpаницу
Мое письмо всего лишь демонстрирует, что "мой опыт" не полностью
покрывает множество осмысленных сценариев работы. Т.е. все лозунги
о безграмотности интерфейсов со страничными переходами являются
лишь следствием полного отсутствия опыта работы в этой сфере и
нежелания (или неумения) провести элементарный анализ группы
несложных (в рамках темы) задач. Другими словами, речь вовсе не о
конструкциях реализации, а о подходах к организации :)
With best regards, Vladimir Pavlikov. E-mail: v...@soil.msu.ru
--