Thanks Rod,
I certainly find it a must to use such features as referential integrity
(even it costs a little), transaction support, custom objects, etc.
which make postgreSQL stand apart from mySQL, etc. Such standard
features as value checks, which I believe can be ported quite easily
also don't arouse my doubts.
I guess features that don't port well across DBs are stored procedures
and consequently triggers. Those are the things I am referring to. For
example, if we need to increment a field by a certain value once in
every 2 weeks, would you suggest using stored procedures to accomplish
it, or app logic? And in general, when would you say it's worth to use
stored procedures?
Thanks,
r.
-----Original Message-----
From: Rod Kreisler [mailto:rod@23net.net]
Sent: Saturday, November 16, 2002 9:02 AM
To: Reshat Sabiq; 'Joel Rodrigues'; pgsql-novice@postgresql.org
Subject: RE: [NOVICE] using functions to generate custom error messages
Reshat,
You have some points, however just as there is the possibility of
switching
RDBMS, there is a possibility that the frontend language will change as
well. Furthermore, a greater possibility, I think, that multiple
frontends
under different platforms will access the one data source.
Data integrity constraints MUST be in the database itself anyway (if
not,
then I suggest using MySQL...), otherwise you are hoping that multiple
ADs
are going to properly maintain integrity in the applications.
IMHO, what Joel suggests is quite reasonable.
Rod