查询反模式 - 隐式的列

发布日期:2018-02-09    浏览次数:512

一、减少输入

  程序员都喜欢使用通配符,如:

    SELECT * FROM Person

  又或者省略字段名:

  INSERT INTO Person VALUES('10','张飞'...)

二、捷径会让你迷失方向

  对于以上代码,如果你仅仅是在开发过程中用于查看一下数据库信息,又或者你只是写个小程序自己玩玩,这是没有什么问题的。

  但是如果一旦你习惯于这样编写正式生产环境中的代码,那问题就随之而来了。

  1、破坏代码重构

  如果数据库更改了,比如增加了一列:

  ALTER TABLE Person Add Age int

  这下糟糕了,你程序中所有的

  INSERT INTO Person VALUES(...)

  语句都会报错。

  早使用这种隐式模式执行INSERT时,输入必须严格按照定义表时的那些列的顺序,如果列变了,这条语句就会抛出一个错误,甚至有可能就会抛出一个错误,甚至有可能把数据写到错误的列里面去。

  假设原本是使用隐式模式查询:

  SELECT * FROM Person

  但是加入删掉了中间的一个列:

    ALTER TABLE Person DROP COLUMN Age

  那么加入是使用DataTable的方式装载数据库内容,那么row[10]可能就已经不是第十个。在重命名、添加、删除列的时候,程序代码并不能适应查询结果的改变。如果使用了通配符,就无法预测这个查询会返回多少行。

  2、隐藏的开销

  在查询中使用通配符可能会影响性能和扩展性。一次性查询所获取的列越多,客户端程序和数据库之间的网络传输的字节也越多。

  生产环境中的程序可能会有很多并发的查询请求。它们都共享同一个网络带宽。太多客户端同时查询返回上千条记录可能会造成阻塞。

  3、合理使用反模式

  在你只是为了快速地写几个脚本对一个解决方案进行测试,或者写临时SQL查询对当前数据进行查看时,使用通配符是合情合理的。只执行一两次的查询对可维护性没有任何要求。

  当然,输入一张很多列的表的所有列名是很耗时的,对某些人来说,开发效率可能比程序运行效率更加重要。例如,当你开发的是较少用户量的小公司内部访问程序,这时候返回数据所使用的带宽比查询语句本身要多得多。这时候没必要纠结这些问题。

三、解决方案-明确列出列名

  1、预防错误

  每次查询都列出所有你需要用到的列,而不是使用通配符或者隐式列的列表。

  SELECT Id,Name... FROM Person
  
INSERT INTO Person (Id,Name,Age...) VALUES(1,'张飞',22...)

  这样做的好处如下:

  •   如果这张表的某一列的位置被移动过,他不会对返回结果中这一列的位置造成影响。
  •   如果这张表中新加入一列,它是不会出现在查询结果中的。
  •   如果从这张表中删除一列,你的查询会得到一个错误,但是直接就能够找到问题所在,这是符合尽早出错原则的。

  2、减少资源占用

  如果必须关心软件的可扩展性和程序的吞吐量,你应该检查一下网络传输过程中可能造成的浪费。一旦在SQL中禁用通配符,那么就很自然地去除那些不需要的列,提高了带宽和内存的使用效率。

 

本文网址:https://www.wyxxw.cn/blog-detail-17-18-180.html

返回列表

非特殊说明,本文版权归原作者所有,转载请注明出处

提示:本站所有资源仅供学习与参考,请勿用于商业用途。图片来自互联网~如侵犯您的权益,请联系QQ:1067507709.

提示:转载请注明来自:http://www.cnblogs.com/kissdodog/p/3374695.html 。 转载人:momo