小编典典

SQL代码比C#代码快吗?

sql

几个月前,我开始在这家编程公司工作。他们使用的一种实践是在SQL中而不是C#中完成尽可能多的工作。

因此,可以说我有一个编写一些文件列表的简单示例:

是这样的:

string SQL = @"
    SELECT f.FileID,
           f.FileName,
           f.FileExtension,
           '/files/' + CAST(u.UserGuid AS VARCHAR(MAX)) + '/' + (f.FileName + f.FileExtension) AS FileSrc,
           FileSize=
           CASE
               WHEN f.FileSizeB < 1048576 THEN CAST(CAST((f.FileSizeB / 1024) AS DECIMAL(6, 2)) AS VARCHAR(8)) + ' KB'
               ELSE CAST(CAST((f.FileSizeB / 1048576) AS DECIMAL(6, 2)) AS VARCHAR(8)) + ' MB'
           END
      FROM Files f
INNER JOIN Users u
        ON f.UserID = u.UserID
";

// some loop for writing results {
//     write...
// }

更快或更佳的方法是这样的:

string SQL = @"
    SELECT u.UserGuid,
           f.FileID,
           f.FileName,
           f.FileExtension,
           f.FileSizeB
      FROM Files f
INNER JOIN Users u
        ON f.UserID = u.UserID";

// some loop for writing results {
       string FileSrc = "/Files/" + result["UserGuid"] + "/" + result["FileName"] + result["FileExtension"];
       string FileSize = ConvertToKbOrMb(result["FileSizeB"]);  
//     write...
// }

这个特定的代码无关紧要(这只是一些基本示例)……问题通常是关于这种事情的 ……在SQL或“普通”代码上增加更多的负担更好吗?


阅读 188

收藏
2021-04-15

共1个答案

小编典典

这只是一个不好的编程习惯。您应该分离并隔离程序的不同部分,以简化将来的维护(考虑下一个程序员!)

表现

许多解决方案的数据库性能不佳,因此大多数开发人员通常将SQL数据库访问限制为可能的最小事务。理想情况下,应将原始数据转换为可读格式。同样,非格式化数据的内存使用量要小得多,并且尽管内存便宜,但您不应浪费它。每个要缓冲,缓存和传输的额外字节都占用时间,并减少了可用的服务器资源

例如,对于Web应用程序,应使用JSON数据包中的本地JavaScript模板进行格式化。这样可以减少后端SQL数据库和应用程序服务器的工作量,并减少需要通过网络传输的数据,所有这些都可以提高服务器性能。

格式和本地化

许多解决方案对于同一事务有不同的输出需求,例如不同的视图,不同的本地化等。通过将格式嵌入到SQL事务中,您将不得不为每个本地化进行新的事务,这将成为维护的噩梦

同样,格式化的事务不能用于API接口,您将需要另一组没有格式的事务用于API接口

使用c#,您应该使用经过良好测试的模板或字符串处理库,或者至少使用 string.Format() ,不要对字符串使用’+’运算符,这非常慢

分担负载

大多数解决方案为一个数据库有多个客户端,因此客户端的格式化负载是由多个客户端CPU共享的,而不是由单个SQL数据库CPU共享的。

我严重怀疑SQL比c#快,您应该执行一个简单的基准测试并将结果发布在这里:-)

2021-04-15