Re: Which Database (MySQL, Oracle, mSQL, Protgress etc.)

In article <m2hg5nuboa.fsf_at_lucifer.guardian.no>, Bjorn Borud <borud_at_guardian.no> wrote:

>it is not an absolute that the DBA is NOT primarily responsible for
>application development, of course, but I don't see why you should
>view this as a sad statement.
>
>I cannot possibly imagine how your day looks or what you do for a
>living so from your point of view it might be natural for the DBA to
>develop applications.

I do view it as a sad statement, and yes if you know more about what my day looks like then perhaps you will understand. I, and other similar developers around me, amd responsible for the entire application development from top to bottom. That includeds what other sites consider DBA work. Since our environment dictates at most an average of 15 minutes of DBA type work a day, there's no reason we cannot accomplish these tasks in addition to our regular duties.

I agree about the team concept as you desrcribed. It's just my experience that the DBA and the developer are the same person. It's better that way because the database design and implmentations gets done by the same person that designs the application. The more that is done as an integrated whole produces better systems, IMO.

>the DBA is typically a service role. this is the person that knows
>how the database works and who makes sure that a) the database is in
>good shape, b) the developers don't do stupid things, c) makes sure
>that tables, indexes, clusers etc are optimized.

This is where our experiences differ, and why I see the above statement as sad. A developer should know about the indexes. He's the guy who's got to use them, he knows about how the application is going to access data. Those two functions are best combined. (and then the developers stop doing stupid things)

>the size of the company doesn't really tell us anything about the size
>or nature of the database you maintain for them.

True. As I said Fortune 50 companies, 100GB+ databases not 100MB+, hundres if not thousands of users. Mission critical applications. Minolta is a good example as one of their divisions runs entirely off of Progress (MBS) and another runs a mainframe system. (OPD) MBS has an entire development staff (the ever changing, flexible systems) of 11 people + two part time consultants. Other staff in the field handle system support on a regional basis. (but no development work) This staff does entire module development, top to bottom, including documentation and training, (2 people) and the maintenance of the development equipment (1 person). There are two people who are strictly managers.

Meanwhile the mainframe shop has over 100 employees. Their application is simple order entry, shipping and receiving. (where MBS does all of that, plus Service Contract Maintenance, and actual Service Call Tracking)

>I've worked on projects where perhaps 10-20% of the people were DBAs,
>and we needed every one of them. you really, really want someone
>around who can say "that won't perform well -- do it like this" or who
>can deal with the changing demands on a database during a project.
>
>let's be honest: most application developers are utterly clueless
>about databases and letting them loose on a large database in (for
>instance) a bank is utter madness.
>

I again agree with your statement for many large organizations. And that again is sad that a developer does not know how to write his own code that makes proper use of the database. Perhaps having separate job functions between developer and DBA promotes this. Without a DBA to fall back on, developers are forced to understand the indexex and make code that performs well. Sure there are inexperienced people that are not going to do a good job at this. But when you routinely are expected to be responsible for performance tuning, you must learn how or you're not going very far. And since Progress doesn't require that full time DBA, a developer can be expected to have that responsibility. Every shop I consult to, the guy who writes the report or screen is the one who knows "they won't perform well - I better do it like this". They end up being better developers that way since they have a consolidated view of the database and application from both sides of the house.

>there's a difference between maintaining systems that are in a
>evolutionary stable state and managing a development environment or an
>environment that is in constant flux. not having adequate human
>resources in a database environment that is in flux is a recipe for
>disaster.

I was talking about clients with on going in house development. They do have adequate resources, and they don't have disasters. It's just a more productive environment that allows for less staff.

Geoff Crawford                       Phone:      (973) 627 - 0307
Innovative Client Servers            FAX:        (973) 627 - 0634
24 Dogwood Drive                     Email:    geoff_at_innov8cs.com
Denville NJ 07834                    Web: http://www.innov8cs.com