RE: Why an organization would need an enterprise DB team

  • From: Robert Freeman <robertgfreeman@xxxxxxxxx>
  • To: "Kerber, Andrew W." <Andrew.Kerber@xxxxxxx>, jkstill@xxxxxxxxx
  • Date: Mon, 19 Mar 2007 12:57:25 -0700 (PDT)

With respect, it *is* that kind of thinking that will
keep things status quo and lead to continual project
failures. Developers have the time (or will make it)
and the interest, if they are good developers. I have
the proof right here where I work.

Read "From Good to Great" with regards to the kind of
people to surround yourself with. Good isn't good
enough to really succeed. If your developers do not
have the desire to learn about the database they are
working with, then they probably need to be developing
somewhere else, or doing something else. Many of the
developers I've worked with have that burning desire
to learn and understand the database is an important
component.

As long as you have unmotivated developers on a
project then projects will always be behind schedule,
off budget and fail. With developers who don't want to
spend the time to understand the tools they are
working with, is it any wonder that these things
happen? It dosen't mean they need to be experts, mind
you, but understanding how to write basic DDL, and
queries that perform, is an important part of what
they do. It's something that happens over time. It
takes deliberate effort on the part of everyone.... 

Same thing with DBA's. For example, when I came here I
didn't know a thing about Hibernate, our persistance
layer. I took a couple of days, installed it, played
with the demos and read a couple of books and numbers
of web sites over a couple of weeks (ok... I
skimmed!). Am I a Hibernate expert? Nope. Do I
understand something about Hibernate and how it works
as a persistence layer? You bet. Do I understand the
developers when they talk to me about Hibernate? Yes.

The bottom line is that until we stop this stove pipe
mentality, we will keep making the same mistakes and
having the same problems. 


Cheers!

RF


--- "Kerber, Andrew W." <Andrew.Kerber@xxxxxxx> wrote:

> I think it would be more accurate to say that
> developers don't really
> have time to figure out how the database really
> works, and dba's don't
> really have time to figure out how the developers
> are programming.
> 
>  
> 
> My thoughts on the agile programming technique that
> someone mentioned
> here is it adds more in confusion than its worth in
> speed.
> 
>  
> 
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of
> Jared Still
> Sent: Monday, March 19, 2007 12:22 PM
> To: robertgfreeman@xxxxxxxxx
> Cc: oracle-l@xxxxxxxxxxxxx
> Subject: Re: Why an organization would need an
> enterprise DB team
> 
>  
> 
> On 3/19/07, Jared Still <jkstill@xxxxxxxxx> wrote:
> 
>        
> 
>       "Why is data modeling needed?  The main reason is
> that systems
> developers are so bad at building files and
> databases".  George Tilmann
> - A Practical Guide to Logical Data Modeling -
> McGraw Hill 1993 
>       
>       That hasn't changed much in 14 years.
>       
>       Much of this ignorance of how an efficient (as in
> scalable)
> database should work is due to the Microsoft 'black
> box' programming
> methods.  Developers don't know many of the building
> blocks they use
> really work,  and are not encourage to find out how
> things work. 
>       
>       You don't need to know all the internals, but you
> do need some
> idea of how things work to use them efficiently.
> 
>  
> 
> 
> Just to be clear on this, I think it would be great
> if all developers
> had an interest in how the database work, and the
> hows and whys of
> database design. 
> 
> The problem just seems to be that they are often
> taught that it is not
> necessary.
> 
> -- 
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
> 
> 
>
------------------------------------------------------------------------------
> NOTICE:  This electronic mail message and any
> attached files are confidential.  The information is
> exclusively for the use of the individual or entity
> intended as the recipient.  If you are not the
> intended recipient, any use, copying, printing,
> reviewing, retention, disclosure, distribution or
> forwarding of the message or any attached file is
> not authorized and is strictly prohibited.  If you
> have received this electronic mail message in error,
> please advise the sender by reply electronic mail
> immediately and permanently delete the original
> transmission, any attachments and any copies of this
> message from your computer system. Thank you.
> 
>
==============================================================================
> 


Robert G. Freeman
Author:
Portable DBA: Oracle  (Oracle Press)
Oracle Database 10g New Features (Oracle Press)
Oracle9i RMAN Backup and Recovery (Oracle Press)
Oracle9i New Features (Oracle Press)
Oracle Replication (Rampant Tech Press)
Mastering Oracle8i (Sybex)
Oracle8 to 8i Upgrade Exam Cram (Coriolis <RIP>)
Oracle 7.3 to 8 Upgrade Exam Cram (Coriolis <RIP>)
--
//www.freelists.org/webpage/oracle-l


Other related posts: