-----Original Message----- From: fedora-list-admin@xxxxxxxxxx [mailto:fedora-list-admin@xxxxxxxxxx]On Behalf Of Richard Welty Sent: Saturday, January 31, 2004 2:08 PM To: fedora-list@xxxxxxxxxx Subject: Re: MS-SQL -> OS DB Migration was Re: idiot database flamewars 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 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@xxxxxxxxxx To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
