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

In article <m23eh6leoy.fsf_at_lucifer.guardian.no>, Bjorn Borud <borud_at_guardian.no> wrote:
>I think it is more fruitful for the application developer to describe
>the way he would like to interact with the database and then leave
>optimalization to the DBA.

If you see the DBA's job as taking 5-6 hours a day, then what other choice do you have? If you see the DBA as a 15 minute a day job (and the 15 mins. are best left to a system admin) then why would you want to split apart something the developer can handle on his own? Why would you want to increase the risk of a developer and a DBA miscommunicating and getting it wrong? Why would you risk having developers that do not have good database design as part of their job descriptions?

>I'm not sure we agree on what the DBA actually does. in my opinion
>the DBA does system administration tasks like ensuring that the server
>runs and that backups are okay, but the DBA is also responsible for
>knowing the structures inside the databases, knowing how to optimize
>the databases and working with the developers in a supportive role.

We do agree. But my environment is far different from yours. The structure inside the database is no mystery that you will need a year of training to understand. That leaves system admin chores, which for me are a couple of minutes a day. That becomes no burden for a system admin.

>| I, and other similar developers around me, amd responsible for the
>| entire application development from top to bottom.
>
>the problem is that not all projects are small enough for one person
>to manage or even understand fully.

I never said this was exclusive to projects that one person could manage. And I certainly don't expect one person to fully understand a whole system. I did mention "other developers around me", so yes team development is at work here. Now granted, again, my day looks different than yours. A team would be subdivided into smaller modules of the system that they would be working in. (divided vertically, not horizontally) Modules small enough so that a person or two could understand the whole module. And in my environment a single person can easily code a whole module in a couple of months, no matter how complicated, or how many man-years it might take in other environments.

>small projects that can be managed by one person permits a wider range
>of "methods" to be used -- in larger projects however, you need to
>think differently; usually you try to accomplish two things:
>
> 1) people do what they are good at
> 2) the number of interactions between people should be kept low

I disagree quite strongly with #2. In environments such as yours in particular, there are really huge staffs that have to be coordinated. Less coordination means one part of the system going in one direction, another off in another. System design only becomes better when the interation goes up. That's basic system engineering to my mind.

>for small projects I
>have often taken on the DBA role myself, but I find that it distracts
>me from the "real work", which is to build an application. when
>taking on the DBA role myself I spend time optimizing database
>interaction, making decisions about indexes and query strategies and
>figure out problems that come up related to the server itself.
>I've even found myself writing software to analyze tables and
>relations in order to anticipate locking and performance problems
>before altering or inserting new tables, relations or triggers.

I understand this to be the case. But where my "sadness" is coming from is that when messing with record tests to optimize database interaction takes enough time to be a distraction, then this is the wrong environment. (don't misunderstand me, I'm not saying there's anything wrong with you, I do understand that where you're coming from these tasks which are rocket science, they are no more complicated that a toaster in my environment)

>on larger projects not everyone can know everything all the time. on
>larger projects you design APIs and try to hide detail behind
>abstraction.

Agreed, as stated above, everyone gets enough of a chunck that they can handle. (but programmers can, and do, handle far bigger chunks where I come from) Then they spend time hammering out the interfaces.

>this works for small systems, but it doesn't scale well when you want
>to build a system that may involve many "man-years" of work.

It scales if your development environment scales together with the methodology. I've never been on a Progress project that took "many" man-years. A few man-years yes, but not many. And that's not for lack of being complicated. AT&T's own MIS department declared their Worker's Compensation plan unprogrammable it was so complicated. The parts that were possible to program were going to take 1.5 years and a team of 20-30. The company I used to work for did the whole thing with 4 people in six months. (and yes it was as complicated as I've seen, in the US each individual state has different laws so it was like building 50 different systems and putting them all together) I've worked on many projects that others attempted in other languages/environments/etc. that took many man years and failed. (or delivered half of the system) Even if others projected multi-man-year projects, they've always come way down with Progress.

It's not that I don't agree with your assesment of how many people today work. I just don't agree that we should needlessly separate job functions and lock ourselves away and interact with each other as little as possible. My software engineering background really screams out to me how bad an idea that is.

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