From: Colm MacCárthaigh (colmmacc at domain redbrick.dcu.ie)
Date: Sat 14 Sep 2002 - 02:29:52 IST
On Sat, Sep 14, 2002 at 01:40:42AM +0100, kevin lyda wrote:
> > In my mind, I tend to think of MySQL as the open source alternative to
> > Access databases, and Postgres as the alternative to SQL Server. I am
> i think that's a poor comparison. to begin with access isn't really
> client/server oriented, while that's the only way to use mysql.
It's not a totally bad comparison from some perspectives. They are
both essentially convientent interfaces to convetional filesystem
DB hash as opposed to an actual DBMS.
> > convinced that the enterprise class databases (Oracle, Sybase, DB2,
> > Informix) will offer better performance, scalability and reliability under
> > heavy load situations, but this may not be a real requirement in this case -
> > especially if you only have 25 users. OTOH Postgres and MySQL have improved
> > a lot recently, so may I need to re-evaluate my opinion of OSS databases.
> wander into your local newsagent. if there's an alphyra credit card
> terminal that sells o2/vodafone/etc top-up pins, you'll have a chance to
> use mysql. the invoices the merchant receives every week (like several
> (10+?) thousand others just like them) is generated from a mysql db
> (via perl and troff).
That could be done in shell using tdb. Sure, mysql can store and index
records, that's no biggie :) That makes it a database, but not
a managment system :)
MySQL suits a hell of a lot of tasks, this is one of them. Postgresql
would do it better in my opinion, but there's no harm in using MySQL.
> i'm not quite certain what enterprise class is. does that sound like
> it yet?
Not really. A more realistic enterprise application is a live
registration system, or real time data gathering from *diverse*
sources, where triggered commits and data verification at the
fundamental level, which may be coming from a diverse range of
sources is very important.
Real DBMS's give you the ability to trigger and use SPROCs to
take care of sanity checking your data. What if tomorrow the
people who developed the above are asked to make their system
available via the web ? And then via call up phone service,
and then via real human operators ?
How are you going to ensure the integrity of your data with
such a broad and growing range of inputs? Sure they should
all be verifying it indivually, not least so that they
can generate some useful failure messages to the end-user.
But risking your data integrity at the DB level due to
a bug in one input system is not acceptable. A fundamental
of good database design is that you sanity check and
integrity check your data as close to the database as
possible, you do not trust your input systems to do
it for you.
For example, something as basic as this, can you even
make MySQL generate a failure if you try to insert a non
RFC822 compliant e-mail address into a certain field ?
Or say recognise and enforce correct usage of IPv4
dot-quads, or IPv6 colonated IP strings ? Can you verify
that a timestamp is not later than now, no matter what
timezone it's in ? Can you give strict , but complex bounds
to your data ranges ?
What about if you'd like to store the last, say 100
credit card numbers used in a round-robin database, which
are checked when cancelations are requested, and then
drop any CC #'s for security reasons ?
For a single input system, the arguments arnt queit as
effective, but when you start seeing multiple inputs
you start saving time and money :)
-- colmmacc at domain redbrick.dcu.ie PubKey: colmmacc+pgp at domain redbrick.dcu.ie Web: http://devnull.redbrick.dcu.ie/
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:18:52 GMT