Re: Temporal Units - Mailing list pgsql-general

From Rich Shepard
Subject Re: Temporal Units
Date
Msg-id Pine.LNX.4.64.0704300906520.17352@salmo.appl-ecosys.com
Whole thread Raw
In response to Re: Temporal Units  (Ted Byers <r.ted.byers@rogers.com>)
Responses Re: Temporal Units  (Ted Byers <r.ted.byers@rogers.com>)
List pgsql-general
On Mon, 30 Apr 2007, Ted Byers wrote:

> I am not sure I see why it would be good to do this using SQL, but I do
> know that I have used a number of Perl packages for this sort of thing.

>  I am not arguing with you. I just want to know in what circumstances my
>  schemas can be improved by a calendar table, and how it provides a
>  benefit over my more usual Perl functions.

Ted,

   Having never used such a table -- or having written an application that
had such a heavy use of temporal data rather than scientific data -- I have
no idea in what circumstances your schemas might be improved with a calendar
table.

   I suspect, however, that a SQL table lookup may well be quicker than
running a script (or compiled function) in another language, and the table
is available for use in multiple apps. Isn't it faster or more efficient to
run SELECT queries with table lookups rather then use stored procedures?

   For this web-based application, the UI and communications between client
and server are being written in Ruby (with Rails) while the report
generation is written in Python using ReportLab. If most of the queries can
be done with SQL, I think it will be much easier to maintain, modify, and
expand. Could be wrong, of course.

Rich

--
Richard B. Shepard, Ph.D.               |    The Environmental Permitting
Applied Ecosystem Services, Inc.        |          Accelerator(TM)
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

pgsql-general by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: Server crash on postgresql 8.2.4 with tsearch2
Next
From: Jim Nasby
Date:
Subject: Re: Disadvantages on having too many page slots?