Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
Вот написал такую процедуру (ASE 12.5.3) Код: 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. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. потом Код: plaintext 1. ну вроде как все работает, одно но, хочу универсальную процедурку, как видно по коду необходимо делать две темповые таблицы, как можно получить структуру данных из входящего запроса и по ним уже сделать CREATE TABLE? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2005, 16:21 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
Лучше даже наверное вот так, что-то типа как LIMIT в mysql Код: 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. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2005, 16:44 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
если включены соответствующие опции (кажется select into/bulk copy), то должен работать запрос типа Код: plaintext это автоматом создаст таблицу #temp ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2005, 17:49 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
да я знаю что так возможно, но вот это будет выдавать ошибку Код: plaintext 1. 2. тем более это немного не подходит, у меня на входе запрос, он может быть сколь угодно каким большим, с джойнами и так далее, слишком сложно его будет распарсить и сделать из select ЧТО-ТО from ЧТО-ТО похожее на select ЧТО-ТО into #table_1_page from ЧТО-ТО хотя... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.12.2005, 18:04 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
Да, не жалко вам сервака-то своего... Пейджер на клиенте делать надо, или на сервере приложений (WEB). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2005, 02:55 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
а вы думаете что на сервере приложений это будет быстрее работать? тем более базавоз хорошая 2-хпроцессорная машина, зачем ей просто так простаивать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2005, 19:08 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
Затем что базе данных можно найти лучшее применение. А именно - обработка данных. А формирование представления данных - задача клиента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2005, 16:03 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
MasterZivДа, не жалко вам сервака-то своего... Пейджер на клиенте делать надо, или на сервере приложений (WEB). В принципе согласен, но есть одно "но". Если запрос выдает много строк, пользователь просматривает мало (а он всегда просматривает мало, если не строит аналитических отчетов), то сеть и сервер будут грузиться в основном обработкой и передачей ненужных данных. А если таких пользователей много, то возникнут проблемы. Это довольно распространенная ситуация, например у нас в запрос могут попасть тысячи строк, и только 5-10 реально просматриваются пользователем, остальное мусор. А задать фильтр среднего менеджера заставить невозможно, он думает что ему нужно все и чем у больше информации тем лучше он увидит закономерности. В этом случае ИМХО все-таки лучше на сервере. Вопрос интересный, кто как поступает в этом случае? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2005, 23:30 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
c127Это довольно распространенная ситуация, например у нас в запрос могут попасть тысячи строк, и только 5-10 реально просматриваются пользователем, остальное мусор. А задать фильтр среднего менеджера заставить невозможно, он думает что ему нужно все и чем у больше информации тем лучше он увидит закономерности. Какая знакомая ситуация. А еще бывает что нужно видеть 5-10-20 строк отобранных по определенным критериям и одновременно итоги по всем записям (что-то вроде: всего; из них таких-то столько-то, далее поименно) В этом случае разбивка на сервере не особо поможет, если только не считать в процедуре эти итоги отдельно. По поводу "кто как поступает в таких случаях" - мы используем форму поиска, в которой пользователь может задавать произвольные ограничения на выборку, в понятных ему терминах. Если же не заданы никакие условия, то перед выполнением запроса выдается предупреждение, что выборка всех данных может занять длительное время. И если пользователь согласился с этим - пусть ждет. Хотя это не самый лучший вариант. Тем не менее, некоторые пользователи принципиально не хотят пользоваться поиском, предпочитая, искать в огромном списке, по старинке, "глазками". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 06:30 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
c127 Это довольно распространенная ситуация, например у нас в запрос могут попасть тысячи строк, и только 5-10 реально просматриваются пользователем, остальное мусор. А задать фильтр среднего менеджера заставить невозможно, он думает что ему нужно все и чем у больше информации тем лучше он увидит закономерности. Это все лечится, правильным проектированием БД и интерфейса и невозможностью генерации ad-hoc запросов менеджером. На крайний случай делается жесткая отсечка наприм. по 1000 записей с выдачей сообщения об ошибке или предупреждения , что показано не все, сделайте критерий выборки более точным. c127 В этом случае ИМХО все-таки лучше на сервере. ЧЕМ лучше ? Вопрос риторический. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2005, 14:42 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
MasterZiv Это все лечится, правильным проектированием БД и интерфейса и невозможностью генерации ad-hoc запросов менеджером. Согласен, этим лечится все, но вопрос как раз том, какое проектирование в этом случае называется правильным. Для меня вопрос актуальный, интересно мнение уважаемых специалистов. MasterZiv На крайний случай делается жесткая отсечка наприм. по 1000 записей с выдачей сообщения об ошибке или предупреждения , что показано не все, сделайте критерий выборки более точным. А как в этом случае клиент будет заниматься прокруткой по всем записям, сортировкой и прочими прелестями, если он из 1млн получил только 1000. Насколько я понял Вы как раз агитировали передавать все на клиент и там разбираться с прокруткой (Да, не жалко вам сервака-то своего... Пейджер на клиенте делать надо, или на сервере приложений (WEB)), или я что-то недопонял? MasterZiv ЧЕМ лучше ? Вопрос риторический. На этот вопрос Вы уже сами себе ответили на пару строчек выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 02:44 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
прошу прощения, сама идея, постраничного вывода, меня очень волнует в последнее время. нелзя ли получить пояснения на предмет: использования пейджера. что это такое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 05:44 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
panuпрошу прощения, сама идея, постраничного вывода, меня очень волнует в последнее время. нелзя ли получить пояснения на предмет: использования пейджера. что это такое? Почему это так волнует? Делаете интерфейс для клиента? И, объясните зачем делаете пэйджер?... Наверно чтобы просмотр таблицы на клиенте не жрал много серверных ресурсов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 10:02 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
с127Согласен, этим лечится все, но вопрос как раз том, какое проектирование в этом случае называется правильным. Для меня вопрос актуальный, интересно мнение уважаемых специалистов. Ну вот у нас было так (на примере актов сдачи работ) Задача - показать акты сдачи работ на заданную дату. Делалось так: Пользователь на юрлице нажимает пункт меню "Акты сдачи работ по периодам". Ему в дереве раскрываются периоды - 1-вый квартал, второй квартал, и т.п. (для каждого года). Далее он раскрывает квартал - получает месяца, и в каждом месяце - по неделям или по декадам (десять дней). И вот только когда он выберет декаду или неделю, тогда ему за эту неделю выдаются нужные документы. Последний период подбирается специально так, чтобы в нем документов было немного, не более 1000. А дальше они все сосуться на клиента и он с ними уже в гриде разбирается сам. с127 А как в этом случае клиент будет заниматься прокруткой по всем записям, сортировкой и прочими прелестями, если он из 1млн получил только 1000. Не, я ни в коем случае не против применения ограничивающих выборку критериев. Наоборот, их надо применять. Но уж если тебе тупой пейджер по выборке нужен, делать его на сервере не нужно и сложно (в реально многопользовательской среде надо сохранять выборку и затем уже ее дергать из контекста коннекции, чтобы данные были непротиворечивые). Так уж лучше засунуть это в сервер приложений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 10:13 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
panuпрошу прощения, сама идея, постраничного вывода, меня очень волнует в последнее время. нелзя ли получить пояснения на предмет: использования пейджера. что это такое? наверно это от слова page - страница ... а пейджер здесь, имхо, постраничная начитка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 10:14 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
panuпрошу прощения, сама идея, постраничного вывода, меня очень волнует в последнее время. нелзя ли получить пояснения на предмет: использования пейджера. что это такое? Пейджер - это что-то, что ловит данные, накапливает их и показывает потом постранично. Как less more в xNIX. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 10:14 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
Интересно, как бы вы такую задачу решали: Есть таблица, в таблице ~5млн записей - фамилия, имя, отчество, дата рождения. В поле вводится начальные буквы фамилии, а в гриде сразу перескакивает на нужную запись? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 11:02 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
gardenmanИнтересно, как бы вы такую задачу решали: Есть таблица, в таблице ~5млн записей - фамилия, имя, отчество, дата рождения. В поле вводится начальные буквы фамилии, а в гриде сразу перескакивает на нужную запись? абстрактная идея без конкретики: как записная книжка - разбивка по первой букве ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 11:39 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
sybdba gardenmanИнтересно, как бы вы такую задачу решали: Есть таблица, в таблице ~5млн записей - фамилия, имя, отчество, дата рождения. В поле вводится начальные буквы фамилии, а в гриде сразу перескакивает на нужную запись? абстрактная идея без конкретики: как записная книжка - разбивка по первой букве Ну-ну...) разобьем по первой букве 5000000/32=156250 Это столько на рабочую станцию тянуть что-ли?... В таком случае быстее всего будет идти поиск по Ъ и Ь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 12:07 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
2 gardenman Если 5млн записей, то на одну фамилию будет несколько сотен/тысяч совпадающих И/О. Таким образом попасть на правильную запись невозможно даже набрав ВСЮ фамилию. Решение. Имена, отчества будут совпадать часто. Можно создать справочник имен и отчеств (может быть и фамилий). В основной таблице хранить только коды. Дается выбор мужчина/женщина (эргономичнее нажатием клавиши с автоматическим переходом к гриду после одной набранной буквы: м или ж) 3 поля с гридами по Ф И О из справочников Если в одной местности, то повторяемость Имен/Отчеств будет значительной и можно сделать выпадающий список как альтернативу. Затем по кнопке или по вводу формируется динамический sql-запрос (или др. если инструментарий позволяет) на те поля, которые непустые по кодам из справочника. По полям код_Ф, код_И, код_О в основной таблице делается индекс. Возможно для очистки справочников от экзотических имен при удалении последней записи с именем в основной таблице удалять это имя в справочнике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 14:10 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
А что - нормально. Тяп-ляп. Дорогие пользователи. Нате - трахайтесь!.. Мда... Представляю, с какой скоростью будет работать написанный вами интерфейс... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 14:49 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
2 gardenman А задачу описать не по-Бобруйски слабо? На PowerBuilder + ASE для определенного круга задач и определенного круга пользователей весьма нормальное решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 17:45 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
gardenmanИнтересно, как бы вы такую задачу решали: Есть таблица, в таблице ~5млн записей - фамилия, имя, отчество, дата рождения. В поле вводится начальные буквы фамилии, а в гриде сразу перескакивает на нужную запись? Я бы сделал дерево из начальных кусков фамилии. При чем можно даже статистически сделать чтобы более-менее равномерно выбирать куски. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 22:28 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
Vlad_51812 gardenman Если 5млн записей, то на одну фамилию будет несколько сотен/тысяч ... Вот очень хорошая идея и здравая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2005, 22:31 |
|
||
|
Постраничный вывод, помогите доделать
|
|||
|---|---|---|---|
|
#18+
MasterZiv Ну вот у нас было так (на примере актов сдачи работ) Задача - показать акты сдачи работ на заданную дату. Делалось так: Пользователь на юрлице нажимает пункт меню "Акты сдачи работ по периодам". Ему в дереве раскрываются периоды - 1-вый квартал, второй квартал, и т.п. (для каждого года). Далее он раскрывает квартал - получает месяца, и в каждом месяце - по неделям или по декадам (десять дней). И вот только когда он выберет декаду или неделю, тогда ему за эту неделю выдаются нужные документы. Последний период подбирается специально так, чтобы в нем документов было немного, не более 1000. А дальше они все сосуться на клиента и он с ними уже в гриде разбирается сам. Да, это хорошее решение, но в данном случае критериий четко известен. У нас много параметров, заранее все не распишешь, к тому же менеджер хочет задавать разные запросы. Поэтому может оказаться что в результат запроса попадут все или почти все записи. Вот с этим и боремся. MasterZiv с127 А как в этом случае клиент будет заниматься прокруткой по всем записям, сортировкой и прочими прелестями, если он из 1млн получил только 1000. Не, я ни в коем случае не против применения ограничивающих выборку критериев. Наоборот, их надо применять. Но уж если тебе тупой пейджер по выборке нужен, делать его на сервере не нужно и сложно (в реально многопользовательской среде надо сохранять выборку и затем уже ее дергать из контекста коннекции, чтобы данные были непротиворечивые). Так уж лучше засунуть это в сервер приложений. Я говорил немного о другом. Если просто ограничить количество записей на клиенте, например 1000, а потом пользователь отсортирует их в убывающем порядке по какому-то полю, то наверх попадет не та запись, которая имеет максимальное значение в этом поле в базе, а только та, которая попала на клиент. Т.е. получается что либо сортировку делать в базе и потом вытаскивать 1000 записей, либо на клиент тащить все записи, а этого бы не хотелось. С сервером приложений проблема как раз в синхронизации. В базе записи меняются, и вообще много чего меняется, это все нужно реплицировать на сервер приложений и ничего не забыть, это та еще задача. К тому же на СКЛ-е многие вещи пишутся легче чем на процедурных языках, а сервер приложений СКЛ не поддерживает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2005, 02:03 |
|
||
|
|

start [/forum/topic.php?fid=55&fpage=92&tid=2013189]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
36ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 269ms |
| total: | 419ms |

| 0 / 0 |
