应用程序开发人员常见的数据库开发错误有哪些?
当前回答
在运行DELETE查询之前没有执行相应的SELECT查询(特别是在生产数据库上)!
其他回答
使用Access而不是“真正的”数据库。有很多很棒的小型甚至免费的数据库,比如SQL Express、MySQL和SQLite,它们可以更好地工作和扩展。应用程序通常需要以意想不到的方式进行扩展。
这里有一个视频链接,名为“经典数据库开发错误和克服它们的五种方法”,作者是Scott Walz
忘记在表之间建立关系。我记得当我刚开始在我现在的雇主工作时,我不得不清理这些东西。
相关子查询导致的性能差
大多数情况下,您希望避免相关子查询。如果子查询中存在对外部查询的列的引用,则子查询是相关的。当发生这种情况时,对于返回的每一行至少执行一次子查询,如果在应用包含相关子查询的条件之后应用其他条件,则可以执行更多次。
请原谅这个不自然的示例和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.
我曾多次看到初级开发人员关联子查询,这通常会对性能产生严重影响。但是,当删除一个相关的子查询时,一定要查看之前和之后的解释计划,以确保您没有使性能变差。
过度使用和/或依赖存储过程。
一些应用程序开发人员将存储过程视为中间层/前端代码的直接扩展。这似乎是微软堆栈开发人员的一个共同特征(我是其中之一,但我已经不再这样做了),并产生许多执行复杂业务逻辑和工作流处理的存储过程。这在其他地方做得更好。
存储过程在某些实际技术因素(例如性能和安全性)需要使用时非常有用。例如,保持大型数据集的聚合/过滤“接近数据”。
我最近不得不帮助维护和增强一个大型Delphi桌面应用程序,其中70%的业务逻辑和规则是在1400个SQL Server存储过程中实现的(其余在UI事件处理程序中)。这是一场噩梦,主要是由于难以将有效的单元测试引入TSQL,缺乏封装和糟糕的工具(调试器,编辑器)。
在过去与Java团队一起工作时,我很快发现在那个环境中,情况往往完全相反。一位Java架构师曾经告诉我:“数据库是用于数据的,而不是用于代码的。”
现在,我认为完全不考虑存储过程是错误的,但在它们提供有用好处的情况下,应该谨慎使用(不是默认情况)(参见其他答案)。