Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] interesting PHP/MySQL thread

From: Sterling Hughes <sterling(at)bumblebury(dot)com>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Josh Berkus <josh(at)agliodbs(dot)com>, Joe Conway <mail(at)joeconway(dot)com>,"Advocacy (PostgreSQL)" <pgsql-advocacy(at)postgresql(dot)org>,PostgreSQL-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: [GENERAL] interesting PHP/MySQL thread
Date: 2003-06-23 15:06:51
Message-ID: 1056380811.6262.115.camel@hasele (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-general
> > 
> > > 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(at)lists(dot)php(dot)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

In response to

Responses

pgsql-advocacy by date

Next:From: Reuben D. BudiardjaDate: 2003-06-23 15:43:29
Subject: Re: [GENERAL] interesting PHP/MySQL thread
Previous:From: Lincoln YeohDate: 2003-06-23 14:23:23
Subject: Re: [GENERAL] interesting PHP/MySQL thread

pgsql-general by date

Next:From: Bruce MomjianDate: 2003-06-23 15:12:36
Subject: Re: A creepy story about dates. How to prevent it?
Previous:From: scott.marloweDate: 2003-06-23 14:52:23
Subject: Re: A creepy story about dates. How to prevent it?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group