Re: [GENERAL] interesting PHP/MySQL thread

On 23 Jun 2003, Sterling Hughes wrote:

> Hey,
>
> I got forward your message from a friend, and I'd figure I'd just weigh
> in.
>
> > Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> > > Better hurry. Sterling Hughes is proposing to enable SQlite support by
> > > default; that move could be bad for the lobbying of activating Pg
> > > support.
> >
> > SQlite? Sure, give it a try. (I was slightly astonished to compare
> > these two pages:
> > http://www.hwaci.com/sw/sqlite/omitted.html
> > http://www.hwaci.com/sw/sqlite/datatypes.html
> > At the very least, one would have to say that the author feels free
> > to define those parts of SQL he doesn't like as "not features". There
> > sure isn't anything on the former page to suggest that vast parts of
> > the SQL spec are being ignored per the latter page.)
>
> Yep. In fact I would go as far to say that SQLite is really just a nice
> interface to a DBM.
>
> > SQlite is even less competition from our point of view than MySQL is
> > ... if the PHP guys think their users will be satisfied with SQlite,
> > let them try it for awhile.
> >
>
> This is actually my point in choosing SQLite. I've used both MySQL and
> PostgreSQL extensively, and I like both systems alot (please, I don't
> mean to start a war on which database is better here.) SQLite is not
> really a competitor to either of these solutions. MySQL and PostgreSQL
> are both database servers, SQLite isn't. Just because they all speak a
> SQL dialect, certainly doesn't mean they are the same thing.
>
> But one of the most common things that people want to do with PHP is
> save data. Many sites don't require a relational database system. For
> example, implementing a weblog system with a RDBM system is overkill.
> SQLite fills the nice nicely. It provides a coherent system for doing
> simple stuff. No need to worry about locking, data formats, etc. And
> most importantly, no database server is required, so you can write an
> app for sqlite, and have it always available, on every shared host.

What about concurrency issues? It may well be that a system built to log
with a non-concurrent database works fine until it hits a certain load
point, then data starts to get corrupted due to parallel access issues.

It's quite common for me to see people saying "we don't need something as
complex as postgresql" then 4 months later, when their log files or
whatever they're doing get corrupted, they want a quick fix. The quick
fix is usually to switch to a database oriented system.

I would at least hope that PHP would pickup the postgresql headers if it
sees them and include postgresql support automagically.

And I agree with the point made in the php dev mailing list that getting
an exception is a Bad Thing. It goes against the whole open source
concept. Plus, I don't think you can actually author a "GPL exception" so
it would have to be an exception to the commercial license, i.e. PHP use
automatically gives on a free commercial licensed version of MySQL. If
it's an exception based on the commercial license, it can likely be
revoked in the future.

MySQL AB are playing the PHP community. PHP is my primary development
environment, and I'd hate to see its well get poisoned by this behaviour
of MySQL AB.