1)不了解如何正确地在Java和数据库之间进行交互。

2)过度解析，不恰当或没有重用SQL

3)没有使用BIND变量

4)在数据库中使用SQL集逻辑时，用Java实现过程逻辑(更好)。

5)在投入生产前没有进行任何合理的性能或可伸缩性测试

6)使用水晶报表，在报表中没有正确设置模式名

7)由于不了解执行计划，使用笛卡尔式产品实现SQL(你甚至看了EXPLAIN计划吗?)

根据我的经验: 不与有经验的dba沟通。

第一个问题?他们只在玩具数据库上测试。因此，他们不知道当数据库变大时，他们的SQL将会爬行，并且稍后必须有人来修复它(您可以听到的声音是我咬牙切齿的声音)。

这之前已经说过了，但是:索引，索引，还是索引。我见过许多性能不佳的企业web应用程序，它们通过简单地进行一些分析(查看哪些表被频繁访问)，然后在这些表上添加索引来解决问题。这甚至不需要太多的SQL编写知识，而且回报是巨大的。

Avoid data duplication like the plague. Some people advocate that a little duplication won't hurt, and will improve performance. Hey, I'm not saying that you have to torture your schema into Third Normal Form, until it's so abstract that not even the DBA's know what's going on. Just understand that whenever you duplicate a set of names, or zipcodes, or shipping codes, the copies WILL fall out of synch with each other eventually. It WILL happen. And then you'll be kicking yourself as you run the weekly maintenance script.

最后:使用清晰、一致、直观的命名约定。与一段编写良好的代码应该是可读的一样，一个好的SQL模式或查询应该是可读的，并且实际上告诉您它在做什么，甚至没有注释。六个月后，当你不得不对桌子进行维护时，你会感谢自己的。“选择account_number, billing_date FROM national_accounts”比“选择ACCNTNBR, BILLDAT FROM NTNLACCTS”更容易使用。

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

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.

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