> original platform. I can see where this kind of design is useful... if you > KNOW you are going to port to MySQL in the future. But in that case, why not > design there in the first place?
I have no idea and I didn't suggest this was a good solution, but the question was posed, so I simply stated that it's possible to develop your MSSQL system with a MySQL port in mind. I agree completely, if you're going to port it anyway, it should simply be developed for MySQL from the beginning. But who knows? As others have stated, there may be a good reason to do this that we don't know about... On Fri, 18 Jan 2002, Chris Lott wrote: > > 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. > > Yes, and such an application is likely not to be nearly as efficient on the > original platform. I can see where this kind of design is useful... if you > KNOW you are going to port to MySQL in the future. But in that case, why not > design there in the first place? > > Otherwise, if I am using SQL Server, I am going to take advantage of true > foreign keys, stored procedures, and other SQL Server attributes that make > for a more easily supported and performance-enhanced system. This is not > going to lead to a system that is easy to port :) > > c > -- --------------------------------------------------------------------- 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
