[KLUG Members] MySQL adoption

[Adam Tauno Williams]

>>At a certain point of scale/complexity the rules fundamentally change. 
>Yes, one of those things that has to be seen to be beleived. 

A common failure of our education system I think - students are turned into
"believers".  Depends on the institution,  but a very prevelant problem

>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...

Yep, for the text to be readable our ER diagram prints out at around 8 x 11
feet. :)  Wall paper!

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

Work, at home I've got one PostgreSQL instance - and thats plenty for something
I don't get paid to support.

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

Actually rather nice.  Functionally comparable to PostgreSQL except extremely
fast on large sort and actually has useful management tools.

> >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.

They dropped support for ODBC, etc...  It is now either their proprietary flat
file thing or M$-SQL - your two choices.  It baffles me why one would choose
that;  but I expect GoldMine to go away as management hates the support company.
 :)  Still have to live with it for now.

> >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! :)

One is underway, but not to one database as some applications just aren't ours
to modify (Sigh, did I mention I love Open Source?).  Maintainers are either
dead, gone, on to other things, etc...  pure maintenance mode.  We are
constructing a business logic system that integrates the databases and uses the
informix engine to generate a unified near-real-time view for data miners,
report generators, etc...  A second best solution, but not without its own
advantages - changing business procedures, etc... does become a much less
painful thing.
http://www.brunswickwdi.com/bie

> 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....

This is really the problem that plagues alot of Open Source apps (IMHO), and why
so many projects on sites like Freshmeat seem to suddenly "brick wall".

On older systems abstraction layers exacted performance penalties, consumed
scarce resources and posed other real-world problems.  Today I think that has
been very much mitigated and the economics (both monetarily in preserving
investment in developement and in leveraging technologies) really favor almost
always putting layers between interfaces, logic, and data stores.

The real problem I think is that doing so does increase the initial learning
curve and extends the time to a "working" solution - especially in relation to
solving *apparently* simple problems.

> >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".

True,   but these theoretical discusses have to initially grow out of real world
situations (and eventually come back to them).