|
|
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
Есть набор записей (неважно каких) есть желание их получить , но в наборе записей - 1000 строк,а я хочу получить только с 100 по 200 т.е первые 100 select top 100 а остальные как ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2002, 10:56:25 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
Начнем с того, что обязательно должен быть первичный ключ (если такового нет - введи IDENTITY поле). Допустим, Field1 - первичный ключ, тогда Код: plaintext 1. 2. 3. 4. 5. здесь выбираются 200 начиная с 101 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2002, 11:17:49 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
Блин, поправочка: Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2002, 11:21:25 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
2 АнКа - не работает такая штука .. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2002, 11:31:39 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. может так ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2002, 11:40:29 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
по-моему можно как-то так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. можно вставлять во временню таблицу с identity. В любом случае получается горбато ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2002, 11:42:26 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
Спасибо ! Классная идея ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2002, 11:53:07 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
кстати переправленный вариант от АнКа работает на УРА ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2002, 12:00:35 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. Поле, по которому осуществляется сортировка, должно быть уникальным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2002, 12:09:45 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
А если усложнить задачу? Получить N ную порцию из M записей? Причем N и M - задаются пользователем? Эдакий пэйджинг ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2002, 18:55:38 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
Я тут не досуге решил FAQ по этому вопросу написать, доделать полностью не успел, но вот что есть. Выношу на обсуждение, благо есть повод. Glory, ау! У Вас была сделано такая штука, но я теперь хоть убей не могу ее найти. =========================================== Создана тестовая таблица на 10000 записей. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. С полями RowID и DDаte все ясно, про поле NDate - несколько попозже. Задача. Выделить m записей начиная с позиции n. Записи должны быть отсортированы по обратному порядку даты создания (DDate), то есть первыми должны быть самые "свежие" Созданы две хранимые процедуры. Параметр @rfirst - номер первой записи, @rcount - количество возвращаемых записей. Способ 1. Обрезание результатов Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Способ 2. Усовершенствованное обрезание результатов Скорость этого способа выше, так как используется индекс по полю NDate, которое было заполнено следующим образом: Код: plaintext 1. В реальных приложениях его изменение надо проводить через тригер на вставку-изменение. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2002, 22:23:03 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
а если сортировка может быть какой угодно - по возрастанию и убыванию, причем по любому из полей базового запроса ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 00:23:08 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
А кто мешает поставить свой ORDER BY c любыми полями и их комбинациями? В способе 1 это не проблема. Для разных комбинаций полей можно наделать разных процедур. Другое дело способ 2. Он конечно более специфический и требует создания дополнительного поля (полей) обратной сортировки, что легко делается только для числовых данных (включая Datetime). Приведен он главным образом для того, что бы показать, как правильно созданный индекс может увеличить скорость обработки. Если бы в задаче не надо было бы сортировать даты по убыванию, то нужно было бы просто сделать индекс по DDate. А вообще-то данная задача (возвращение N записей, начиная с M-той) порочна по своей сути. Пользователю возвращается не то, что ему нужно, а просто куча информации - пускай сам ищет что ему надо, а мы (разработчики), умываем руки. С этим можно смириться только в интернет-приложениях, типа форума, гостевой книги или чата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 07:09:22 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
Погодите ! Либо я не догоняю, либо все проще ... если есть таблица (в примере от Cat2) известна запись с которой надо начинать ... и кол-во строк ... то тогда можно зацепиться за поле RowID т.е. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Или я неправ ... PS. Какя разница (следить за номером строки или за ее кодом ?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 09:21:15 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
2 Cat2 Glory, ау! У Вас была сделано такая штука, но я теперь хоть убей не могу ее найти. Да где-то это затерялось при переезде форума. Если только админ сообщит номера топиков.... Методы хорошие, только думаю, что т.к. на практике в конечном запросе нужно большее количество стобцов, то я бы во временную таблицу копировал бы только RowID, а потом использовал бы временную и оригинальную таблицу 2Sanek Какя разница (следить за номером строки или за ее кодом ?) А если в RowID имеются "пробелы" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 12:45:55 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
>Glory в примере от Cat2 написанно на чистом SQL Код: plaintext , что в моем понимании есть автоинкрементное поле, т.е. Integer Про пробелы в этом типе данных ничего не сказано , да и в номере строки пробел тоже наврядли появиться .. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 12:52:24 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
Я сегодня отвечал на похожий вопрос о нумерации. Для динамического количества выводимых строк, по моему их надо считать. /topic/9523 здесь примеры какие я знаю для нумерации строк, чуть изменить под данную задачу не трудно. Если поможет буду рад... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 13:06:19 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
"Пробелы" в поле identity могут получится при нормальной работе, например, в результате отакта транзакции Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 13:06:38 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
прошу прощения ! Понял ! Осознал ... и т.п. Нашел ошибку и исправил : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. В этом случае мало интересно пропуски индекса ... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 13:19:40 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
2 Cat2, Sanek Не подумайте только, что я хочу на вас наехать, но ваши скрипты в предложенном варианте у меня возвращают всегда только первую "страницу" Для большего правдоподобия я заполнил тестовую таблицу произвольными значениями RowId Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 14:00:06 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
>Glory Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Попробовал совместно с твоим запросом и все работает нормально , только :) сортировку изменил с NDate на RowID ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 14:19:01 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
Данные примеры показывают способ работы с полем DDate, котрый не коррелирует с кластерным индексом по RowID. Такая корреляция обычно бывает, например, при оформлении каких-то докментов. Значения DDate могут перманентно менятся. A'la время последнего ответа на вопрос в форуме, где RowID означает ID темы, a DDate обновляет тригер последнего постинга в эту тему. Все, что выше этой строки, написано до полного разбора полетов. Ну дела!!! Ну M$ наоптимизировал! После издевательств над базой по методу Glory все любовно выписанное рухнуло. Плевал оказывается MS SQL на всякие там ордер бай при вставке во временные таблицы. И моя вера в физическое расположение записей по кластерному индексу сильно подорвана. Может быть по этому поводу выскажется кто-нибудь из DBA? У меня такое подозрение, что после столь крутых изменений первичного ключа таблицу надо как-то оптимизировать. "Орешек знаний тверд, но все же мы не привыкли отступать..." А как Вам такое извращение? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. С полем NDate ничего пока не придумал. Не работает ни под каким соусом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 20:03:18 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 20:34:39 |
|
||
|
Вот такой вопрос !
|
|||
|---|---|---|---|
|
#18+
Re Vit! В обороте TOP нельзя использовать переменные. Вы не обратили внимание, что надо сортировать по возрастанию даты, а не по кластерному индексу. Конечно, можно использовать динамический SQL, но при более сложных выборках это будет тормозить. Если Вам не лень, попробуйте свой пример на вышеприведенной тестовой таблице, обработаной по методу GLory. Мне честно говоря, сегодня лень. Кстати, на моей памяти, это не то тридцатое, не то сороковое предложение данного способа. Наверное, что-то тут не то, если он так и не стал каноническим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2002, 20:46:33 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32034925&tid=1822022]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
46ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 226ms |
| total: | 371ms |

| 0 / 0 |
