Re: Query design assistance - getting daily totals

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: Query design assistance - getting daily totals
Дата
Msg-id dcc563d10712120748t2ea3629fl9e9a578e00330f45@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Query design assistance - getting daily totals  (Paul Lambert <paul.lambert@reynolds.com.au>)
Список pgsql-sql
On Dec 12, 2007 12:39 AM, Paul Lambert <paul.lambert@reynolds.com.au> wrote:
> A. Kretschmer wrote:
> > am  Wed, dem 12.12.2007, um 10:34:35 +0900 mailte Paul Lambert folgendes:
> >> year_id integer
> >> month_id integer
> >> working_day integer
> >
> > Why this broken data types? We have date and timestamp[tz].
> >
> >
>
> It's a financial application which needs to work using a concept of
> 'financial periods' which may not necessarily correspond to calendar
> months and it's much easier to manage in this way than it is to merge it
> all together using a date field. Eg, 1st January may actually be the
> 15th 'working day' of the 9th 'financial period' - however looking at
> just a date of jan-1 there is no way of knowing this and it's the
> periods that matter more so than the actual date.

I'm not sure that really justifies your method though.  Not saying
"you're doing it wrong" so much as I'm not sure the way you're doing
it makes it any easier to keep track of certain periods.  Any method
you would use to pick rows with the disjointed dates could be applied
to date and / or timestamp types as easily, and with some functional
indexes on the date / timestamp columns you could easily select
periods quickly as well.

Just saying.


В списке pgsql-sql по дате отправления:

Предыдущее
От: Gerry Reno
Дата:
Сообщение: Re: join on three tables is slow
Следующее
От: "Gary Chambers"
Дата:
Сообщение: Query Assistance