Sql视图vs jdbc select-join,在哪里抽象?

时间:2012-12-26 20:18:08

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

我有3个表格(见下文),Table A描述了一个产品,Table B保存了不同日期的广告资源信息,Table C保存了不同日期的每个产品的价格。< / p>

 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文件中读取),还是编码到数据库中的视图中?

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

1 个答案:

答案 0 :(得分:1)

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

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