Re: Data Management and Database Management

"Tony Andrews" <andrewst_at_onetel.com> wrote in message news:1095689071.641139.292620_at_k26g2000oda.googlegroups.com...
> > Also, if you had one of these OTLT designs, wouldn't responsibility
> for the
> > correctness fall on different people, for different types of rows?
>
> Yes - but let's just not GO there ;-)

OK, let's not. But let's just have a canned response ready for the next newbie who wanders in here and suggests that s/he can design a good database without knowing what the underlying entities and attributes are. (as in: a code is a code is a code).

>
> >
> > I never heard the term "bedded in" before. Is that something like
> > "acceptance testing"?
>
> Maybe it is an Anglicism: I mean beyond Acceptance Testing; the system
> is in production, and any teething problems have been resolved. The
> users use it, the DBAs "administer" it, and my input is not required.
>

OK. I guess the nearest thing in Murrican is "put to bed".

> Well I did say "(and assuming no changes are ever required!)".

Yes, you did. But there's a problem there. One of the selling points of a DBMS, some 20 years ago, as opposed to a file system, was precisely that databases hold up better in the face of changing data requirements than flat files do. And one of the selling points for Relational databases, over hierarchical and CODASYL databases is that relational databases would offer more logical data independence that the others.

All this becomes rather moot, if we take the stand that no changes will ever be required. In those cases, there is one less reason to need a DBMS.

Further, one of the most exasperating things to me is the position of many software houses that if they so much as add a new table between releases, they will create a support nightmare. That's requiring more stability in data definitions than I think is appropriate.

> If I am
> employeed by the company as a database designer, then probably
> (hopefully) they will have redeployed me to a new project; if I am a
> consultant, then they won't want to be paying for my full-time
> attendance just in case - more likely I will no longer be there, but
> there will be some kind of support/call-out agreement in case of
> problems. I guess the "system manager" (which may be a business person
> or an IT person) is responsible for making decisions about spending
> money on improvements, after taking advice from senior users and the
> DBAs, and then calling on the designer for estimates etc.
>

Since "consultants" were mentioned fairly recently, I'll offer the opinion that one of the jobs of a consultant is to work himself out of a job. "Congratulations! We no longer have the problems we had when you walked in the door! You're fired!" If you can't bear to hear this message, consulting is going to be very unpleasant for you.

> I would say that making changes to the logical database design is
> beyond the role of the DBA per se, it requires a database designer.
> However, the person who fills the role of DBA may also happen to fill
> the role of database designer. The two skill sets are distinct, but
> have overlaps e.g. in the area of indexes, tuning, etc. In a large
> company, the DBA may support many databases, and cannot be expected to
> fully know the particulars of each one, even if he/she does have the
> relevant skills. In a small company, overlaps of role are far more
> likely (and desirable) than in a large company.

Agreed. I've tended to work in either small companies, or small departements of very agile big companies. YMMV. Received on Mon Sep 20 2004 - 20:52:15 CEST