У меня была дискуссия с коллегой на работе, речь шла о SQL-запросах и сортировке. У него есть мнение, что вы должны позволить серверу выполнять сортировку перед возвратом строк клиенту. Я, с другой стороны, полагаю, что сервер, вероятно, достаточно занят, как есть, и для производительности должно быть лучше, чтобы клиент мог обработать сортировку после того, как он извлек строки.
Кто-нибудь, какая стратегия лучше всего подходит для общей производительности многопользовательской системы?
В общем, вы должны позволить базе данных выполнять сортировку; если у него нет ресурсов для эффективного решения этой проблемы, вам необходимо обновить сервер базы данных.
Во-первых, база данных может уже иметь индексы в полях, которые вы хотите, поэтому для получения данных в отсортированном порядке может быть тривиальным. Во-вторых, клиент не может сортировать результаты, пока у них не будет всех; если сервер сортирует результаты, вы можете обрабатывать их по одной строке за раз, уже отсортированные. Наконец, база данных, вероятно, более мощная, чем клиентская машина, и, возможно, более эффективно выполняет сортировку.
Это зависит... Есть ли пейджинг? Каков максимальный размер набора данных? Нужно ли всю совокупность данных сортировать один и тот же путь все время? или в соответствии с выбором пользователя? Или (если задействован пейджинг), нужно ли сортировать только записи на одной странице на экране клиента? (обычно это не приемлемо) или весь набор данных необходимо отсортировать, а страница одного из вновь отсортированного набора будет повторно отображаться?
Какое распределение клиентского оборудования по сравнению с требованиями к обработке этой операции сортировки?
нижняя строка; Это общий пользовательский опыт (измеренный от стоимости курса), который должен контролировать ваше решение... В общем, клиентские машины работают медленнее серверов и могут вызывать дополнительную задержку.... ... Но как часто клиенты будут запрашивать дополнительные пользовательские операции сортировки после загрузки начальной страницы? (клиентский вид данных уже на клиенте намного быстрее, чем в оба конца...) Но сортировка на клиенте всегда требует, чтобы весь набор данных был отправлен клиенту при начальной загрузке... Это задерживает отображение страницы инициалов.., которая может потребовать ленивой загрузки, или AJAX, или других технических сложностей для смягчения...
Сортировка на сервере otoh, добавляет дополнительные проблемы с масштабируемостью и может потребовать, чтобы вы добавили больше полей в ферму серверов для работы с дополнительной нагрузкой... если вы делаете сортировку в БД и достигаете этого порога, который может усложняться, (Чтобы масштабировать DB, вам нужно реализовать некоторую схему репликации только для чтения или другое решение, которое позволяет нескольким серверам (каждый из которых выполняет обработку) делиться данными только для чтения).
Я в пользу ответа Робертса, но я хотел добавить немного к нему.
Я также предпочитаю сортировку данных в SQL Server, я работал над многими системами, которые пытались сделать это на стороне клиента, и почти в каждом случае нам пришлось переписать процесс, чтобы он выполнялся внутри SQL Сервер. Почему вы можете спросить? У нас есть две основные причины.
Мы имеем дело с интерфейсами, которые показывают пользователям очень большие наборы данных, а использование возможностей SQL Server для обработки сортировки и подкачки намного лучше, чем выполнение на стороне клиента.
Чтобы поместить некоторые номера в это, сортировка на стороне SQL Server на стороне клиента сортируется в нашей среде, а не подкачки для обоих. Сторона клиента 28 секунд, используя XML для сортировки, и общее время загрузки на стороне сервера 3 секунды.
В общем, я согласен с высказанными выше взглядами, что сортировка на стороне сервера обычно является способом выхода. Однако иногда есть причины для сортировки на стороне клиента:
Важно помнить, что при балансировке нагрузки между мощными клиентами и сервером теоретически может быть хорошей идеей, только сервер может поддерживать индекс, который обновляется на каждой вставке. Независимо от того, что делает клиент, он начинается с неиндексированного несортированного набора данных.
Если сортировка просто косметическая, и клиент получает весь набор данных, я бы склонялся к тому, чтобы клиент обрабатывал ее, как о представлении.
Кроме того, скажем, в сетке вам может потребоваться выполнить сортировку в клиенте в любом случае, так как пользователь может изменить порядок, щелкнув заголовок столбца (не хотите, чтобы сервер запрашивал всю информацию )
Как обычно, " Он зависит от":)
Если у вас есть хранимая процедура, например, которая отправляет результаты на ваш уровень представления (будь то отчет, сетка и т.д.), вероятно, не имеет значения, с каким методом вы работаете.
Тем не менее, я обычно сталкиваюсь с просмотрами, которые имеют сортировку (потому что они использовались непосредственно в отчете, например), но также используются другими представлениями или другими процедурами с их собственной сортировкой.
Поэтому, как правило, я рекомендую другим делать все сортировки на стороне клиента и только на сервере, когда есть разумное обоснование для него.
Как и любой другой вопрос, связанный с работой, универсальный ответ... "Это зависит". Однако я предпочитаю сортировку на клиенте. Мы пишем браузерные приложения, и мое определение клиента разделяется между веб-серверами как фактическим клиентом конечного пользователя, браузером. У меня есть две причины для сортировки на клиенте для сортировки в БД.
Во-первых, существует проблема "правильного" места, чтобы сделать это с дизайнерской точки зрения. В большинстве случаев порядок данных не является деловым правилом, а скорее удобной для конечного пользователя, поэтому я рассматриваю его как функцию презентации, и мне не нравится вводить проблемы с презентацией в базу данных. Существуют исключения, например, когда текущая цена для элемента является самой последней в файле. Если вы получаете цену с чем-то вроде:
SELECT TOP 1 price
FROM itemprice
WHERE ItemNumber = ?
AND effectivedate <= getdate()
ORDER BY effectivedate DESC
Тогда порядок строк является частью бизнес-правила и, очевидно, принадлежит базе данных. Однако, если вы сортируете по LastName, когда пользователь просматривает клиента по имени, а затем снова по первому имени, когда они нажимают заголовок столбца FirstName, и снова на State, когда они нажимают на этот заголовок, ваша сортировка является функцией представления и принадлежит слою презентации.
Вторая причина, по которой я предпочитаю сортировку на клиентском уровне, - это производительность. Веб-серверы масштабируются горизонтально, то есть, если я перегружаю свой веб-сервер пользователями, я могу добавить еще один, а другой и другой. У меня может быть столько интерфейсных серверов, сколько мне нужно для обработки нагрузки, и все работает отлично. Но, если я перегружу базу данных, я ввернусь. Базы данных масштабируются по вертикали, вы можете бросить больше аппаратного обеспечения на проблему, конечно, но в какой-то момент это становится слишком дорогостоящим, поэтому я хотел бы, чтобы БД делал выбор, который он должен делать, и позволял клиенту выполнять сортировку, которая это может быть довольно просто.
Ситуации различаются, и измерение производительности важно.
Иногда это очевидно - если у вас большой набор данных, и вас интересует небольшой диапазон отсортированного списка (например, подкачка в приложении UI) - сортировка на сервере сохраняет передачу данных.
Но часто у вас есть одна БД и несколько клиентов, и БД может быть перегружена, пока клиенты не работают. Сортировка на клиенте невелика, и в этой ситуации это может помочь вам масштабировать.
Я предпочитаю настраивать сортировку на клиенте, однако я также полагаю, что большинство операторов SQL должно иметь некоторое разумное предложение ORDER BY по умолчанию. Это очень мало влияет на базу данных, но без нее вы можете столкнуться с проблемами позже. Часто, не осознавая этого, разработчик или пользователь начнут полагаться на некоторый первоначальный порядок сортировки по умолчанию. Если предложение ORDER BY не указано, данные находятся в этом порядке случайно. В какой-то более поздний срок индекс может измениться или данные могут быть реорганизованы, и пользователи будут жаловаться, потому что исходный порядок данных мог бы измениться из-под них.