Chris Browne wrote:
[EMAIL PROTECTED] (Robert Treat) writes:
I feel like some type of counter-argument is that this is probably longer
than one would expect thier database software to last. :-)
That has the counterargument that if the database software works, it's
likely to get used for longer than one would expect.
I don't think I have ever seen a case where DB-based software got
replaced *earlier* than planned.
I have - but only where it only worked if you adopt a very limited
definition of "worked". When management's paid for something and they
want to deploy it despite warnings that it's just not going to do the
job these things can happen, and a rush project to replace the system
can arise when it becomes clear (to management) just how broken the
system really is. I've been lucky enough not to have to directly
experience such problems, but I know a couple of people who've been
saddled with implementing, then rapidly replacing, monster-from-the-deep
database systems. "VB6 and IBM UniVerse? Why not? ..."
I've hacked together small web apps in a couple of days that've gone on
to see six years (and ongoing) of heavy use at my work - because they do
the job, and because I haven't had the time or cause to replace them
with something cleaner. Every couple of years I have to go back and fix
something when a mistake in the code bites me, but all in all they've
worked amazingly well.
Given that I'd have to agree that it's a good idea to assume your
database software will live on well beyond your expectations, and it's
worth considering how you'll feel when someone calls you in 5 years with
an issue with some code you haven't touched since you wrote it as a
throwaway tool. The call will, of course, be urgent, and involve either
breakage that must be fixed in 10 minutes for some critical business
process (that you didn't know they even used your tool for) to continue,
or will be to inform you that you have one day to make major changes
they could've told you about six weeks ago if they felt like it. So ...
it's well worth considering the long term now.
Unfortunately I speak from recent experience - and my beginner
perl+MySQL code was NOT designed for long term flexibility and
robustness. *shudder*.
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
