避免数据库开发者常犯的十大错误

admin

你可能会兴奋地紧跟时尚创建一个AJAX Web界面，或者使用最近迷人的Windows用户界面，但是透过这些各种各样的外观界面，你可能依然需要从后台数据库中提取或存取所需要的数据——这一点就如同十多年以前人们对数据库的操作是一样的。

　　然而，令人吃惊的是，现在还有很多开发者依然在不断地重复着很多年以前就存在的数据库使用和开发上的错误。或许是有太多的开发者只是来学习如何使用一个数据库，而不是真正的去研究它。以下是笔者作为一个开发者，个人在平时的开发工作中所精选出的数据库开发者常犯的十大错误，以飨读者和同行。

　　1、选择了错误的数据库

　　不是所有的数据库都可以用来完成你的任务，这意味着当你在使用数据库来做任何开发工作和其他事情前，你必须选择合适的数据库。例如，我们经常看到一些Access数据库没有能力处理的大容量数据集，对于SQL Server来说却像玩小孩子的游戏一样轻松地完成处理。但是，对于只需要处理几百行数据的需求，有的人却花钱来购买SQL Server。这些都是错误的做法。

　　广泛地来说，在当今市场中的数据库可以分为三个层次：桌面和嵌入数据库——适合于处理小型任务;一些大型数据库产品的“Express”版也是不错的，可以处理数G条数据;而真正的企业级数据库，像SQL Server、Oracle和DB2的数据处理能力是非常惊人的，你可以毫不犹豫地把数据抛给它们。

　　因此，在你选择数据库前，你需要对于你的数据进行一次客观真实的分析，从而选择适合你的开发工作和实际需求的数据库产品。

　　2、选择了太多的数据库

　　诸如ODBC、JDBC和OLEDB等应用程序编程接口的出现，大大促进和提升了数据库独立性，也就是说，开发人员可以这样来编写你的应用程序：你可以让你的应用程序支持使用任何数据库来进行数据存储。

　　然而，这种情况是要付出一些代价的，我曾经看到有的开发团队为了追求应用程序的数据库“无关性”，专门编写了应用程序将所有的SQL语句转换成一些底层的语言，以便让所有的数据库都能理解并执行，但是，这样做的同时也丧失了现有数据库的一些高级功能。

　　那么为什么这么做呢?可能是出于这样的考虑：某些客户在将来的使用中可能想切换到Oracle或DB2或FoxPro，或其他的什么数据库，采用上面的这种做法或许是现在先准备好了，“未雨绸缪”。

　　对于此，另一种相反的做法是：当你开始开发一个新产品的时候，选择一个存储引擎并开始在此基础上编写你的应用程序。如果你的产品足够好，人们会安装你指定的数据库，因此你不用浪费时间和精力来支持一种“假想”的用户需求。

　　3、了解你的数据

　　在我们使用数据库的过程中会碰到很多需要考虑的问题，例如有些客户编号可能并不是我们通常认为的七位，而是六位;而有一些公司和企业出于保护个人隐私的考虑，可能不一定非要求员工输入他们的身份证号码或者银行帐号，因此这中数据类型在数据库搭建和开发中必须设置成可以为空(NULL)。

　　也就是说，数据库开发和设计不能脱离实际情况进行，不能远离实际业务规则。对数据库开发者来说，必须要完全了解用户真正输入数据的需求是什么，并根据这些数据来合理地设计数据字段的大小、类型以及什么规则，等等。否则，等待你的将是一次又一次地返回头来进行修改工作。因此，你要学会在开始的时候就对你需要处理的数据具有非常全面、深入的了解，要尽量考虑到各种意外的情况。

　　4、数据库不像Excel一样人人会用

　　现在有一种认识上的误区，尤其是在一些小单位的管理者眼中，他们总认为任何开发者都知道如何去合理地搭建一个数据库。

　　很明显，这种误解让我很困惑。既然你不会假定任何开发者都知道如何用C#编程或创建一个Web服务，那么为什么要假定每个开发者都是数据库专家呢?

