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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
