简单的时间观点？

如何编写查询来计算postgres中每个ID的结束日期？我可以用Python在内存中执行此操作，但我宁愿保持简单并创建一个视图。简单的时间观点？

我的表追加了system_1_id和system_2_id的任何新组合以及数据来自的文件的日期（我正在读取每周发送几次的快照映射文件）。它看起来像这样：

system_1_id system_2_id start_date is_current 
123456   05236  2016-06-01 False 
123456   98899  2017-01-03 False 
123456   05236  2017-04-15 True

要：

system_1_id system_2_id start_date end_date 
123456   05236  2016-06-01 2017-01-02 
123456   98899  2017-01-03 2017-04-14 
123456   05236  2017-04-15

注意，只能有一次分配给system_1_id一个system_2_id，但它们可以被回收，甚至重新分配在后面日期。
结束日期简直比下一行日期为同一ID

我的目标是最终能够加入其他表中的数据和拉每个日期的准确IDS少仅1天：

where t1.system_2_id = t2.system_2_id and t1.report_date >= t2.start_date and t1.report_date <= t2.end_date

一个简单态表，而无需担心触发器或规则或使用扩展。

来源

2017-08-11 trench

的lead()窗口功能为你做这个，你的榜样数据：

select 
    system_1_id, 
    system_2_id, 
    start_date, 
    cast(lead(start_date, 1, Null) over(partition by system_1_id order by start_date) - interval '1 day' as date) as end_date 
from 
    the_table;

来源

2017-08-12 14:15:41

这似乎是完美的。它会不会随着时间的推移捕获多个变化？我想确保它适用于我最初分配给system_1_id的特定边缘案例，比如Fred，然后将其分配给George，然后将其再次分配给同一个Fred。这些更改中的每一个都应具有开始日期和结束日期，以便我可以准确地将其他数据返回到表格并获取正确的system_2_id。 – trench

它将处理system_2_id被重新分配的情况，如你的例子，但我不认为它会处理system_1_id被重新分配的情况。为此，您必须有一些额外的标准来确定system_1_id的哪些实例应该组合在一起。 –

是的，system_2_id是我担心的那个。我运行了一年以上的文件，看起来效果很好。我需要阅读更多关于lead（）和分区的东西，所以我明白它是如何工作的，但非常感谢。我在熊猫（python）中实现了一些东西，然后我插入行并添加新的东西......这是一团糟。我认为这是一个更清洁，更少的错误空间。 – trench

简单的时间观点？

回答

相关问题