Cross platform scripting language and database

[David A. Bandel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 14 Dec 2003 22:16:05 -0600
Alma J Wetzker <almaw at ieee.org> wrote:

> David A. Bandel wrote:
> > On Sat, 13 Dec 2003 20:13:35 -0600
> > Alma J Wetzker <almaw at ieee.org> wrote:
> > 
> > 
> >>>Perl comes immediately to mind.  Java is a real outside
> >possibility.>>
> >>>Do you intend to store the image itself into the database or just
> >the>>name of the image with the description?  (Are you using a real
> >>>database {MySQL, PostgreSQL, ...} or data listing?
> > 
> > 
> > MySQL - a real database?  Not hardly.
> > 
> > PostgreSQL, Informix, Oracle, others, are _real_ databases.  MySQL
> > is a file system you access with SQL commands.  It lacks:
> > ****transaction support****, outer joins (how do you create a real
> > relational database application without left outer joins?),
> > triggers, stored procedures, etc(does it have views?), AND it's not
> > ACID (see lack of transaction support) 
> 
> It is a much a real database as access and a few other options that
> get mentioned.  Would I use it for a mission critical, bet the
> business, type of application?  No.  Would I use it for lightweight
> database applications? Absolutely.  It seemed a reasonable option for
> the project as I saw it described.  Usually, you pay in performance
> for a "real" database.  That extra functionality costs cycles.  I
> think you should only use a "real" database when the data security
> demands that type of uptime and performance hit.  The project I heard
> about sounded like it could wait for a restore from backup.
> 
> My GE training says that the quality solution is the one that gets the
> job done in the best way.  Don't waste time and resources overbuilding
> a solution and don't skimp on tools when you need a feature.  Making
> those choices is the most fun I have in this technology whirlwind.

First off, if you're going to have one table and only about 50 rows, you
don't need a database.  Any toy like Access or even a spreadsheet will
do.  Even if you get to 5000 rows, but still only one table, you're
better off with a hashed file.

But if you've got a true RDBMS with over a dozen tables and thousands of
rows, then all you'll end up with using MySQL is corrupted data.  And
using two inner (natural) joins when a simpler left outer join will do
is a real waste of cycles.

But this is where you have to know where things are and where they're
headed.  Starting out with something too big or too small for the job
will bring nothing but headaches.  And while the SQL interface (user
commands) is the same between different systems (i.e., the left outer
join syntax is basically the same in Informix, Oracle, or PostgreSQL),
the administration side is tremendously different between them (with
Oracle taking the prize for being the most outrageously difficult,
frustrating, and confusing -- i.e., the Windoze of the SQL world).  So
personally, learning how to admin a SQL database that isn't -- well, I
don't have the time.

Ciao,

David A. Bandel
- -- 
Focus on the dream, not the competition.
		Nemesis Racing Team motto
GPG key autoresponder:  mailto:david_key at pananix.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/3anKj31PLQNUbV4RArC4AJ43ct/AJstzNgMg+jAgkqXz4OXwMACcCGiV
52Q1TSonw1D9tyddAy+N3PY=
=cRay
-----END PGP SIGNATURE-----