Re: need help on a design point

sergey_s_at_my-deja.com wrote:
>It's hard to tell which way is better. There might be hardly any
>difference at all since tables are small. A bunch of smaller
 queries
>means a bunch of smaller transactions which means less Oracle
 time per
>transaction which in turn means less chance for user lockups in
 the
>database. A bigger query may cause someone to wait for resources
>especially if there are many users. Traditionally, DB app
 designers tend
>to minimize network traffic by breaking transactions down into
 smaller
>ones and by moving less data back and forth.

For the most part, I've tended to follow this approach, but I've always focused on 1 dimension, which is the length or # of rows in the query. With these 2 options, the # of rows is always identical. 1 gets more columns back in a single query and the other requires multiple queries.

>Personally, I like to try and use stored procs whenever
 possible instead
>of SQL directly from the app. It allows the DBA greater control
 over DB
>performance.

Unfortunately, our entire application is extremely datacentric  .. (analytical application with lots of number crunching, transformation, and mathematical algorithms and forecast modeling that I barely even comprehend). The developers need a high-level of control over the data. Our code is executed from an application server against oracle (BEA / Web Logic). That's where our semantic layer and "business rules" live.

We're also trying to maintain complete platform independence. We're early in development (considering the entire schedule) and don't want to lock ourselves into any hardware/os or db just yet...but the app must still be built. We're likely to stick with oracle, but I've been told that we might want to take a look at DB2 (but not if I can help it).

Thanks for the feedback.
Gavin

Got questions? Get answers over the phone at Keen.com. Up to 100 minutes free!
http://www.keen.com Received on Wed Aug 02 2000 - 00:00:00 CDT