几个月前,我开始在这家编程公司工作。他们使用的一种实践是在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或“普通”代码上增加更多的负担更好吗?
这只是一个不好的编程习惯。您应该分离并隔离程序的不同部分,以简化将来的维护(考虑下一个程序员!)
表现
许多解决方案的数据库性能不佳,因此大多数开发人员通常将SQL数据库访问限制为可能的最小事务。理想情况下,应将原始数据转换为可读格式。同样,非格式化数据的内存使用量要小得多,并且尽管内存便宜,但您不应浪费它。每个要缓冲,缓存和传输的额外字节都占用时间,并减少了可用的服务器资源
例如,对于Web应用程序,应使用JSON数据包中的本地JavaScript模板进行格式化。这样可以减少后端SQL数据库和应用程序服务器的工作量,并减少需要通过网络传输的数据,所有这些都可以提高服务器性能。
格式和本地化
许多解决方案对于同一事务有不同的输出需求,例如不同的视图,不同的本地化等。通过将格式嵌入到SQL事务中,您将不得不为每个本地化进行新的事务,这将成为维护的噩梦
同样,格式化的事务不能用于API接口,您将需要另一组没有格式的事务用于API接口
使用c#,您应该使用经过良好测试的模板或字符串处理库,或者至少使用 string.Format() ,不要对字符串使用’+’运算符,这非常慢
分担负载
大多数解决方案为一个数据库有多个客户端,因此客户端的格式化负载是由多个客户端CPU共享的,而不是由单个SQL数据库CPU共享的。
我严重怀疑SQL比c#快,您应该执行一个简单的基准测试并将结果发布在这里:-)