Gus*_*uss 13 mysql performance database-design stored-procedures sql-view
我有一个有点复杂的查询与多个(嵌套)子查询,我想让应用程序开发人员使用它.该查询是通用的,并且在数据集的集合上生成具有计算值的视图,并且开发者预期仅需要来自查询返回的一些记录(即,它们将限制某个实体的ID或日期范围的结果或某些这样).
我可以看到实现这个的3种方法:
WHERE根据需要添加自己的子句.WHERE让每个应用程序应用他们需要的过滤器.目前我正在寻找3个额外的子视图,主要是因为一些子查询被多次使用并且作为子视图执行它们可以防止重复 - 否则它可能会更糟;-).明智的表现会更好吗？(假设在所有情况下所有索引都是等效的)如果可能,请选择最坏的情况.
你认为什么在代码维护方面会更好？
我喜欢定义"好"的问题 - 你特别询问了性能和可维护性,这可以让我们回答谈论这种权衡.
从性能的角度来看,我不认为3个选项之间可能存在任何差异,只要查询和数据符合您的预期方案即可.我测试了100倍以上的数据,并可能扩大"where"子句以查看发生了什么,但索引结构等更有可能影响性能,而不是从存储过程执行相同的SQL,通过查看,或从客户端应用程序.
回答这个问题的最好方法是测试它 - 当然,有许多具体细节可能会使我们的溢出者可以给出的一般"我期望的x,y或z"答案无效.如果性能是一个关键问题,请使用数据库填充工具(Redgate make on,我过去使用过DBMonster)并尝试所有3个选项.
从维护点来看,我提供了一个选项4,在我看来,这是迄今为止最好的选项.
选项4:构建一个数据访问库,封装对数据的访问.让库公开方法和参数以优化记录选择.考虑使用规范模式(http://en.wikipedia.org/wiki/Specification_pattern).使用库中最好的查询,不要打扰开发人员的实现细节.
如果这不起作用 - 异构应用程序代码,对简单需求的更改太多 - 我将评估选项如下:
嵌入式SQL:根据重新使用此SQL的次数,这可能没问题.如果只有一部分代码运行SQL,那么它在逻辑上类似于数据访问库.但是,如果相同的代码片段需要在很多地方重新使用,那么它可能是错误的来源 - SQL中的一个小变化需要在几个地方重复.
存储过程:出于维护原因,我通常不喜欢存储过程 - 它们往往因过载而变脆,并创建一种程序化的思维方式.例如,如果您在单独的存储过程中有其他要求使用此SQL计算,则很快就会得到一个过程编程模型,存储过程会相互调用.
观点:这可能是最好的选择.它将特定的数据逻辑放在一个地方,但促进了基于集合的逻辑的使用,因为访问路由是通过SELECT语句,而不是通过执行过程语句.视图很容易合并到其他查询中.
| 归档时间： |
|
| 查看次数： |
5917 次 |
| 最近记录： |