Re: Temporal Units - Mailing list pgsql-general
| From | Ted Byers |
|---|---|
| Subject | Re: Temporal Units |
| Date | |
| Msg-id | 272678.10166.qm@web88301.mail.re4.yahoo.com Whole thread Raw |
| In response to | Re: Temporal Units (Rich Shepard <rshepard@appl-ecosys.com>) |
| List | pgsql-general |
Rich,
I would think that as an ecologist, you would have a better sense than most here of the kinds of things I'd be doing. After all, I am a mathematical ecologist by training and the majority of applications I have developed have been either for agricultural consultants or environmental consultants. As a very simplistic example of where I find the kind of auditing I mentioned being priceless, consider a decision support tool for which the input data involves concentrations of various contaminants in water leaving some facility (at this point we don't care what the facility is). While I would prefer that the input come from a laboratory information system, and fully automated, imagine that the data is recorded and input by some lab tech. as each test is completed. On April 1, 2006, there is a typo leading the decision maker to believe that the concentration of contaminant X is 1 mg/l, and that this is an error and the true value is 1 g/l. The decision maker may decide to do nothing because 1 mg/l is considered safe. But doing nothing, some bad environmental effect occurs, and it is discovered days after the decision was made that the data entered is in error. Who is to blame? Where does responsibility lay and what corrective action is needed to ensure the problem does not recurr? When there is an issue of accountability and responsibility involved in environmental issues, every scientific measurement taken becomes a candidate for the kind of multitemporal data I routinely use.
Now, for lookup tables vs functions, there is always a tradeoff even within a given programming language (I am most familiar with FORTRAN, C++ and Java). The tradeoff is between memory use (including how that may affect performance if the table is large relative to available memory) and the speed or size of the function. In the case of the date and time functions I typically use in my perl scripts, they are so short, I doubt the performance impact is significant or easily measurable.
On a side note, how do you like Ruby and Python? How would you compare them to the other options (such as C++, Java, Perl, &c.)?
Cheers,
Ted
Rich Shepard <rshepard@appl-ecosys.com> wrote:
Rich Shepard <rshepard@appl-ecosys.com> wrote:
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)
Voice: 503-667-4517 Fax: 503-667-8863
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
pgsql-general by date: