RE: MS-SQL -> OS DB Migration was Re: idiot database flamewars
From: Mike Westkamper (mjwestkamper_at_weiinc.com)
Date: 01/31/04
- Previous message: David C. Hart: "RE: Kernel build problem"
- In reply to: Richard Welty: "Re: MS-SQL -> OS DB Migration was Re: idiot database flamewars"
- Next in thread: Paul Thomas: "Re: MS-SQL -> OS DB Migration was Re: idiot database flamewars"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: <fedora-list@redhat.com> Date: Sat, 31 Jan 2004 14:56:19 -0500
-----Original Message-----
From: fedora-list-admin@redhat.com
[mailto:fedora-list-admin@redhat.com]On Behalf Of Richard Welty
Sent: Saturday, January 31, 2004 2:08 PM
To: fedora-list@redhat.com
Subject: Re: MS-SQL -> OS DB Migration was Re: idiot database flamewars
On Sat, 31 Jan 2004 18:54:20 +0000 Paul Thomas <paul@tmsl.demon.co.uk>
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@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
I too suggest an engineered approach.
There are a number of good relational databases that play on multiple
platforms, none are free! You may not pay a license fee for some, but you
will pay in other ways. From personal experience, consider the true
multi-platform aspect and what it is worth to you. Then consider the cost of
migration, both technical and administrative. And don't forget the cost of
converting the data.
I did a large conversion from MS-SQL to DB/2. The database was spread over
mainframes, Windows, Unix and Linux platforms. It worked well when done, and
still does today. The conversion took three people a year and almost two
months by 24 hours per day to migrate the data.
A large commercial database is good if you what the reliability, support and
availability of trained professionals to convert and maintain the system. My
SQL is good and I've used it for some jobs, however I've had a number of
problems that trace back to its origins. I've also used Oracle, Tamino and
some pretty custom stuff. Each has its place. I do like Tamino for its
native XML abilities, Oracle for its scalability and DB/2 for its robust
implementations and inter-operability with mainframes. Not one is easy.
Good luck
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
- Previous message: David C. Hart: "RE: Kernel build problem"
- In reply to: Richard Welty: "Re: MS-SQL -> OS DB Migration was Re: idiot database flamewars"
- Next in thread: Paul Thomas: "Re: MS-SQL -> OS DB Migration was Re: idiot database flamewars"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
