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

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

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

因为“它太神奇了”或“不在我的数据库中”这样的原因，而放弃像Hibernate这样的ORM。 过度依赖像Hibernate这样的ORM，并试图将它硬塞到不合适的地方。

我想补充一点: 偏好“优雅”代码而不是高性能代码。在应用程序开发人员看来，对数据库最有效的代码通常是丑陋的。

Believing that nonsense about premature optimization. Databases must consider performance in the original design and in any subsequent development. Performance is 50% of database design (40% is data integrity and the last 10% is security) in my opinion. Databases which are not built from the bottom up to perform will perform badly once real users and real traffic are placed against the database. Premature optimization doesn't mean no optimization! It doesn't mean you should write code that will almost always perform badly because you find it easier (cursors for example which should never be allowed in a production database unless all else has failed). It means you don't need to look at squeezing out that last little bit of performance until you need to. A lot is known about what will perform better on databases, to ignore this in design and development is short-sighted at best.

相关子查询导致的性能差

大多数情况下，您希望避免相关子查询。如果子查询中存在对外部查询的列的引用，则子查询是相关的。当发生这种情况时，对于返回的每一行至少执行一次子查询，如果在应用包含相关子查询的条件之后应用其他条件，则可以执行更多次。

请原谅这个不自然的示例和Oracle语法，但假设您想要找到自上次商店每天销售额低于10,000美元以来在任何商店中雇用的所有员工。

select e.first_name, e.last_name
from employee e
where e.start_date > 
        (select max(ds.transaction_date)
         from daily_sales ds
         where ds.store_id = e.store_id and
               ds.total < 10000)

本例中的子查询通过store_id与外部查询相关联，并将对系统中的每个员工执行。优化此查询的一种方法是将子查询移动到内联视图。

select e.first_name, e.last_name
from employee e,
     (select ds.store_id,
             max(s.transaction_date) transaction_date
      from daily_sales ds
      where ds.total < 10000
      group by s.store_id) dsx
where e.store_id = dsx.store_id and
      e.start_date > dsx.transaction_date

In this example, the query in the from clause is now an inline-view (again some Oracle specific syntax) and is only executed once. Depending on your data model, this query will probably execute much faster. It would perform better than the first query as the number of employees grew. The first query could actually perform better if there were few employees and many stores (and perhaps many of stores had no employees) and the daily_sales table was indexed on store_id. This is not a likely scenario but shows how a correlated query could possibly perform better than an alternative.

我曾多次看到初级开发人员关联子查询，这通常会对性能产生严重影响。但是，当删除一个相关的子查询时，一定要查看之前和之后的解释计划，以确保您没有使性能变差。

最大的错误是在代码中使用循环更新或插入数据，而基于集合的简单解决方案可以更快、更简单地完成这一任务。

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