sql语句太长有什么坏处吗?
一条select语句竟然长达一百多行,虽然中间通过unionall连接的,不过我想知道sql语句太长有啥大的坏处吗?我是不是应该把它简化比较好?...
一条select语句竟然长达一百多行,虽然中间通过union all连接的,不过我想知道sql语句太长有啥大的坏处吗?我是不是应该把它简化比较好?
展开
7个回答
展开全部
1.不方便维护.
试想一下,一条长达100多行的查询语句如果维护起来时怎样的麻烦,如果有详细的注释还好说,不然要查看100多行的查询语句,更何况是一条...任何一个程序都是最少有百八十条的。
2.运行速度低
如果只是查询一张表不可能会有100多行,即使列再多像这样SLEECT INT_Id, CHR_Username...就这样一个列整一行也到不了100行吧..更合况设计表时要遵守三范式..那么多列的一张表,不能说没有,不过对于做普通项目的数据库,那也太菜了...证明肯定是多表联查的,一般想这种情况就用储蓄过程了,或是建立一个视图,查询视图。
3.结构清晰
现在不仅仅是数据库设计,包括所有的代码都不是将运行速度作为唯一的衡量的标准了,结构的清晰,代码的易懂也是不可缺少的东西,100多行的查询有些繁琐,肯定是要简化的,加上必要的注释,或者将一部分封装成储蓄过程,再调用,显然要比这样好.
试想一下,一条长达100多行的查询语句如果维护起来时怎样的麻烦,如果有详细的注释还好说,不然要查看100多行的查询语句,更何况是一条...任何一个程序都是最少有百八十条的。
2.运行速度低
如果只是查询一张表不可能会有100多行,即使列再多像这样SLEECT INT_Id, CHR_Username...就这样一个列整一行也到不了100行吧..更合况设计表时要遵守三范式..那么多列的一张表,不能说没有,不过对于做普通项目的数据库,那也太菜了...证明肯定是多表联查的,一般想这种情况就用储蓄过程了,或是建立一个视图,查询视图。
3.结构清晰
现在不仅仅是数据库设计,包括所有的代码都不是将运行速度作为唯一的衡量的标准了,结构的清晰,代码的易懂也是不可缺少的东西,100多行的查询有些繁琐,肯定是要简化的,加上必要的注释,或者将一部分封装成储蓄过程,再调用,显然要比这样好.
本回答被提问者采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
sql语句的效率问题跟长度没任何关系,长没关系,但只要注意一下编写格式,那么别人看起来也比较清晰,不会显得太乱。
特别要注意的就是每一行的代码不要太长,多分行是很好的习惯
特别要注意的就是每一行的代码不要太长,多分行是很好的习惯
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
太长会影响数据库的解析速度,但是影响是比较小的,关键是语句的执行效率要高。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
太复杂的语句,一般都做成函数或者存储过程
本回答被网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询