Thread: Re: [GENERAL] interesting PHP/MySQL thread
Hey, I got forward your message from a friend, and I'd figure I'd just weigh in. > Alvaro Herrera <alvherre@dcc.uchile.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. -Sterling -- "Microsoft isn't evil, they just make really crappy operating systems." - Linus Torvalds
Sterling Hughes <sterling@bumblebury.com> writes:
> Many sites don't require a relational database system.
Agreed. If SQlite gets the job done for some folk, then that's the
tool they ought to use. I was just a tad bemused by the apparent
claim that it could be considered a substitute for Postgres (or even
MySQL) in general.
I think there's some merit in the idea of bundling both PG and SQlite
support in future PHP releases. You'd have both a high-end and a
low-end solution available. There are probably some people in the
middle who'd complain that neither solution quite hits their sweet spot
like MySQL did, but I'd bet that overall this'd cover quite a nice
range of problems.
regards, tom lane
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@dcc.uchile.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.
> >
> > > 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.
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. (*)
-Sterling
(*) 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.
--
"The three most dangerous things in the world are a programmer
with a soldering iron, a hardware type with a program patch and
a user with an idea."
- Unknown