Question

我在工作中与同事讨论过，它是关于SQL查询和排序的。他认为在将行返回给客户端之前，应该让服务器进行任何排序。另一方面，我认为服务器可能很忙，并且在获取行之后让客户端处理排序必须更好。

任何哪种策略最适合多用户系统的整体性能？

Answer 1

通常，您应该让数据库进行排序;如果它没有足够的资源来有效地处理这个问题，则需要升级数据库服务器。

首先，数据库可能已经在您想要的字段上有索引，因此它可能无法按排序顺序检索数据。其次，客户端无法对结果进行排序，直到结果全部为止;如果服务器对结果进行排序，则可以一次处理一行，已经排序。最后，数据库可能比客户端计算机更强大，并且可能更有效地执行排序。

Answer 2

这取决于......是否涉及寻呼？数据集的最大大小是多少？整个数据集是否需要始终以相同的方式排序？还是根据用户选择？或者，（如果涉及分页），是否只需要对客户端屏幕上单页中的记录进行排序？（通常不可接受）或是否需要对整个数据集进行排序，并重新显示新排序集的第一页？

与此排序操作的处理要求相比，客户端硬件的分布是什么？

底线是;这是整体用户体验（当然是根据成本衡量），应该控制您的决策......通常，客户端计算机比服务器慢，并且可能导致额外的延迟。 ... ...但是在初始页面加载后客户端多久会请求一次额外的自定义排序操作？（客户端上的客户端数据比往返更快...）但是在客户端上排序总是要求在初始加载时将整个数据集发送到客户端...这会延迟首字母页面显示...这可能需要延迟加载，或AJAX，或其他技术复杂性来缓解......

在服务器上进行排序，引入了额外的可伸缩性问题，可能需要向服务器场添加更多框以处理额外的负载......如果您在数据库中进行排序并达到该阈值，则可能会变得复杂。（要在数据库上扩展，您必须实现一些只读复制方案，或允许多个服务器（每个处理器）共享只读数据的其他解决方案。）

Answer 3

我赞成罗伯茨的回答，但我想补充一点。

我也赞成在SQL Server中对数据进行排序，我已经在许多系统上尝试过在客户端进行这种操作，几乎在每种情况下我们都必须重新编写进程以在SQL中完成它服务器。你为什么这么问？我们有两个主要原因。

正在排序的数据量
由于＃1

我们处理向用户显示非常大的数据集的接口，并且利用SQL Server的强大功能来处理排序和分页比在客户端执行要好得多。

为了给它添加一些数字，SQL Server Side在我们的环境中排序到客户端排序，没有任何分页。客户端28秒使用XML进行排序，而服务器端排序总加载时间为3秒。

Answer 4

一般来说，我同意上面提到的观点，即服务器端排序通常是要走的路。但是，有时候有理由进行客户端排序：

排序标准是用户可选择的或众多的。在这种情况下，向表中添加大量索引可能不是一个好主意 - 特别是如果插入性能是一个问题。如果很少使用某些排序标准，则索引不一定值得，因为插入的数量将超过选择。
排序条件无法在纯SQL [uncommon]中表示，或者无法编入索引。它不一定是更快的客户端，但它需要加载服务器。

要记住的重要一点是，在理论上平衡强大的客户端和服务器之间的负载可能是一个好主意，只有服务器可以维护一个在每个插入时更新的索引。无论客户端做什么，它都以非索引的未排序数据集开始。

Answer 5

如果排序只是整容，并且客户端正在获取整个数据集，我倾向于让客户端处理它与表示的关系。

另外，在网格中说，您可能必须在客户端实现排序，因为用户可以通过单击列标题来更改排序（不希望要求服务器再次检索所有信息））

Answer 6

像往常一样，“取决于”：）

如果您有一个存储过程，例如，它将结果发送到您的表示层（无论是报表，网格等），那么您使用哪种方法可能无关紧要。

我通常遇到的是具有排序的视图（例如，因为它们直接被报告使用），但是其他视图或其他过程也使用它们进行排序。

作为一般规则，我鼓励其他人在客户端进行所有排序，只有在有合理理由的情况下才在服务器上进行排序。

Answer 7

与任何其他与表现相关的问题一样，普遍的答案是......“它取决于它。”但是，我已经开发出了对客户端进行排序的偏好。我们编写基于浏览器的应用程序，我的客户端定义分为Web服务器和实际的最终用户客户端，浏览器。我有两个理由喜欢在客户端上进行排序以在DB中进行排序。

首先，从设计的角度来看，存在“正确”的地方问题。大多数情况下，数据的顺序不是业务规则，而是最终用户的便利，因此我将其视为演示的一个功能，我不喜欢将演示问题推送到数据库中。例如，有一些例外情况，项目的当前价格是最新的价格。如果您的价格如下：

SELECT TOP 1 price 
FROM itemprice 
WHERE ItemNumber = ? 
   AND effectivedate <= getdate() 
ORDER BY effectivedate DESC

然后行的顺序是业务规则的一部分，显然属于数据库。但是，如果您在用户按姓氏查看客户时对LastName进行排序，然后在他们单击FirstName列标题时再次在FirstName上进行排序，并在他们单击该标题时再次在State上排序，那么您的排序是演示文稿的函数，属于表示层。

我更喜欢在客户端层进行排序的第二个原因是性能。 Web服务器水平扩展，也就是说，如果我使用用户重载我的Web服务器，我可以添加另一个，另一个，以及另一个。我可以拥有尽可能多的前端服务器来处理负载，一切正常。但是，如果我重载数据库，我就搞砸了。数据库垂直扩展，你可以在问题上投入更多的硬件，当然，但是在某些时候成本过高，所以我想让数据库进行选择，它必须做，并让客户端进行排序，它可以非常简单。

Answer 8

我更喜欢客户端上的自定义排序，但我也建议大多数SQL语句默认都应该有一些合理的ORDER BY子句。它对数据库的影响很小，但如果没有它，你可能会在以后遇到问题。通常在没有意识到的情况下，开发人员或用户将开始依赖一些初始默认排序顺序。如果未指定ORDER BY子句，则数据仅按顺序排列。在稍后的某个日期，索引可能会发生变化，或者数据可能会被重新组织，并且用户会抱怨，因为数据的初始顺序可能已从其下方更改。

Answer 9

情况各不相同，衡量表现也很重要。

有时候很明显 - 如果你有一个大数据集并且你对一小部分排序列表感兴趣（例如在UI应用程序中分页） - 在服务器上排序会保存数据传输。

但是通常你有一个数据库和几个客户端，当客户端空闲时，数据库可能会过载。在客户端上排序并不重，在这种情况下它可以帮助您扩展。

Answer 10

在服务器上执行此操作。

如果数据集很大，您的服务器将比客户端更好地处理它。现代数据库服务器具有强大的索引，缓存和物化结构，您的简陋浏览器或客户端应用程序没有

如果数据集很小，则不会对客户端或服务器上的数据集产生任何性能或资源使用影响。

所有这一切都考虑到你的客户端应用程序设计得很好，如果你在客户端上进行排序并且排序参数发生变化（例如当客户端说＆＃39; oooh，现在我想要这个专业您在356个不同的地方引用的jasper报告，其中23个不同的参数现在按姓氏而不是出生日期排序＆＃39;

在服务器或客户端上排序？

10 个答案: