在运行DELETE查询之前没有执行相应的SELECT查询(特别是在生产数据库上)!

忘记在表之间建立关系。我记得当我刚开始在我现在的雇主工作时，我不得不清理这些东西。

这之前已经说过了，但是:索引，索引，还是索引。我见过许多性能不佳的企业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”更容易使用。

认为他们是dba和数据建模师/设计人员，而他们在这些领域没有任何正式的灌输。 认为他们的项目不需要DBA，因为这些东西都很简单/琐碎。 未能正确区分应该在数据库中完成的工作和应该在应用程序中完成的工作。 未验证备份，或未备份。 在他们的代码中嵌入原始SQL。

I think the biggest mistakes that all developers and DBAs do is believing too much on conventions. What I mean by that is that convention are only guide lines that for most cases will work but not necessarily always. I great example is normalization and foreign keys, I know most people wont like this, but normalization can cause complexity and cause loss of performance as well, so if there is no reason to move a phone number to a phones table, don't do it. On the foreign keys, they are great for most cases, but if you are trying to create something that can work by it self when needed the foreign key will be a problem in the future, and also you loose performance. Anyways, as I sad rules and conventions are there to guide, and they should always be though of but not necessarily implemented, analysis of each case is what should always be done.

二十年来我见过的最常见的错误是:没有提前计划。许多开发人员将创建数据库和表，然后在构建应用程序时不断修改和扩展表。最终的结果往往是一团糟，效率低下，之后很难清理或简化。