　　这种假设所带来的最后结果是，太多的数据库被一些甚至从来没有听说过术语规范化(term normalization)的人所设计。很多数据库的功能根本没有被合理地运用，如果你是这样一个开发者的话，那么在你设计数据库之前，你需要加强这方面的培训和学习了。高效的数据库设计是你必须了解和掌握的技巧，而不要奢望可以通过失败的教训来了解到这一点。

         5、第三范式并不是至高无上

　　另一方面，开发人员对数据库的一知半解可能是一件比较危险的事情。我看到过很多数据库被设计得过于死板，这些数据库的设计者坚持把所有东西都放在查询表中。

　　是的，数据库开发者需要知道规范化的规则，但是你也需要知道什么时候要停止去用规范化，什么时候逆规范化反而可能会带来更好的效果。

　　6、隐藏应用逻辑的“黑匣子”

　　存储过程和触发器是两个非常伟大的功能。当你有多个客户访问一个数据库的时候，它们可以帮助你确保对数据的一致性处理。

　　不过，它们也可能会变成一个隐藏应用逻辑的“黑匣子”，让Web和瘦客户端开发者无法查看和调试这些逻辑。在大多数情况下，数据库代码不能像其他应用程序代码一样被进行代码测试和代码调试。

　　因此，当你要将代码放到数据库中的时候，花点时间来问一下自己：这些代码是否真的适合放在数据库中?

　　7、备份!备份!备份!

　　你的数据库需要备份吗?当然需要!

　　我们为什么要把数据存在数据库中的原因之一就是想长久地保存它们。然而，我却经常碰到这样的情况，有的开发人员却因为这样或那样的原因——例如硬件故障、黑客或数据库错误——因为没有备份而导致珍贵的数据永远丢失。因此在你开始开发之前，就应该制定一个数据备份计划，包括备份的频率、备份的类型，以及离线备份的频率等等，而不应该在数据丢失后才想起备份的重要。

　　我不希望“亡羊补牢”的故事发生在各位数据库程序员的身上。

　　8、你需要版本控制

　　说到备份，你需要担心的不仅仅是数据的变化，还有数据库的修改。你需要跟踪并记录下这些数据库版本的变化，以便在任何需要的时候重新创建这个数据库。如果你想真正专业化的开发软件，你需要在你的数据库设计中增加版本控制。

　　举个例子来说，如果你想调试某个软件版本中的客户漏洞，但是你无法恢复到该软件版本所对应的数据库版本的话，调试可能不会正常进行。因此数据库开发者必须要做好版本控制，否则可能因此带来很多以后的麻烦。

　　9、使用数据库自带的工具

　　现代数据库中已经不仅仅是一些让你存放数据的工具。它们还具有很多潜在的工具来使得管理数据库更容易。

　　举个例子来说，SQL Server中有工具可以检测SQL语句中潜在的攻击，甚至包括了一个向导，来告诉你该使用什么样的索引才能使你的查询上更高效，甚至可以模拟在真实服务器上的实际负载。

　　通过这些工具，我们的确在有的时候加速了数据库运行的速度，降低了CPU的利用率，但是实际情况是，很多人只有在一些专家顾问告诉他们后才知道在数据库中存在这样的工具。如果你不知道在你的数据库中存在什么样的工具，以及这些工具能帮你做什么，那么你花的钱就没有得到应有的回报。

　　10、不要因为你有一个锤子就认为什么都是钉子

　　现在有一种潮流，一些开发人员把应用程序用到的所有数据都存储在数据库中。我曾经看到有的应用程序试图创建一个完全数据元驱动(metadata-driven)的用户界面，它把元数据和用户偏好的数据都存放在相同的数据库中。显然这会让开发人员的生活变得复杂和降低性能。

　　某些数据可能的确适合存放在本地文件中，而不是存放在网络的客户—服务器数据库中。当你存储数据的时候，你需要分析一下你的数据适合存放在什么地方，是数据库?注册表?文本文件?还是XML文件?然后为其选择最适合的存储类型。“不要因为你有一个锤子就认为什么都是钉子”，不要因为有一个数据库，就把所有东西都扔到数据库中——现在还存在一种对XML文件的过度滥用，也是同样的情况。