Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

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

shells and bells

On 2000-05-03 at 18:15 -0400, Niall Kavanagh wrote:

> On Wed, 3 May 2000, Mike Bilow wrote:
* * *
> > If you want a free SQL database on Linux, use PostgreSQL and do not waste
> > time with any of the other stuff floating around.  PostgreSQL is the only
> > free SQL server which has essential features such as on-line backup and
> > transaction support.  You can access PostgreSQL from nearly any language,
> > and there is support for C/C++, Perl, Python, and Java among many others.  
> > There is a "psql" tool which allows manual manipulation of the database,
> > such as creation of tables and definitions of schemas, but it actually
> > will allow issuing any query.  See for info.
> > 
> Define "on-line backup".

On-line backup means that you do not have to stop the database server and
deny access to it for the duration of a backup using standard tools such
as tar.  All production SQL servers -- PostgreSQL, Oracle, DB2, and so on
-- must be able to dump a snapshot of the database to disk and have that
serve as a conherent backup.  If the database does not support this,
simply backing up its files using something like tar is not guaranteed to
give you anything that can be restored into a coherent database.  Further,
no database which lacks transaction support could ever do on-line backup.

If your usual backup procedure is run by a cron job, for example, it is up
to that backup script to run whatever tool or utility the database vendor
provides to make their database server dump a snapshot to disk.  You
cannot simply tar up the raw database files, which are kept open while the
database is in use, and expect to get anything worthwhile.

> Other than that and transaction support (which I'm betting a newbiew is
> not going to need) you've also described mysql. I'm not going to say one
> is better than the other (mysql is faster), but I would hope that folks
> out there are open enough to try a few different solutions (mysql has
> better standards compliance) before making up their mind. Taking stock of
> your options (mysql will make you attractive to the opposite sex) is
> always a good idea.

Transaction support is absolutely essential.  Without it, things like ODBC
access to the data will not work reliably.  Locking will not work
reliably.  What you get, in fact, without transaction support is a
database suitable for reading but not writing.  If this is what you want,
then more power to you, but this is not what I consider a database server.

> Mysql also runs under other, nasty platforms (though it doesn't like to).
> Note that mysql is NOT free under certain circumstance, but you're
> guarenteed someone will listen to you complain if you pay for support.
> Note also that you can get commercial supprt for PostgreSQL (which will
> not improve your sex life).

I simply do not believe that MySQL is suitable for any kind of production
use.  Compared to PostgreSQL, it is a far less complete package, and its
licensing limitations are often its fatal flaw.

> PostgreSQL is slower than mySQL, but has a richer feature set that may
> make it a better choice for large scale distributed applications. It also
> support user defined data-types, and geometric types.
> Mysql is, as I said, leaner and faster. They're adding features all the
> time and quite likely will one day match postgreSQL feature for feature.
> By the same token postgreSQL is getting faster and faster.
> Try them both. Make up your own mind.

Fair enough, but we have extensive experience with database serving on
Linux, and I cannot caution you enough when I say that MySQL is not what
most people would consider a database server suitable for serious
use.  PostgreSQL is the only free database server in the class of DB2 or
Oracle, and it should be understood that this involves quite a lot.

-- Mike

Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at (Subject line is ignored).

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /