[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MySQL vs postgres



>>There are programmatic ways to "simultae" nested subqueries.  But if
>>you need them on a pretty regular basis it might be easier to use
>>a DB that supports them.    It also depends on if you are updating your
>>database based on those queries, and whether multiple updates may
>>occur at the "same" time.  If both are true then I think you need
>>transactions (in order to make the action atomic) and record
>locking, which are not supported by MySQL
>My application would benifit by record locking so I am thinking
>postgres is the right tool to use.
>
>As a novice user of linux, SQL type db's apache and php, I have
>noticed that the books I have aimed at getting the php web system
>environment compiled, installed and running say little or nothing
>about postgres. They giveexplicit commands and directions to use
>MySql!

There really is no significant difference between using any given database and
PHP.  The commands vary somewhat but nothing major, the concept is always the
same.  

Again I'd like to push ODBC.  Which lets you (or anyone else who uses your
results) the freedom to use their existing DB or select one approriate to their
appliaction.  The unixODBC project at http://www.unixodbc.org is very good
software, and has a PHP HOWTO at http://www.unixodbc.org/doc/php3.html.  This
way you can even run your application on an NT PHP server as windows obviously
support ODBC.  UnixODBC comes with drivers for MySQL, PostgreSQL, Usenet (Cool!)
and even text files.  And you can get drivers for Oracle, Informix, etc... from
those companies sites.  

>
>Why is this? Heavy traffic on web applications, like a real time
>auction, hopefilly will have many concurrent users and overlapping
>sessions working on the same records in the same tables.  Seems to
>me record locking is essential for accuracy and efficienncy.

The VAST majority of DB access for many such applications is QUERY operations,
so things like record locking may actually have less importance than you think.

>Are there other issues why MySQL is the db of choice for people who
>write the php books?

MySQL is old, and thus has a large installed base,  it's lean features make it
fast on even quite old hardware, and it requires little administration.  Thus it
is very attractive to "hackers".  Often such project begin with little foresight
into their end scope or range of uses, or else the developer just doesn't know
alot about DB issues, or simply doesn't care.  I'm not dissin' the use of MySQL
in general, just that I think it gets chosen sometimes because certain issues 
are overlooked.

This is a frustration for me as I have both PostgreSQL servers, and an Informix
server, and I often find otherwise great GPL or free software, but it is
"welded" to this or that DB that isn't appropriate to my enviroment.

Systems and Network Administrator
Morrison Industries
1825 Monroe Ave NW.
Grand Rapids, MI. 49505