开发人员所犯的关键数据库设计和编程错误

Selfish database design and usage. Developers often treat the database as their personal persistent object store without considering the needs of other stakeholders in the data. This also applies to application architects. Poor database design and data integrity makes it hard for third parties working with the data and can substantially increase the system's life cycle costs. Reporting and MIS tends to be a poor cousin in application design and only done as an afterthought. Abusing denormalised data. Overdoing denormalised data and trying to maintain it within the application is a recipe for data integrity issues. Use denormalisation sparingly. Not wanting to add a join to a query is not an excuse for denormalising. Scared of writing SQL. SQL isn't rocket science and is actually quite good at doing its job. O/R mapping layers are quite good at doing the 95% of queries that are simple and fit well into that model. Sometimes SQL is the best way to do the job. Dogmatic 'No Stored Procedures' policies. Regardless of whether you believe stored procedures are evil, this sort of dogmatic attitude has no place on a software project. Not understanding database design. Normalisation is your friend and it's not rocket science. Joining and cardinality are fairly simple concepts - if you're involved in database application development there's really no excuse for not understanding them.

1 -在where子句中的值上不必要地使用函数，导致该索引未被使用。

例子:

where to_char(someDate,'YYYYMMDD') between :fromDate and :toDate

而不是

where someDate >= to_date(:fromDate,'YYYYMMDD') and someDate < to_date(:toDate,'YYYYMMDD')+1

在较小的程度上:不向需要函数索引的值添加函数索引……

2 -没有添加检查约束以确保数据的有效性。查询优化器可以使用约束，它们确实有助于确保您可以信任您的不变量。没有理由不使用它们。

3 -纯粹出于懒惰或时间压力而向表中添加未规范化的列。事情通常不是这样设计的，而是演变成这样的。最终的结果是，当您在未来的演进中受到丢失的数据完整性的困扰时，将会有大量的工作试图清理混乱。

想想看，重新设计一个没有数据的表是非常便宜的。一个有数百万条记录的表，没有完整性……重新设计并不便宜。因此，在创建列或表时执行正确的设计是可以分摊的。

4 -不是关于数据库本身，但确实令人讨厌。不关心SQL的代码质量。SQL是用文本表示的事实并不意味着可以将逻辑隐藏在大量的字符串操作算法中。完全有可能用文本编写SQL，使您的程序员同事能够读懂。

这里有一个视频链接，名为“经典数据库开发错误和克服它们的五种方法”，作者是Scott Walz

在修复生产数据库内部的一些问题之前没有进行备份。 在存储过程中的存储对象(如表、视图)上使用DDL命令。 害怕使用存储的proc或害怕在更有效/更合适的地方使用ORM查询。 忽略数据库分析器的使用，它可以准确地告诉您ORM查询最终转换为什么，从而验证逻辑，甚至在不使用ORM时进行调试。

使用ORM进行批量更新 选择多于需要的数据。同样，这通常在使用ORM时完成 在循环中触发sql。 没有良好的测试数据，只在实时数据上注意到性能下降。

使用Access而不是“真正的”数据库。有很多很棒的小型甚至免费的数据库，比如SQL Express、MySQL和SQLite，它们可以更好地工作和扩展。应用程序通常需要以意想不到的方式进行扩展。