On 23 Jun 2003, Sterling Hughes wrote:
>
> > >
> > > > 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.
>
> That's what you have locking for. That's actually what you have sqlite
> for. One of the "common" problems as you mention it are that people
> write file logic themselves. Its also very fast so long as your not in
> a write heavy environment (in which case performance is terrible, but
> not as bad as it would be with custom PHP solutions).
>
> SQLite is in my opinion a great flat file abstraction interface. It
> handles all the issues surrounding file access - concurrency, paging,
> buffering, etc. And it provides a familair, abstracted interface to
> accessing data in these files.
>
> Would I use it as an RDBM? Hell no.
> Would I use it to build a weblog system? Hell yes.
>
> Remember, PHP is widely used on shared hosting providers. Many of whom
> don't wish to provide an RDBM, and tangle with permissions, performance,
> and user support requirements. SQLite is a godsend for those people who
> don't have access to any other solutions.
>
> >
> > 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.
>
> Uhmm. MySQL AB are not "playing" the PHP community. I happen to know
> the folks doing the licensing quite well, and while I don't particularly
> like how its been handled, I'm certain there was/is no intent to play
> PHP.
The primary reason for changing the 4.x connect lib to GPL was to
encourage people to buy commercial software licenses.
In my opinion, this is playing the GPL community. PHP happens to be part
of the community they are playing.
What other reason can there be for switching their licensing of their
connect libs while also making sure that 4.x won't talk to an app using
the LGPL'd 3.x connection library?
> In any event, MySQL is debundled. While I'm not thoroughly convinced
> that PostgreSQL needs to bundled/automagically enabled, I probably
> wouldn't be against automagical detection. (*)
I agree with this. I think bundling a connect lib directly in raises a
lot of issues with forward / backward compatibility, and would much rather
the connect lib installed with the product be detected and used at build
time. I would say that if a box has any of the standard free connect libs
(LGPL or less restrictive) on it, then it's probably a good idea to
automagically detect and include support for them, not just pgsql or
SQLite, but interbase, and all the others. It's just easier for Joe
Beginner if he doesn't have to enter a --with-dbnamehere switch everytime
he builds to get connectivity.
> (*) Note, I was personally against bundling libmysql as well. I speak
> for myself, as one voice in the PHP community. You're best off making
> this case on internals@lists.php.net if you want PostgreSQL to be
> further supported.
Thanks for the recommendation. I'll take a look at that list when I have
a moment.
As an aside, I'd highly recommend auto-including gdbm ability when
building if it's detected. I find it far more intuitive to access a DBM
style database from there than using a SQL interface. Plus it's a pretty
small lib, and including it means you have a supported package that is
known to work well for people who want simple database type access.
