RE: OT: RE: interview question on schema design
Date: Wed, 12 Dec 2012 19:12:58 -0500
Message-ID: <022501cdd8c6$9c329fa0$d497dee0$_at_rsiz.com>
And this thread segues to the old argument about cache management in general. Anything you plan to keep in an array, you had better be able to spill to a file dynamically, the thought process goes in pre-database 3rd generation design.
What is missing in the disasters I've seen is dynamic resolution of what could be a close call between, for example, caching a slowly or infrequently changing look-up list and the cost of accessing the list freshly. It might be a close call and a guess a design time and the better answer might change over time or between implementations. So you need something quick to fetch to see whether any particular thing cached has changed and a way to tell whether the "everything" refresh costs more than demand fetching. And of course when you do need to refresh, you need to avoid having that be an unacceptable wait state in both time and cost. Can you just refresh (and add or subtract) the bits that changed? Is managing that more or less expensive than demand fetching?
Instrumentation is the answer to this (and many other) quasi-religious wars. But since a lot of folks who don't even know what an afferent leg is also think they are "use case" analysts and user interface "architects" it gets messy. Caching all of the database within an application is probably not ever a good idea. Caching certain bits of a database in an application can work wonders with response time. Figuring out which bits to cache might be partly static architecture (valid US state abbreviations), but much of it is likely to be dynamic.
Having a really solid schema design facilitates building good applications. Bad schema design tends to punish application builders for trying to use the database well. Treating the database as a big garbage can misses that opportunity even when a helpful schema exists. Codd presented us with an upright apple cart filled with nice fruit. Once someone tips over the apple cart it is hard to convince folks to set it back up instead of just grabbing the apples off the ground.
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Powell, Mark
Sent: Wednesday, December 12, 2012 4:35 PM
To: ORACLE-L
Subject: RE: OT: RE: interview question on schema design
DBA's in general dislike java applications for just the reason mentioned: bad database access technique. I am sure there are many well written java applications that access Oracle; it is just that the rule seems to be to code poorly. Also java programmers have a tendency to try to do what should be done inside the database instance within their code. I remember reading a forum thread where the java developers were trying to cache the database data within their application where multiple java application servers would be in use since this would be better than having to go to the database for the data!
The problem is not the java language, but rather a combination of how the java frameworks are designed, inexperienced developers, and poor project management which results in poorly performing applications that kill the database.
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Andrew Kerber
Sent: Wednesday, December 12, 2012 2:10 PM
To: mbrady_at_allegisgroup.com
Cc: oracledbaquestions_at_gmail.com; ORACLE-L
Subject: Re: OT: RE: interview question on schema design
You have expressed exactly why DBA's (in general) are so disdainful of Java
programming. While no doubt there are exceptions, in my experience Java
programmers never look at the code underlying their objects, and blame the
DBA when their application is slow.** In particular, Java seems very prone
to producing huge numbers of round trips from the application server to the
database and back, pulling one row or even one row and one column of data at
a time when some very simple query and schema design could get all of the
data in a single trip.
On Wed, Dec 12, 2012 at 12:33 PM, Brady, Mark
<mbrady_at_allegisgroup.com>wrote:
> That attitude is promulgated by tools like hibernate (
> http://www.hibernate.org/) which increases the developer's ability to
> rapidly develop new applications by abstracting the database [away].
> It abstracts the database away, so you no longer have to /think/ about it.
> Adoption of those frameworks has been slower in .net communities but
> where it is adopted you find the same attitude.
>
> <SNIP>
>
>
>
-- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.' -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Thu Dec 13 2012 - 01:12:58 CET