工业企业订单管理系统升级(1) — Stored Procedures VS DB Queries in code

近期接到任务,需要升级系统的数据库查询订单部分的功能。主要问题是系统查询订单等待时间过长,需要10-30s才能等到查询结果的显示。

分析了code和查询方式,系统需要做大的修改。系统是使用DB Queries in code的方式对数据库进行操作。虽然DB Queries in code对单个查询的时间并不会太慢,但结合这个项目的情况并不适合。使用循环语句对数据库进行多次的读操作,使I/O的cost大幅增加。结合这个项目对相应的技术使用点分几个方面进行分析总结,供今后查询使用。

Stored Procedures VS DB Queries in code

性能

简短的回答是它不会有性能差异。 在以前的SQL版本中,查询引擎会优化存储过程。 当前版本的SQL没有区别。 SQL存储每个执行计划,只要它可以(存储proc或不存储),并且如果可以的话将重用它。

更快的实施

在过去的12年里,我使用过两种方法,毫无疑问,编写存储过程的工作量更大。它也可能导致许多错误,因为它是另一层保护。 因此,许多项目坚持要我使用它们。

安全:

存储过程更安全,这就是原因。 使用存储过程,您只需将一个角色授予SQL日志 – 存储过程的执行权限。  使用特殊查询(如Entity框架),必须直接授予对表的完全读写访问权限。

这种区别曾经对我很重要,在数家公司的十个项目之后,我真的不在乎这个细微差别了。 如果您遭到黑客入侵并且他们可以直接访问您的SQL以及您的用户名和密码,那么此级别的权限差异就不是问题所在。

我的观点是,使用存储过程或DB Queries in code取决于项目所进行的操作,两者的使用要结合项目需求。如果有大量的查询和复杂的逻辑在一个工作中,使用存储过程会更好。

310 total views, 5 views today

Author: Thomson

Thomson's blog

Leave a Reply