On Sat, 31 Jan 2004 18:54:20 +0000 Paul Thomas <paul@xxxxxxxxxxxxxxxx> wrote:
> On 31/01/2004 17:08 Richard Welty wrote:
> > MS SQL Server-> <some Open Source DB> is likely to be
> > every bit as challenging, so it's pretty silly to propose it in
> > this case.
> If you search the PostgreSQL archives you'll find a good number of
> successful migrations from MS SQL. The major work generally seems to be in
> re-writing stored procedures. Not a drop-in replacement solution, I agree
> but consider this: what if a company wants to migrate their desktops to
> Linux but can't get the required connectivity to MS-SQL? Should they
> meekly accept that they're locked into M$ for ever? Or should they
> investigate ways of replacing MS-SQL (maybe even with another proprietry,
> but multi-platform, DB)? Which would you advise?
they need to look at the entirety of their application and consider what it
is that they are doing that is causing the lock in, and then start taking
an iterative approach to breaking the lock.
there's no one true path, it depends on the situation. usually they've
coded a lot in C# or VB making it hard to migrate (but if they've done
that, they're SOL when it comes to non-MS desktops anyway.)
if it's non-standard SQL in an otherwise portable langauge, then
they probably need to look at whether they have properly
implemented an M-V-C architecture that hides the SQL from the
bulk of the app, so that the SQL is isolated and can be dealt
with w/o massive disruption. at that point, you look at what
non-standard features are in use, and figure out how to revise
the architecture to facilitate migration.
the main thing is that you may need to move the database first,
before you can move the desktop. this all presumes that there
is no answer involving JDBC or ODBC, which make desktop
migration fairly straightforward and independent of database
migration.
you can do a forklift, and switch everything all at once, but it
won't be seamless, it never is. people who want to do forklift
conversions need to understand the implications, but often
they're neck deep before they finally understand.
richard
--
Richard Welty rwelty@xxxxxxxxxxxxxxx
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
