Лучшие практики для отображения больших списков

Question

Существуют ли передовые практики для возврата пользователям больших списков заказов?

Позвольте мне попытаться обрисовать проблему, которую мы пытаемся решить. У нас есть список клиентов, которые имеют 1-5 000 + заказов, связанных с каждым. Мы извлекаем эти заказы непосредственно из базы данных и представляем их пользователю в виде разбитой на страницы сетки. У нас очень простое представление «выбрать столбцы из заказов», которое отлично работало, когда мы только начинали, но по мере роста оно вызывает проблемы с производительностью и конфликтами. Похоже, есть миллион и один способ обшарить эту кошку (вернуть только данные на одну страницу, вернуть только данные за последние 6 месяцев и т. Д.), Но, как я уже говорил, мне просто интересно, есть ли какие-нибудь ресурсы, которые предоставляют немного больше руки о том, как решить эту проблему.

Мы используем SQL Server в качестве базы данных транзакций и отбираем данные в формате XML. Затем мы используем смесь XSLT и Javascript для создания нашей сетки. Мы не женаты на решении для презентаций, но женаты на решении для баз данных.

Answer 1

Мой опыт.

1. Всегда устанавливайте значения по умолчанию в пользовательском интерфейсе для разумного пользователя.Вы не хотите, чтобы они нажимали «Получить» и получали все.
2. Установите ограничение на количество записей, которые могут быть возвращены.
3. возвращать из базы данных только те записи, которые вы собираетесь отображать.
4. Если важна согласованность вперед / назад, сохраните весь набор результатов запроса во временной таблице и верните только страницувам нужно отобразить.При поиске вверх / вниз получить следующий набор из временной таблицы.
5. Убедитесь, что ваши индексы покрывают ваши запросы.
6. Используйте разные запросы для разных целей.Подумайте «Открытые заказы» против «Закрытые заказы».Они могут работать намного лучше, чем разные запросы вместо одного общего запроса.
7. Установка параметров по умолчанию в хранимых процедурах.Защитите ваш запрос от пользовательского интерфейса, который не устанавливает разумных ограничений.

Хотелось бы, чтобы мы все это сделали.

Answer 2

Глупый вопрос, но спрашивали ли вы пользователей вашего приложения о том, какие записи они хотели бы видеть изначально?

Answer 3

Я не совсем уверен в вопросе, какую именно проблему пользовательского интерфейса вы пытаетесь решить.

Если клиент не может работать с таблицей, представляющей собой только один большой аморфный шарик, то пустьСортировка по полям: дата заказа, номер заказа, номер вашего SKU, его номер SKU, может быть, и я думаю, другие тоже. Он может найти удобным сделать мультиколонкастабильная сортировка тоже.

Если заголовки таблиц прокручиваются вверх и исчезают, когда он прокручивает свои заказы, это сложнее. Прочитайте ТАКИЕ обсуждения , чтобы увидеть, дает ли метод там решение, которое вы можете использовать.

Существует также механизм JQuery для сохранения заголовка в области просмотра.

HTH

РЕДАКТИРОВАТЬ: плюс я буду второй ответ @Iain: выполнить профилирование.
Еще один РЕДАКТИРОВАТЬ: @Scott Bruns ответ напомнил мне, что, когда мы начали разрабатыватьUI, самой большой проблемой на сегодняшний день было ограничение количества записей,Пользователь должен был посмотреть.Итак, да, я согласен со Скоттом, что вы должны дать пользователю возможность увидеть только ограниченное количество записей с самого начала;то есть, прежде чем он когда-либо увидит стол, он много рассказал вам о том, что он хочет видеть.

Answer 4

Я бы порекомендовал провести некоторое профилирование, чтобы найти фактические узкие места.Возможно, у вас есть доступ к Visual Studio Profiler?http://msdn.microsoft.com/en-us/magazine/cc337887.aspx Существует множество хороших профилировщиков.

В противном случае, моей первой остановкой было бы разбиение на страницы для получения меньшего количества записей из БД, что облегчает соединение и занимает меньше места в памяти.Посмотрите на это (я предполагаю, что вы на SQL Server> = 2005) http://www.15seconds.com/issue/070628.htm