Sql 视图 vs jdbc select-join，在哪里抽象？答案

【问题标题】：Sql views vs jdbc select-join, where to abstract?Sql 视图 vs jdbc select-join，在哪里抽象？
【发布时间】：2012-12-26 20:18:07
【问题描述】：

我有 3 个表格（见下文），Table A 描述一种产品，Table B 保存不同日期的库存信息，Table C 保存每种产品在不同日期的价格。

 Table A
 ------------------
 product_id    product_name
 1             book
 2             pencil
 3             stapler
 ...           ...

 Table B
 ------------------
 product_id    date_id     quantity
 1             2012-12-01  100
 1             2012-12-02  110
 1             2012-12-03  90
 2             2012-12-01  98
 2             2012-12-02  50
 ...           ...         ...

 Table C
 -------------------
 product_id   date_id      price
 1            2012-12-01   10.29
 1            2012-12-02   12.12
 2            2012-12-02   32.98
 3            2012-12-01   10.12

在我的 java 应用程序的许多部分中，我想知道每个产品的美元价值是多少，所以我最终做了以下查询

 select 
      a.product_name,
      b.date_id,
      b.quantity * c.price as total
 from A a
 join B b on a.product_id = b.product_id
 join C c on a.product_id = c.product_id and b.date_id = c.date_id
 where b.date_id = ${date_input}

我今天有个想法，我可以让上面的查询成为一个视图（减去日期条件），然后查询特定日期的视图，这样我的查询看起来像

 select * from view where date_id = ${date_input}

我不确定这种逻辑的适当抽象级别在哪里。它应该在 java 代码中（从 pref 文件中读取），还是编码到数据库中的视图中？

我不想把它作为一个观点的唯一原因是，随着时间的推移，加入会变得昂贵，因为要涵盖的日期越来越多，而且我通常只对过去一个月的感兴趣价值的数据。也许存储过程更好？那是抽象这个逻辑的好地方吗？

【问题讨论】：

标签： sql stored-procedures jdbc abstraction sql-view

【解决方案1】：

如果视图被正确实现，那么在没有视图的情况下查询将相同的情况下，您永远不会看到最差的性能。更多日期不会影响性能，因为您有此视图。

制作视图，在这种情况下它是正确的抽象。

【讨论】：