I wasn't talking about migration of a 30gb DB2 system. I was talking about porting a system that was specifically designed to be ported. If you design it correctly up front, you can port it very painlessly. You can easily develop a system that uses the proper datatypes and does NOT use MSSQL-specific extensions. This type of system can easily be ported.
Porting a legacy application that someone else developed is likely to be a duanting task, I agree. But I'm talking about a system that has not been developed and can be designed with porting in mind. I just finished a system that was developed 100% for MySQL. It was ported to work with MSSQL and now works with either. There was exactly ONE column change and the actual porting of the database and the back-end code was 2 hours max. This is because there is almost nothing to do provided you've designed the system with porting in mind... You've seen some OLAP developers take 3 months to complete a migration, and I've seen (at least one) company take over 6 months to convert a Paradox system to MSSQL. Neither example is relevant to the current discussion. An MSSQL system can be designed and developed with porting in mind and porting can be painless. On Fri, 18 Jan 2002, Todd Williamsen wrote: > I would say it would take a month at least to complete the job > correctly. I have seen some top OLAP developers take 3 months to > complete a 30gb DB2 to an Essbase migration including all documentation > and politics involved. Two hours? You should be fired for just > thinking that! Just kidding. The whole project scope of a migration is > HUGE! > > Here would be a vague outline of this type of project: > > 1. Politics > 2. What can mySQL do that MS SQL cannot do? > 3. Technical issues > 4. Documentation > 5. Schemas > 6. admin functions > 7. training > 8. post installation testing > 9. pre install testing, Beta > 10. load testing > 11. get the picture? > > This is NOT a two hour job! > > -----Original Message----- > From: Tony Buckley [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 18, 2002 10:56 AM > To: j.urban > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Porting from MS SQL to MySQL > > > ----- Original Message ----- > From: "j.urban" <[EMAIL PROTECTED]> > To: "Tony Buckley" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Friday, January 18, 2002 4:07 PM > Subject: Re: Porting from MS SQL to MySQL > > > > > Porting a DB takes more 'than a couple of hours'. What about the > written > > > procedures, the security mappings, the back up and recovery procs, > the > > > fallback arrangements, the testing etc. > > > > Yes, porting a database that was written for MSSQL with no intention > of > > porting can be a painful proposition. However, if you have control > over > > how the system is developed, you can easily design the system to be > > compatible with EITHER MSSQL or MySQL (the differeces are > > well-documented). If you develop your system with porting in mind (ie > the > > original post of "they'll develop in SQLServer and port it to MySQL > > later") porting should not take more than a couple of hours. You > simply > > choose appropriate datatypes and don't use MSSQL-specific > extensions... > > > > > I still don't agree with this. Yes you can ease the passage by > considering > all the issues up front but it is still not a trivial job for a database > of > any consequence. There is more to a database than a physical schema - > what > about all the administration procedures that sit around it, what about > tuning the new physical implementation, what about reviewing the access > paths and optimisation, what about the redevelopment of data loading > scripts. As I have said in another post, it's futile arguing about it > because we don't know enough about the technical situation let the > business/political one. > > Are you seriously saying you could sit down in front a reasonably sized > DB > you had never seen before and understand all the business issues and > pick it > up and ship to a new RDBMS and platform, rewrite the document, replan > what I > have stated above, and get it back up and running in two hours? Perhaps > I > am getting too old and slow but it would take me longer :-) > > I am not saying it's a huge task to do any of this but whoever said, "I > could do it in a couple of hours", doesn't understand the background > that > led to a company quoting E18k; nor do any of us, and for anything other > than > a very very trivial system, two hours seems inadequate. > > This is an area that interests me, because I directly bid for work such > as > this, and when tendering you usually find the bloke down the road > working > out of his spare bedroom that thinks he can do it for a tenner over one > day. > The company requesting the work then thinks that everyone else is > overinflating their prices so goes cheap and pays for it big time > downstream. Cheapest and quickest is rarely best. On the flip side, > nor is > most expensive. Tricky world init. > > Tony > > > > --------------------------------------------------------------------- > Before posting, please check: > http://www.mysql.com/manual.php (the manual) > http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail > <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
