RE: OT: RE: interview question on schema design
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <mark.powell2@xxxxxx>, "'ORACLE-L'" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 12 Dec 2012 19:12:58 -0500
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Andrew Kerber
Sent: Wednesday, December 12, 2012 2:10 PM
To: mbrady@xxxxxxxxxxxxxxxx
Cc: oracledbaquestions@xxxxxxxxx; 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@xxxxxxxxxxxxxxxx>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.'
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
