Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
Есть grid на таблицу с огромным количеством записей. Подскажите как лучше организовать подкачку? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2001, 12:08 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
А она нужна? Пользователь должен пролистать 100000 записей, или он должен увидеть что-то конкретное? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2001, 17:27 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
Ну если в записях не картинки, то 100000 это совсем не много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2001, 02:24 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
А мне казалось, что наоборот. Речь ведь не об объёме информации в байтах, а о её восприятии - графический интерфейс появился не ради красивости. Вы в таблицы Брадиса никогда не заглядывали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2001, 04:24 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
1.А она нужна? Пользователь должен пролистать 100000 записей, или он должен увидеть что-то конкретное? Пользователь должен иметь возможность просматривать все записи в таблице, которых может быть не только несколько сотен тысяч, но и несколько миллионов. И найдя нужную запись с ней поработать, но с этим все понятно. 2. А мне казалось, что наоборот. Речь ведь не об объёме информации в байтах, а о её восприятии - графический интерфейс появился не ради красивости. Вы в таблицы Брадиса никогда не заглядывали? Таблицы Брадиса я не только видел, но и пришлось в свое время поработать с ними. Дело не в объеме, дело в том, как дать пользователю возможность просмотреть информацию, быстро найти нужную и обработать. По себе скажу, очень неудобно работать, когда тебе не предоставляют возможность просмотреть всю информацию, а при необходимости(!) отфильтровать по нужным критериям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2001, 08:42 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
Согласен с FomPro. Вываливать на экран нужно такое количество информации, которое пользователь морально готов прочитать. Если же он заведомо не собирается читать содержимое 100000 записей, значит они ему не нужны, и поток данных должен быть ограничен по какому-то критерию, который должен быть задан перед выборкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2001, 08:43 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
Я считаю, что если нет острой необходимости ограничивать пользователя, то не надо этого делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2001, 08:46 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
если пользователь успевает просмотреть 100 записей в секунду, то на простотр 10 млн записей он потратит больше суток. Это время несоизмеримо больше того, которое потратит камнпутер на закачку этих записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2001, 10:47 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
Скорее всего мы все по своему правы. Просто подход к этому вопросу сильно зависит от типа клиентского приложения, и, главное, от скорости соединения между клиентом и сервером. То что для локальных юзеров произойдет влет, может заставить удаленных пойти попить чайку. И безусловно более правильный способ - отправка на клиента минимально возможного количества записей. Вот только на практике добится этого сложно - сильно страдает интерфейс пользователя или неоправданно 'наворачивается' клиент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2001, 02:08 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
1. Тащить все записи в грид это а) аморально б) вредно в) глупо. 2. Если какой нибудь киборг-юзер хочет иметь все записи, нужно убедить его в п.1. Любыми средствами. Безжалостно. 3. В случае провала п.2 либо крайне редкого исключения из п.1 необходимо организовать постраничную оргазизацию. Пусть этот м...к сам занимается подкачкой. Вот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2001, 06:10 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
Вот-вот, и я про то же. А реализация подкачки a) усложняет клиента(прикинте реализацию поиска в гриде например); б) задержка в работе происходит не только при первоначальной закачке данных, но и при каждой последующей. Еще раз повторюс: 100 000 записей на 100Mb сетке залетают на клиента за 5 сек, причем в асинхронном режиме, т.е. c уже закаченными данными можно работать сразу, пока остальные докачиваются. Но если зайти модемом - эти 5 сек вылезут в 5 мин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2001, 07:00 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
Для решения данной проблемы существует несколько путей. 1. Использование серверных курсоров. 2. Использование древовидных справочников с динамической подгрузкой в TreeView только тех частей дерева, которые нужны пользователю. Иерархическая организация данных как раз и позволяет разбить большой массив информации на части, которые хочет отобразить у себя пользователь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2001, 07:25 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
Приветсвую всех! . Не нужно показывать 100 000 тыс. записей в Grid. На то и придумали архитектуру клиент-сервер, чтобы уменьшить сетевой трафик. Клиенту выдавать только необходимую порцию. Я решаю при помощи хранимых процедур. Пользователь решает по каким критериям он хочет увидеть записи. (или они ограничены диопазоном дат, или по фимилии или еще как-то), для каждой выборки пишу отдельную процедуру, и нужную запускаю. Проверьте скорость работы, я не думаю что это так медленно. Что касается серверных курсоров, то я их не использую, они жутко тормозные во-первых, во-вторых сервер может установить блокировку на всю таблицу. Что касается Tree, не все данные подходят что бы их так показать. Не согласен с "Павел", пользовательский интерфес не становится навароченнее, среди 100 000 записей ползователю все равно что-то надо сделать чтобы найти нужное, и какая разница между, что он будет искать и получать очередную порцию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2001, 22:04 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
>Не согласен с "Павел", пользовательский интерфес не становится навароченнее, среди 100 000 записей ползователю все равно что-то надо сделать чтобы найти нужное, и какая разница между, что он будет искать и получать очередную порцию. При закачке сразу всех данных поиск не представляет никикой сложности. А теперь прикинте алгоритм работы при порционной закачке: убедится что искомой записи нет в локальном блоке, найти ее на сервере, вернуть блок содержащий запись клиенту и красиво подменить старый блок на новый. Или это не усложнение клиента? Я не против такого подхода, просто далеко не всегда он оправдан. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2001, 05:47 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
>2. Использование древовидных справочников с динамической подгрузкой в TreeView только тех частей дерева, которые нужны пользователю. Иерархическая организация данных как раз и позволяет разбить большой массив информации на части, которые хочет отобразить у себя пользователь. Скажите, Garya, где об этом можно подчитать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2001, 06:00 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
>разбить большой массив информации на части, которые хочет отобразить у себя пользователь. как то не очень понимаю причем здесь деревья? 2 Павел >При закачке сразу всех данных поиск не представляет никикой сложности. А теперь прикинте алгоритм работы при порционной закачке: убедится что искомой записи нет в локальном блоке, А че, слабо сразу на сервере выбрать искомую запись, не разбивая все записи на блоки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2001, 06:07 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
2 Genady >А че, слабо сразу на сервере выбрать искомую запись, не разбивая все записи на блоки? А слабо понять разницу между отправкой на сервер Select ... Where... и отображением искомой записи в гриде, где пользователь должен видеть расположенные в каком-то порядке скажем 5 предыдущих и пять последующих записей от искомой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2001, 07:23 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
>А слабо понять разницу между отправкой на сервер Select ... Where Наверное таки слабо Тем более, что от многих страниц данных мы пришли всего к 11 строкам - 5 до и 5 после Ну трудно мне понять желание вытащить все данные на клиента и уже здесь их отбирать, потому что сервер подходит для этого лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2001, 07:34 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
>Ну трудно мне понять желание вытащить все данные на клиента и уже здесь их отбирать, потому что сервер подходит для этого лучше. Конечно сервер подходит для этого лучше. Но представьте крайне редко обнавляемый справочник, который может болтаться локально на клиенте весь день, будучи закачан с сервера всего один раз. А Вы предлагаете его порциями весь день с сервера дергать? И нет у меня желания качать на клиента все подряд. Просто нет желания без необходимости прописывать то, без чего вполне можно пока обойтись. Возможно это обычная лень. Но пока тормозов нет, и все счастливы. Появятся тормоза - перепишу. А то о чем пишет Garya я, в действительно узких местах, безусловно использую и всем рекомендую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2001, 07:52 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
>Но представьте крайне редко обнавляемый справочник, который может болтаться локально на клиенте весь день, будучи закачан с сервера всего один раз. Ну не буду Вас отговаривать, хотя я далеко не уверен, то такой подход лучше, особенно если учесть Ваш первый пост. >Есть grid на таблицу с огромным количеством записей. Подскажите как лучше организовать подкачку ? Т. е. все таки не весь справочник закачиваете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2001, 08:13 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
Упс не понял ПавелК и Павел один и тот же человек? Если нет, то в предыдущем моем посте вторая цитата не Павла ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2001, 08:15 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
>Просто нет желания без необходимости прописывать то, без чего вполне можно пока обойтись. Возможно это обычная лень. Но пока тормозов нет, и все счастливы. Появятся тормоза - перепишу. СКУПОЙ ПЛАТИТ ДВАЖДЫ, Павел. Тем более, с таким подходом "потом переписывать" придется уже не Вам =) ... Итак: 1. Загружать на клиента все записи недопустимо. Это аксиома. 2. Необходимо предоставить клиенту возможность просматривать произвольные диапазоны записей. 3. Как? 4. Используя "умный" грид (или не грид). С возможностью типа "показать ближайшие N записей" или там... показать старницу такую-то + всевозможные фильтры и поиски. Причем ессно вся "черновая" работа выполняется на сервере. 5. Это придется воплощать САМОМУ, а не пользоваться готовым г..ном, написанным непонятно кем, как и для чего. 6. Возражения Borland-фанатов не принимаются. 7. Один из возможных вариантов - web-интерфейс. 8. Вопросы? =) =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2001, 13:18 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
> Скажите, Garya, где об этом можно подчитать? На данном форуме, например ... А можно просто пораскинуть мыслями по полочкам. >как то не очень понимаю причем здесь деревья? Представьте себе орго-о-о-о-мный номенклатурный справочник. Записей на 10000000000 . Пользователи сами организуют его в виде дерева. На первом уровне - номенклатурные группы (например, виды товарных групп - кабельная продукция, услуги, металлопрокат, ГСМ, насосное оборудование), на втором - подгруппы (например, по видам торговли имортные / экспортные / СНГ-шные), на третьем подподгруппы (например, для насосного оборудования - по областям применения - бытовые насосы, химические, фекальные, для перекачки абразивных смесей, для перекачки нефти и газа) и т.д. до 10 уровней иерархии. А теперь представь, что ты открываешь этот справочник, но тебе отфильтровалось только 10 записей самого верхнего уровня (а не 10000000000). Далее ты щелкаешь по плюсику возле ноды "насосное обрудование" в TreeView чтобы развернуть содержимое данной папочки. Тут же на сервер идет запрос и автоматом подкачиваются еще 10 записей второго уровня, дочерних для кликнутого узла. Потом еще 10 записей третьего уровня после третьего клика... и т.д. При каждом клике подгружается только 10 записей. А ежели дерево хорошо сбалансировано, то 10 кликами идя по иерархической структуре ты достаточно быстро доберешься до нужного листа дерева, ибо при условии хорошей сбалансированности дерева как раз указанное количество записей (10000000000, то есть 10 в 10 степени) позволяет выбрать визуально из всего этого огромного массива данных нужную запись, подгрузив с сервера всего 100 записей (за все 10 кликов вместе взятых). Конечно, кликать 10 раз муторно, но это гораздо менее муторно, нежели глазами прошаривать одну огромную таблицу с 10000000000 записей, предварительно неделю дожидаясь ее загрузки с сервера. Отдельно зачесалось высказаться по последнему категоричному постингу Cube: >1. Загружать на клиента все записи недопустимо. Это аксиома. Интересно, кто ее автор? Павел привер хороший пример, когда эта аксиома не работает. MS разработала ADO.NET, в которой активно использует буферизацию на клиенте не только данных, но и бизнес-логики сервера (для того, чтобы буферизация смогла эффективно работать), практически доведя эти механизмы до уровня репликации, только не между сервером и сервером, а между сервером и клиентом. Или ты полагаешь, что MS - заблудшая овца? >6. Возражения Borland-фанатов не принимаются А не фанатов? А просто программистов? Которые привыкли не изобретать уже изобретенный велосипед? А тот так можно дойти и до SQL-сервера собственного производства... >СКУПОЙ ПЛАТИТ ДВАЖДЫ, Павел. Тем более, с таким подходом "потом переписывать" придется уже не Вам =) Уж не метите ли вы на его место ? Или вы ученик Нострадамуса, и заранее предвидите его увольнение? У каждого подхода есть плюсы и минусы. Можно сначала достаточно быстро разработать приложение, заранее предусмотрев в нем пути дальнейшей доработки. И производить эти доработки после того, как приложение начало крутиться (пусть и не в идеальном виде) и приносить пользу. А можно очень долго клепать идеальный продукт, и так никогда его и не склепать. А вы сами пробовали реализвать WEB-интерфейс для продукта средней паршивости, завязанного на учетные задачи? Как вы полагаете, во сколько раз разработка такого интерфейса дольше во времени, нежели при использовании RAD того же Borland-а, которого вы так ненавидите? Или того же Access? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2001, 14:33 |
|
||
|
Подкачка данных
|
|||
|---|---|---|---|
|
#18+
Тээкс... =) 2Garya: >> Скажите, Garya, где об этом можно подчитать? >На данном форуме, например ... А можно просто пораскинуть мыслями по полочкам. Исходя из вышеизложенного "древесного" примера (который, имхо, является превосходным подходом к организации данных) я сделал вывод, что я, спрашивая о древидной организации, имел ввиду другое: динамическое n-арное дерево. В принципе реляционные бд для этого не очень предназначены. Но если есть какие-то наработки, то интересно было бы их изучить, чтобы так сказать, "не изобретать велосипед" =). >Отдельно зачесалось высказаться по последнему категоричному постингу Cube: 1. =) Не был бы постинг "категоричным", не "зачесалось" бы... =) 2. Просто в один прекрасный момент я затрахался обильно сдабривать месаги всевозможными "имхо", "по-моему", "как мне кажется", "мой опыт подсказывает мне" и т.д. Да и нет на это времени. Вся эта вода разбавляет концентрированный смысл. 3. Любая точка зрения (даже моя =)=) ) в любой момент может "провалиться". Ну и что? Никто ж на абсолют не претендует... Просто так удобно излагать... >Можно сначала достаточно быстро разработать приложение, заранее предусмотрев в нем пути дальнейшей доработки. И производить эти доработки после того, как приложение начало крутиться (пусть и не в идеальном виде) и приносить пользу. А можно очень долго клепать идеальный продукт, и так никогда его и не склепать. 100% согласен. Как раз по этому необходимо все предвидеть и просчитывать ЗАРАНЕЕ. Чтобы потом не ПЕРЕДЕЛЫВАТЬ. Этому учил меня мой учитель Нострадамус. =) Увольнение Павла я не предвижу - просто пошутил (Нострадамус - мой учитель - тоже много шутил). >Как вы полагаете, во сколько раз разработка такого интерфейса дольше во времени, нежели при использовании RAD того же Borland-а, которого вы так ненавидите? Или того же Access? Извините, но к борланду отношусь спокойно. Ненавижу я акцес =) . Просто борланд расслабляет программерские мозги и жестко фиксирует в собственных границах. И это большой минус. По поводу веб-интерфейса, можно отдельно поговорить. Очень долго перечислять все "за" и, кстати "против". А по поводу "велосипеда" приведу такой пример: название "1С" слышали? Написан на VC. Кто писал на VC - может себе представить. И тем не менее этот "велосипед" почему-то покупают все подряд, и он даже работает, и даже с MS SQL... Такое кино =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2001, 15:26 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32008854&tid=1826241]: |
0ms |
get settings: |
11ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
84ms |
get tp. blocked users: |
2ms |
| others: | 259ms |
| total: | 444ms |

| 0 / 0 |
