Subject | Re: [ib-support] Call Interbase Stored Procedure from PHP |
---|---|
Author | Helen Borrie |
Post date | 2002-03-09T00:32:27Z |
At 04:56 PM 08-03-02 -0500, Xavier wrote:
That is what stored procedures and UDFs are for - to do this kind of number
crunching right on the server and deliver *chunks of processed data* to the
client, according to specifications input by the user. One designs
client/server apps to collect instructions from users and return user
selections of processed data, not to crunch numbers.
With the volumes of data you are talking about, probably very little data
entry would be done through a user interface. One would have various
console apps collecting raw process output data from instrument interfaces,
communicating with a server-based client app to validate, log (where
required) and store. Any datasets surfaced in the server application would
be very small, non-update validation parameters and such.
Similarly, I would expect that your would have a server-based reporting
layer to manage snapshot datasets for reports.
The only data that should cross the wire are input (of course) and those
outputs which human users will actually use.
Helen
All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________
>Well, this database will have data coming from DNA microarray experiments. IXavier,
>don't know if you have heard something about them. I just will tell you that
>one single experiment generates 10000 rows of raw data. Imagine I want to get
>the raw data of (just) 10 experiments to make some kind of statistical
>analysis with them, this generates the 100000 rows I explained befored. The
>field of Computational Biology is one of the most challenging ones, and even
>more if we talk about bilogical databases, which must be able to store
>enormous amount of data.... and now I begin to face this challenge!!
That is what stored procedures and UDFs are for - to do this kind of number
crunching right on the server and deliver *chunks of processed data* to the
client, according to specifications input by the user. One designs
client/server apps to collect instructions from users and return user
selections of processed data, not to crunch numbers.
With the volumes of data you are talking about, probably very little data
entry would be done through a user interface. One would have various
console apps collecting raw process output data from instrument interfaces,
communicating with a server-based client app to validate, log (where
required) and store. Any datasets surfaced in the server application would
be very small, non-update validation parameters and such.
Similarly, I would expect that your would have a server-based reporting
layer to manage snapshot datasets for reports.
The only data that should cross the wire are input (of course) and those
outputs which human users will actually use.
Helen
All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________