0

date当基表日期为或时,许多查询是按周、月或季度进行的timestamp

通常,在group by查询中,是否使用 - 日期函数 -day预先计算了提取的表

注意:与DATE 查找表类似的问题 (1990/01/01:2041/12/31)

例如,在postgresql

create table sale(
  tran_id   serial       primary key,
  tran_dt   date         not null default current_date,
  sale_amt  decimal(8,2) not null,
  ...
);

create table days(
  day       date      primary key,
  week      date      not null,
  month     date      not null,
  quarter   date      non null
);

-- week query 1: group using funcs
select
  date_trunc('week',tran_dt)::date - 1 as week,
  count(1) as sale_ct,
  sum(sale_amt) as sale_amt
from sale
where date_trunc('week',tran_dt)::date - 1 between '2012-1-1' and '2011-12-31'
group by date_trunc('week',tran_dt)::date - 1
order by 1;

-- query 2: group using days
select
  days.week,
  count(1) as sale_ct,
  sum(sale_amt) as sale_amt
from sale
join days on( days.day = sale.tran_dt )
where week between '2011-1-1'::date and '2011-12-31'::date
group by week
order by week;

对我来说,虽然date_trunc()功能看起来更有机,但days表格更易于使用。

这里有什么比口味更重要的吗?

4

3 回答 3

2
-- query 3: group using instant "immediate" calendar table
WITH calender AS (
        SELECT  ser::date AS dd
        , date_trunc('week', ser)::date AS wk
        -- , date_trunc('month', ser)::date AS mon
        -- , date_trunc('quarter', ser)::date AS qq
        FROM generate_series( '2012-1-1' , '2012-12-31', '1 day'::interval) ser
        )
SELECT
  cal.wk
  , count(1) as sale_ct
  , sum(sa.sale_amt) as sale_amt
FROM sale sa
JOIN calender cal ON cal.dd = sa.tran_dt
-- WHERE week between '2012-1-1' and '2011-12-31'
GROUP BY cal.wk
ORDER BY cal.wk
        ;

注意:我修正了 BETWEEN 范围内的一个明显错字。

更新:我使用 Erwin 的递归 CTE 来挤出重复的 date_trunc()。嵌套 CTE 丰富:

WITH calendar AS (
        WITH RECURSIVE montag AS (
        SELECT '2011-01-01'::date  AS dd
        UNION ALL
        SELECT dd + 1 AS dd
        FROM   montag
        WHERE  dd < '2012-1-1'::date
        )
    SELECT mo.dd, date_trunc('week', mo.dd + 1)::date AS wk
    FROM montag mo
    )
SELECT
  cal.wk
  , count(1) as sale_ct
  , sum(sa.sale_amt) as sale_amt
FROM sale sa
JOIN calendar cal ON cal.dd = sa.tran_dt
-- WHERE week between '2012-1-1' and '2011-12-31'
GROUP BY cal.wk
ORDER BY cal.wk
        ;
于 2012-06-02T17:24:15.467 回答
1

是的,这不仅仅是品味问题。查询的性能取决于方法。

作为第一个近似值,函数应该更快。它们不需要连接,在单个表扫描中进行读取。

然而,一个好的优化器可以有效地利用查找表。它会知道目标值的分布。而且,内存中的连接可能会非常快。

作为数据库设计,我认为有一个日历表是非常有用的。某些信息(例如假期)将无法发挥作用。但是,对于大多数临时查询,日期函数都很好。

于 2012-06-02T03:33:13.220 回答
1

1、你的表情:

...在“2012-1-1”和“2011-12-31”之间

不起作用。BasicBETWEEN要求左参数小于或等于右参数。必须是:

... BETWEEN SYMMETRIC '2012-1-1' and '2011-12-31'

或者这只是一个错字,你的意思是:

... BETWEEN '2011-1-1' and '2011-12-31'

我不清楚您的查询应该检索什么。我假设您想要从 2011 年开始的所有周(周一至周日)来获取此答案的其余部分。在现代硬件上,这个表达式在不到一微秒的时间内准确生成(适用于任何年份):

SELECT generate_series(
        date_trunc('week','2010-12-31'::date) + interval '7d'
       ,date_trunc('week','2011-12-31'::date) + interval '6d'
       , '1d')::date

*请注意,“一年中的第一周”的ISO 8601 定义略有不同。

2.您的第二个查询根本不起作用。没有GROUP BY

3.您链接到的问题没有处理 PostgreSQL,它具有出色的日期/时间戳支持。在大多数情况下,它generate_series()可以消除对单独的“天”表的需求——如上所示。您的查询将如下所示:

与此同时, @wildplasser 提供了一个应该放在此处的示例查询。

根据流行* 的需求,递归 CTE 版本 - 实际上距离成为一个严肃的替代方案不远!
* “流行”是指@wildplasser 非常严肃的要求

WITH RECURSIVE days AS (
    SELECT '2011-01-01'::date  AS dd
          ,date_trunc('week', '2011-01-01'::date )::date AS wk

    UNION ALL
    SELECT dd + 1
          ,date_trunc('week', dd + 1)::date AS wk
    FROM   days
    WHERE  dd < '2011-12-31'::date
    )
SELECT d.wk
      ,count(*) AS sale_ct
      ,sum(s.sale_amt) AS sale_amt
FROM days d
JOIN sale s ON s.tran_dt = d.dd
-- WHERE d.wk between '2011-01-01' and '2011-12-31'
GROUP BY 1
ORDER BY 1;

也可以写成(与@wildplasser 的版本相比):

WITH RECURSIVE d AS (
    SELECT '2011-01-01'::date AS dd
    UNION ALL
    SELECT dd + 1 FROM d WHERE dd < '2011-12-31'::date
    ), days AS (
    SELECT dd, date_trunc('week', dd + 1)::date AS wk
    FROM d
    )
SELECT ...

4.如果性能至关重要,请确保不要将函数或计算应用于表的值。这禁止使用索引并且通常非常慢,因为必须处理每一行。这就是为什么你的第一个查询会用大表来吸。如有可能,请改为将计算应用于您过滤的值。

表达式索引是解决此问题的一种方法。如果你有一个像

CREATE INDEX sale_tran_dt_week_idx ON sale (date_trunc('week', tran_dt)::date);

..您的第一个查询可能会再次非常快-为索引维护的写入操作付出了一些代价。

于 2012-06-02T17:37:03.640 回答