[KLUG Members] MySQL adoption

Robert G. Brown members@kalamazoolinux.org
Tue, 11 Nov 2003 10:48:52 -0500


On Tue, 11 Nov 2003 09:45:36 -0500, Adam Williams <adam@morrison-ind.com> wrote:

>> I looked around here earlier to see what DBMS'es are running. I found 5,
>> including MySQL and Postgres. I don't feel a need to rush around migrating
>> everything to one DBMS....
>
>I agree, but just for a balanced argument, the demands/requirements of a
>SOHO or small-business are not analagous to those of an "enterprise". 
Absolutely, don't I know it! Anyone reading this can be assured that it
is true. Sizing the tools for the job at hand is normal.

>At a certain point of scale/complexity the rules fundamentally change. 
Yes, one of those things that has to be seen to be beleived. There are 
many ways to measure scale...and complexity often goes up as some exponen-
tial of the scale or size metrics used. People who have written applica-
tions with 15 or 20 tables often do not grasp the notion of applications
with 5,000 tables, and the number of relations that implies...

>I also have four databases ....
Home or work network? I understand that with you, there's a difference...

(1 Informix instance,
Never had the "honor".

>1 MySQL instance, 3 PostgreSQL instances, ....
Hence my question above. I established 1 server for PG, and it's been a very 
good choice. My LAN is small as business LANs go, but it has served quite
well. The MySQL is the backend for a few apps I've downloaded...

>and 1 Goldmine disease),
I'm sorry. :)
Actually, I've run Goldmine with an RDBMS backend. Maybe you can dump
theirs and move the data to PG or MySQL.

>the ability to have *1* would be a huge boon - and fundamentally I don't
>see why I can't have *1* - had the developers of given applications been 
>more "considerate" of larger issues.
There's no compelling reason why you can't have *1*; but it is often not
an economically attractive choice to make. If you think it is, then you're 
wasting your time yakking about it here, let's talk about about a migration 
project, baby needs new shoes! :)

Levels of abstraction keep rising. Databases and DBMS's were once considered
to be abstractions for file reads, in-memory seach and sort routines, and
other kinds of activities. Now we talk about abstracting the DBMS away, and
maybe (often) SQL as well. That's all fine, applications may exhibit best 
practices at the time, but not today's. Also, applications often start life
as a small-scale system that doesn't demand this level of abstraction, but 
later on....

I'd certainly agree that we want a level of abstraction that allows the code
to be more portable, within some economic considerations.

>>>At the same time there are so many instances of these 
>>>holy wars between various camps. No one said life as a techie was 
>>>boring. :-)
>I really don't see anything in the thread that even vaguely resembles a
>flame or holy war.
I don't think the author was commenting on THIS thread...

>Behind the PostgreSQL/MySQL debate lie interesting assumptions concerning 
>application developement and deployment.
I would prefer to pursue that discussion, and believe that it is not framed
well as a "PostgreSQL/MySQL debate".

>Both PGSQL and MySQL are darn good - and fast to a certain point of scale -
>databases.
That's right, they represent different value and utility propositions. This
renders almost any general discussion that pits one against the other into
the realm of fruitless exercise....
							Regards,
							---> RGB <---