Re: The MySQL/PHP pair

From: Bill H <wphaskettatTHISISMUNGEDadvantosdotnet>
Date: Tue, 9 Nov 2004 21:54:19 -0800
Message-ID: <GYednWcMZJqSMAzcRVn-ig_at_adelphia.com>


"Laconic2" <laconic2_at_comcast.net> wrote in message news:lrCdnVwok8DxDwzcRVn-ug_at_comcast.com...
>
> If you you are
> simply referring to Dawn's concern with total cost of ownership, my
> reaction is: "Well, Duh!"
>
> What makes you think there is anyone in this forum that doesn't get the
idea
> of holding costs down???

Several reasons, really. Many of the IT departments I've been involved with, and do business with, between the PHBs and the DBAs, don't operate in an environment designed for them to know the true costs of their work. By definition, they're a department and operate under department guidelines. In a smaller business the owner is responsible for everything. Each mistake costs the owner directly (e.g. cash out of their pocket). This is not the model of a large company department. We can discuss the similarities and differences but I only want to answer your immediate question.

I don't presume to know the extent of business ownership experience in this forum. But since it is an IT forum, I'd postulate the members of the department set outnumber the members of direct business owners set. :-) However, I could be incorrect in this assumption.

> Just what was it that made you give up your vacation anyway, if it's not
> too private?

In a small business, all cash flowing into the company goes first to the employees, then to the gov't, then to the rent, then to ...., and finally to the owner. This is the truth of business ownership. No money, no vacation. It's simple, really.

> I have to agree with you that the internal politics of getting groups to
> truly collaborate with each other, instead of pretending that the
workplace
> is one giant "survivor's island" is truly formidable. But this is not
> unique to IT. We have sales departments, advertising departments, and
> strategic marketing departments that ought to be working synergistically
> with each other, but are not. And I could go on.

This is one of the general points I'm always trying to make: that the standard IT operational model could certainly use imput from other areas of the business entity.

> Some of us may be denigrating her experience. I don't count myself as one
> of those. I'm just saying that the teams I've been part of have had
better
> results from products like Oracle than the results Dawn says her groups
have
> acheived.

I've had excellent experience with RDBMS products too. Heck I'm one of those certified PeopleSoft developers which can use a number of DBMS products.

> What is surprising is that, when Dawn was asked to list the importance she
> placed on various factors in influencing her assesment of the weaknesses
of
> products like Oracle, the weight she put on the product license cost was
> 0%, unless I misread her.
>
> BTW, what we are discussing is Oracle RDBMS, not Oracle Financials.
I've
> never used Oracle Financials myself, so I can't comment. But Oracle
> Financials really doesn't have all that much to do with "database theory",
> does it?

I thought her list was funny and thought provoking. I didn't read much more into it than that. :-)

Another general point I'm always trying to make is: the applications using database systems should not be dismissed off hand when discussing databases. Because database systems are used to build applications, application structure and database structure often overlap. I don't believe this point is given enough credence by many with a strictly IT perspective.

> My own attitude is there there never has been one single "silver bullet"
in
> the world of IT. And every product, methodology, paradigm, or whatever
> that has been elevated to the category of "silver bullet" has been
oversold.
> Some applications should use an RDBMS. Some should use some other kind of
> DBMS. And some shouldn't use a DBMS at all.
>
> Ditto for Peoplesoft or Oracle Financials.

Ahhh, the "silver bullet". I view the dbms as part of a business solution; to be analyzed with the various components of the solution together, or at least attempt to measure the effects of one on the other. That's why I'm inclined to be more inclusive of competing ideas for the very reasons you stated above; there's diversity to our problems. :-)

Bill Received on Wed Nov 10 2004 - 06:54:19 CET

Original text of this message