|
Действия ...
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
28.03.2004, 01:52
|
|||
|---|---|---|---|
|
|||
Большие объемы с помощью ADO .NET |
|||
|
#18+
Есть проблема, связанная с просмотром огромной таблицы. Есть таблица с информацией о клиентах (или продуктах), которая содержит очень много записей. Много означает, что если выбирать все записи из таблицы и сохранять их в Dataset, то это ОЧЕНЬ ДОЛГО. Раньше (до ADO.NET) можно было использовать курсоры как-то настраивая ..., сейчас же Dataset - это отсоединенный источник данных. Я использую Windows Application, данные из таблицы просматриваются с помощью DataGrid. Какие варианты решения можно предложить? Буду рад любым конструктивным идеям! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.03.2004, 16:39
|
|||
|---|---|---|---|
Большие объемы с помощью ADO .NET |
|||
|
#18+
Первое и самое главное откуда тянем записи? (MS SQL, Access or other) Второе зачем клиенту ВСЕ записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.03.2004, 01:42
|
|||
|---|---|---|---|
|
|||
Большие объемы с помощью ADO .NET |
|||
|
#18+
данные из SQL Server и он находится на другой машине, на которой еще лежат другие используемые базы. В том то и дело, что пользователю не обязательно видеть сразу все записи. Задача - сделать удобную навигацию+высокая производительность при больших объемах таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.03.2004, 01:59
|
|||
|---|---|---|---|
Большие объемы с помощью ADO .NET |
|||
|
#18+
Могу посоветовать наиболее распространённый в таких случаях вариант: создать фильтр на форме, на основании которого будет генерироваться SQL-запрос из таблиц/-ы базы данных, после на основании этого запроса будет заполняться DataSet. Фильтр - это, например, ограничение дат (с какого-то - по такое-то число), выбор тех записей, где в таком-то поле первые буквы такие-то такие-то и т.д. - т.е. заставь пользователя максимально конкретизировать выборку данных - ему наверняка не понадобятся все полмиллиона записей, а так по поиску и он быстрее найдёт что ищет, и программа будет оптимально быстро работать. Есть ещё варианты - чтение данных порциями, например по 100 записей. Тут запрос уже генерируется несколько иначе: "SELECT TOP 100 * FROM TABLE1" и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.03.2004, 08:10
|
|||
|---|---|---|---|
Большие объемы с помощью ADO .NET |
|||
|
#18+
>Задача - сделать удобную навигацию+высокая производительность при больших объемах таблицы. Согласен с Axeleron - поиск, фильтрация на стороне сервера и порционная загрузка с использованием хранимых процедур (MS SQL Serverа). Также предостерегаю от использования метода порционной загрузки DataAdapterа так как он потащит все равно все записи. Все делайте через хранимые процедуры MS SQL Server. И еще по поводу фильтров - ограничения надо делать и на сами фильтры, представьте что пользователь может задать такое - что вернет слишком большое, для помещения в кэш, число записей, хотя ограничения на фильтр можно обойти комбинацией: фильтрации и порционной загрузки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.03.2004, 16:44
|
|||
|---|---|---|---|
|
|||
Большие объемы с помощью ADO .NET |
|||
|
#18+
с идеей фильтров на форме - это понятно неясен один момент: пользователь выбирает фильтр на форме, формируется SQL-запрос с соответствующим фильтром, данные тянутся с сервера и заполняют DataSet. Получается, каждый раз когда юзер выбирает новый фильтр, в DataSet с сервера закачивается новая порция данных (с другим фильтром). Вопрос: можно ли объединить данные, чтобы каждый раз когда юзер выбирает новый фильтр, чтобы данные объединялись с уже выкачанными раннее и чтобы не качались уже выкачанные записи? Есть ли для этого стандартные средства? (Понятно, что можно вручную пройтись по записям и подобавлять) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.03.2004, 03:41
|
|||
|---|---|---|---|
Большие объемы с помощью ADO .NET |
|||
|
#18+
Конечно же, есть. Метод Merge у DataSet ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.03.2004, 10:41
|
|||
|---|---|---|---|
Большие объемы с помощью ADO .NET |
|||
|
#18+
Метод Merge у DataSet Я конечно извиняюсь, но не напоминайте мне пожалуйста про этот метод, я с ним уже 2 недели борюсь с переменным успехом. Странный метод, непонятно когда он будет раотать, а когда только мозги компостировать. Тотже самый код работающий на локальной машине отказывается работать на ВэбСервисе. Полный дурдом. Я сделал всё что мог, кто может пусть сделает лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.03.2004, 11:03
|
|||
|---|---|---|---|
Большие объемы с помощью ADO .NET |
|||
|
#18+
Вариантов множество - ручной способ будет работать нисколько не хуже стандартных методов. Только вручную добавлять тоже надо с умом. Только для чего это надо, ну захотел пользователь больше данных поставил в OR в WHERE и получил сразу же необходимый результат. Это будет работать быстрее чем изголяться через еще один DataSet (переливая данные из одного в другой). Хотя все надо самому прощупать и попробовать, и пользователь может захотеть очень много и тут тогда порционную загрузка придется использовать, либо обламывать с такими запросами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=20&mobile=1&tid=1439360]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
2ms |
| others: | 262ms |
| total: | 390ms |
| 0 / 0 |
