[CLUE-Tech] Data models, diagrams, process models documentation

[Sean LeBlanc]

On 08-17 11:35, Jed S. Baer wrote:
> On Sun, 17 Aug 2003 10:10:19 -0600
> David Anselmi <anselmi at americanisp.net> wrote:
> 
> > Sean LeBlanc wrote:
> > [...]
> > > [*] And I really can't grok people who just make database changes
> > > directly via tools like SQL Enterprise Manager, isql, or SQL*Plus or
> > > what have you.
> > 
> > Hear, hear!  At my last job, part of the CM I did was to develop a way 
> > to apply DB changes consistently.  That can be a tricky thing and what I
> > wrote wasn't bulletproof.  But at least I could be confident that the 
> > testers were testing what would go to production.
> > 
> > We did a major rewrite at one point and the data migration scripts (that
> > fit into my CM framework) were very hairy.  When we rolled it out, the 
> > code update took 10 minutes and the data migration 2 hours.  I left at 
> > that point, figuring it was done but our DB guy checked a few things and
> > found a bug.
> > 
> > Instead of rolling it back and fixing/testing the bug he stayed until 
> > 3am hacking on it.  Monday morning all was well.  Tuesday things blew up
> > because of bugs he put in while hacking, two days to fix.  Fortunately 
> > this was a rare occurance.
> 
> ( I'm not sure of where the boundaries of this question are. In Sean's
> original post, it sounded as if he were comparing running a
> human-generated (set of) canned conversion scripts/programs from the
> command line, vs. "push button" execution via a tool. In the context of
> Dave's reply, Sean's openning sentence sounds more like "type each
> individual command seperately", which I've never seen anyone try to do on
> a production box. I have seen single-statement production upgrades done
> via cut&paste into SQL*Plus.)
> 
> Let's not confuse the tool with the outcome, or the process. I've done
> plenty of production turnovers without using any of these high-level
> tools. There are many factors which come into play in determining whether
> the smarter/harder question always turns in favor of the high-level design
> tool. In practice, one of the major factors (particularly in the case of
> behemoths, such as Oracle Designer) is whether people actually take the
> time (or have the time, in some cases) to come up to speed with them.
> Another factor lies in trusting the tool too much, as "It was generated by
> {tool name}, so it must be right". High-level tools, deployed properly,
> can be big time savers, particularly as they mature. Oracle Designer, for
> example, in 1996 didn't support some Oracle server features which were
> critical to a project I was working on. Last I used it (late 2000), it
> still had a different namespace model for database objects name than that
> in use by the Oracle server, but it was still vastly improved for most
> database design tasks.
> 
> Dave's example is perfect for illustrating the failure of process, not the
> tool. High-level tools can make many pieces of the process easier for
> humans, but human failure to adhere to the process, whether it involves
> scripts generated by a programmer, and executed from the command line, or
> generated and executed from within a high-level tool, is the ultimate
> cause of the majority of implementation failures.

Jed, you make some good points. I did not mean to imply that hand-rolled
scripts are a Bad Thing - certainly not. I use them (and check them into
CVS) myself, actually...in combination with ERWin, currently. In some cases,
I find the design tools to indeed be restrictive or problematic. Let me give
some examples:

1. At one job, we kept having what can only be called a "rogue DBA"
inserting the tables used as a repository by Oracle Designer into production
databases! We kept going, WTF are these doing here, and blowing them away
until we discovered who was doing it. It was a guy who worked 24/7 support
and was trying to get certified in Oracle...a real paper tiger in the
making.

2. We use an older version of Erwin where I am at right now. It will not
permit you to create an identity column that is also a type of bigint for
SQL Server 2000, even though SQL Server 2000 does let you do it. So I have
to create a drop script for all FKs (still haven't done this yet, I don't
look forward to it due to screwy FK names) and then recreate the tables in
question, and re-add the FKs.

So obviously these are not without their problems. I also don't buy 
the "Tools Will Save Us" mentality at all, see:
http://www.pragmaticprogrammer.com/cgi-local/pragprog?ToolsWillSaveUs
and the overview page at:
http://www.pragmaticprogrammer.com/cgi-local/pragprog?FailureHowTo
I'm sure you'll recognize some of these!
:) Pragmatic Programmer is a great book, BTW.

But I need to clarify what I have seen developers do (where the function of
a DBA was neither understood/appreciated nor paid for by management). I
*have* seen them do each individual change on dev, then test, then
production...specifically, MS SQL Server, like so many MS tools, seems to
attract and encourage people who demonstrate this sort of behavior - after
all, it's a GUI, anyone can do it, can't they? This is where "ease of use"
really backfires, IMHO. Just because you *can* click and clack in a DB tool
to make changes in production schemas doesn't mean that one *should*. And of
course, there is the whole lack of any way of tracking changes when this is
done...in some places I've worked, this sort of continued behavior would
have resulted in a firing, but at ONE of the places I worked anyway, my
comments about this behavior (I even offered to do what I think is the right
thing on this individual's behalf) resulted in ME being perceived as the Bad
Guy and the Non Team Player, not to mention the intimation that I didn't
"understand" the MS SQL Server Admin tool, LOL.  


I think database modeling tools, like any other tool, properly applied, can
be a useful benefit. Failing that, making changes w/o at least the benefit
of versioned scripts or the like is foolish, IMHO.


Oh yeah, and Dave mentioned CM. I can't tell you how many times I've heard
"huh?" when this was mentioned. So I'd say, "uh, CM means 'configuration
management'". And...you guessed it - the reply to that was, "what's
configuration management?" I'm not kidding, and even the explanation of what
configuration management means made eyes gloss over. No wonder software
projects fail, what, 1/2 of the time? :) 

It's rather interesting to take a look around people in this field actually
getting paid for it and that know so little about it. I remember trying to
describe what Ant is to a co-worker (remember, this is someone who is
supposed to be a developer):

Me: "It's like 'make', but for Java." 
Co-worker: "What's 'make'?"
Me: "Uh...." <thinking, 'Hoo boy'>

People reading this who don't know me very well might think I'm an arrogant
ass, but I'm not, really. I just care about my craft, I guess.

-- 
Sean LeBlanc:seanleblanc at americanisp.net  
http://users.americanisp.net/~seanleblanc/
Get MLAC at: http://sourceforge.net/projects/mlac/
The art of acceptance is the art of making someone who has just done you a 
small favor wish that he might have done you a greater one. 
-Russell Lynes