使用Excel存储(大量)数据。

我曾见过一些公司拥有数千行并使用多个工作表(由于以前版本的Excel的行数限制为65535)。

Excel非常适合用于报告、数据演示和其他任务，但不应被视为数据库。

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

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

3)没有使用BIND变量

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

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

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

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

不使用参数化查询。它们在停止SQL注入时非常方便。

这是一个不消毒输入数据的具体例子，在另一个回答中提到过。

许多开发人员倾向于对数据库执行多个查询(通常查询一个或两个表)，提取结果并在java/c/c++中执行简单的操作——所有这些都可以用一条SQL语句完成。

许多开发人员通常没有意识到，在开发环境中，数据库和应用程序服务器在他们的笔记本电脑上——但在生产环境中，数据库和应用程序服务器将在不同的机器上。因此，对于每个查询，在应用程序服务器和数据库服务器之间传递的数据都有额外的n/w开销。我惊奇地发现，为了向用户呈现一个页面，应用程序服务器对数据库服务器进行了大量的数据库调用!

不了解数据库并发模型以及它如何影响开发。事后添加索引和调整查询很容易。然而，应用程序的设计没有适当考虑热点，资源争用 和正确的操作(假设您刚刚阅读的内容仍然有效!)可能需要在数据库和应用层中进行重大更改，以便稍后纠正。

对于基于sql的数据库:

Not taking advantage of CLUSTERED INDEXES or choosing the wrong column(s) to CLUSTER. Not using a SERIAL (autonumber) datatype as a PRIMARY KEY to join to a FOREIGN KEY (INT) in a parent/child table relationship. Not UPDATING STATISTICS on a table when many records have been INSERTED or DELETED. Not reorganizing (i.e. unloading, droping, re-creating, loading and re-indexing) tables when many rows have been inserted or deleted (some engines physically keep deleted rows in a table with a delete flag.) Not taking advantage of FRAGMENT ON EXPRESSION (if supported) on large tables which have high transaction rates. Choosing the wrong datatype for a column! Not choosing a proper column name. Not adding new columns at the end of the table. Not creating proper indexes to support frequently used queries. creating indexes on columns with few possible values and creating unnecessary indexes. ...more to be added.