Subject | Re: A question about database usage load |
---|---|
Author | stevefields24 |
Post date | 2010-12-14T22:18:51Z |
Thanks for your ideas.
I really needed to also know what the load was
on the database connection: Does 31 separate queries
take more "connections" to the database (other than
the connection using TIB_Connection) versus one
query pulling all of the fields. I know that the
displaying of the data is going to take time. Up
to 450 TIB_Edits on one screen are going to be needed.
I have to take the 31 days of data, in one type
of entity, and then do some summing based on the
total for a given day and then a total for the
given "row". They use numerics, dates and strings.
This is a basic time sheet system where the rules
for different days and statuses entails maybe up
to 15 different fields for each day. With live
results before posting.
I really needed to also know what the load was
on the database connection: Does 31 separate queries
take more "connections" to the database (other than
the connection using TIB_Connection) versus one
query pulling all of the fields. I know that the
displaying of the data is going to take time. Up
to 450 TIB_Edits on one screen are going to be needed.
I have to take the 31 days of data, in one type
of entity, and then do some summing based on the
total for a given day and then a total for the
given "row". They use numerics, dates and strings.
This is a basic time sheet system where the rules
for different days and statuses entails maybe up
to 15 different fields for each day. With live
results before posting.
--- In IBObjects@yahoogroups.com, "Ed Dressel" <eddressel@...> wrote:
>
> > As you can imagine the view is slow either way. I am trying to see
> > if having 31 different TIB_Querys is better than having a single
> > huge query record.
>
> I would always (ouch, I don't like that word) go with the 31 specialized queries vs. one large one. And I would probably use TIB_Cursor if speed is essential and move the data into a local storage container (I don't know what your UI implementation is). You could thread the data access which should improve any apparent sluggishness on the UI.
>
> Ed Dressel
>