Subject | Re: [Firebird-general] pro&contra |
---|---|
Author | Aage Johansen |
Post date | 2009-08-25T22:44:40Z |
Ann W. Harrison wrote:
I'm not sure how it will turn out. Laws and regulations (involving
encryption) is what may force a switch. Note that sense and/or
rationality doesn't really enter into the discussion when regulations
are waved in front of us - comply "with the letter" or accept consequences.
To me, it looks as a lose-lose project. Converting many databases
(although only a moderate number of procedures, triggers, etc.) can
be a big job. Rewriting applications - all of which uses IBObjects -
will take time. Lots of time. After that, there are licence costs
and increased costs for "care and feeding" of a new RDBMS.
As I've mentioned, I did use (and maintain) a Sybase database for
some years. This is 5+ years ago, and I haven't missed those tasks
for a second all these years. I still remember seminars where Sybase
gurus extolled the joys of lock escalation - those were the days!
I will be very saddened if I have to see Firebird leave us at
work. It seems that there is a lesser evil than conversion to
Sybase: Interbase. There is mention of encryption facilities, and
that might be (almost) sufficient for compliance. At least,
conversion should be less
problematic. Maybe I retire before the transition is complete (or even begun)!
I do have a couple of Firebird projects for friends who use Fb
databases to run their businesses, so I will hang around.
--
Aage J.
> Aage Johansen wrote:Thank you, those points are important and they will be part of discussions.
>> At work, some are advocating a migration from Firebird to Sybase (yeech!).
>> Could someone here provide a list of arguments for not migrating?
>
> Well, the first one that I can think of is MVCC - moving to lock-based
> concurrency management could be a real nuisance. Triggers may be
> another problem ... the last time I looked (not recent) Sybase
> triggers didn't cascade. Stored procedure syntax and semantics
> will be a problem.
>
> Any time you've spent tuning queries will be lost. Sybase can't use
> multiple indexes on a single record source in a query, so you'll
> probably need to rethink your indexing strategy.
>
> And of course, there are the usual arguments against migration in
> general. A) It works now, why waste time moving it rather than
> improving it or other things? B) We have in-house expertise. And
> the open source argument that you're not spending money on licenses.
I'm not sure how it will turn out. Laws and regulations (involving
encryption) is what may force a switch. Note that sense and/or
rationality doesn't really enter into the discussion when regulations
are waved in front of us - comply "with the letter" or accept consequences.
To me, it looks as a lose-lose project. Converting many databases
(although only a moderate number of procedures, triggers, etc.) can
be a big job. Rewriting applications - all of which uses IBObjects -
will take time. Lots of time. After that, there are licence costs
and increased costs for "care and feeding" of a new RDBMS.
As I've mentioned, I did use (and maintain) a Sybase database for
some years. This is 5+ years ago, and I haven't missed those tasks
for a second all these years. I still remember seminars where Sybase
gurus extolled the joys of lock escalation - those were the days!
I will be very saddened if I have to see Firebird leave us at
work. It seems that there is a lesser evil than conversion to
Sybase: Interbase. There is mention of encryption facilities, and
that might be (almost) sufficient for compliance. At least,
conversion should be less
problematic. Maybe I retire before the transition is complete (or even begun)!
> Besides, we'd miss you.Thank you VERY much.
I do have a couple of Firebird projects for friends who use Fb
databases to run their businesses, so I will hang around.
--
Aage J.