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.
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
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.
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
In response to
pgsql-general by date
|Next:||From: Craig A. James||Date: 2007-04-30 16:18:51|
|Subject: Re: Feature Request --- was: PostgreSQL Performance Tuning|
|Previous:||From: Oleg Bartunov||Date: 2007-04-30 16:13:06|
|Subject: Re: Server crash on postgresql 8.2.4 with tsearch2|