sql2000 to mysql
Hello, Can someone advise me of the best/easiest way to move an entire DB (Tables and data) from sql2000 (my client) to mySQL (my System)? I need to advise someone on how I wish the data sent to me. Any help would be appreciated. Thanks, Tim -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: sql2000 to mysql
Are you wanting to move Foreign keys, Triggers, Stored procedures and the like as well or just the data? -Original Message- From: Tim Winters To: [EMAIL PROTECTED] Sent: 8/24/04 10:36 AM Subject: sql2000 to mysql Hello, Can someone advise me of the best/easiest way to move an entire DB (Tables and data) from sql2000 (my client) to mySQL (my System)? I need to advise someone on how I wish the data sent to me. Any help would be appreciated. Thanks, Tim -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: sql2000 to mysql
Victor Pendleton wrote: Are you wanting to move Foreign keys, Triggers, Stored procedures and the like as well or just the data? definitely!! so you make relations in your codes for projects... If not use Triggers, not use Stored procedures then, You move database, table and data with a small script.. -Original Message- From: Tim Winters To: [EMAIL PROTECTED] Sent: 8/24/04 10:36 AM Subject: sql2000 to mysql Hello, Can someone advise me of the best/easiest way to move an entire DB (Tables and data) from sql2000 (my client) to mySQL (my System)? I need to advise someone on how I wish the data sent to me. Any help would be appreciated. Thanks, Tim Best Regards. -- - Davut Topcan -- ~ ~ ~~ ~ - OTVT Solutions~ ~ - IT Solutions ~ ~ - Web Development ~ ~ - Software Development ~ ~~ ~ -- ~ ~ == JacK == ~ ~ | | ^Daniel^ ~ ~ _ | | ^^~ ~ | |_| | www.NoGate.org~ ~ \___ / www.DTClife.com ~ ~~ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: sql2000 to mysql
Hi Victor, Just Tables and Data. Ideally scripted to create the tables and insert the data. will sql2000 product something similer to a .sql file which can simple be run as a script? Thx At 12:45 PM 24/08/2004, Victor Pendleton wrote: Are you wanting to move Foreign keys, Triggers, Stored procedures and the like as well or just the data? -Original Message- From: Tim Winters To: [EMAIL PROTECTED] Sent: 8/24/04 10:36 AM Subject: sql2000 to mysql Hello, Can someone advise me of the best/easiest way to move an entire DB (Tables and data) from sql2000 (my client) to mySQL (my System)? I need to advise someone on how I wish the data sent to me. Any help would be appreciated. Thanks, Tim -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: sql2000 to mysql
You can try SQLyog's ODBC Import feature. SQLyog can be found at http://www.webyog.com Regards Karam --- Tim Winters [EMAIL PROTECTED] wrote: Hi Victor, Just Tables and Data. Ideally scripted to create the tables and insert the data. will sql2000 product something similer to a .sql file which can simple be run as a script? Thx At 12:45 PM 24/08/2004, Victor Pendleton wrote: Are you wanting to move Foreign keys, Triggers, Stored procedures and the like as well or just the data? -Original Message- From: Tim Winters To: [EMAIL PROTECTED] Sent: 8/24/04 10:36 AM Subject: sql2000 to mysql Hello, Can someone advise me of the best/easiest way to move an entire DB (Tables and data) from sql2000 (my client) to mySQL (my System)? I need to advise someone on how I wish the data sent to me. Any help would be appreciated. Thanks, Tim -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: sql2000 to mysql
If you have DTS you can export the data to a CSV format. If you have MyODBC installed you could export directly to MySQL. -Original Message- From: Tim Winters To: Victor Pendleton; '[EMAIL PROTECTED] ' Sent: 8/24/04 11:34 AM Subject: RE: sql2000 to mysql Hi Victor, Just Tables and Data. Ideally scripted to create the tables and insert the data. will sql2000 product something similer to a .sql file which can simple be run as a script? Thx At 12:45 PM 24/08/2004, Victor Pendleton wrote: Are you wanting to move Foreign keys, Triggers, Stored procedures and the like as well or just the data? -Original Message- From: Tim Winters To: [EMAIL PROTECTED] Sent: 8/24/04 10:36 AM Subject: sql2000 to mysql Hello, Can someone advise me of the best/easiest way to move an entire DB (Tables and data) from sql2000 (my client) to mySQL (my System)? I need to advise someone on how I wish the data sent to me. Any help would be appreciated. Thanks, Tim -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
Hi Peter, * Assuming that my points below regarding performance are correct (I'm sure that Heikki will stand by InnoDB and back up anyone preaching it's performance benefits), the lower hardware costs are an important factor (as in lower for a given performance target). Note: when using InnoDB in 24x7 environments, you need to purchase an additional hot-backup tool to do your backups. Not expensive at all though. Martin, This is not exactly the case. There are several ways to get Innodb hot and consistent backup. Commercial Innodb Hot Backup tool by Innobase Oy is the easiest to use and fastest. Alternatively you can use LVM (or similar tool) to get the consist read only snapshot and use it as backup or use mysqldump --single-transaction to get consistent text backup. As Innob has versioning these selects will not lock anything. Interesting - thanks for setting me straight here. With regards, Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL MS SQL Server. Upscene Productions http://www.upscene.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
Chris Nolan wrote: Martijn Tonies wrote: Additionally, it is an accepted fact that MySQL is faster than the mighty, mighty PostgreSQL. No, it is not. It is an accepted fact that MySQL is faster than PostgreSQL for certain tasks. The PostgreSQL developers say that they are faster than most commercial databases in their normal fsync mode. GreatBridge LLC claimed their PostgreSQL version was faster than most commercial databases, in their specific benchmark. I am not aware of any such claims from the current PGDG. But there are a few gripes I have with comparing databases on just performance: - Performance data is not portable. You can't say that just because one database is faster in one case, it will be faster in another case too. - Performance is overrated. For most applications, there is some treshhold after which a database is 'fast enough'. I don't care if I can serve 1200 or 1201 customers, if I only have 20 and grow at a rate slower than Moore's Law. - In most cases, you are not measuring database performance, but DBA performance or developer performance. I can think of a few others: - stored procedures (not finished with MySQL) - triggers (not even on the roadmap with MySQL?) - check constraints (please, Heiki?!) I'm a constraint-freak, if you like. I want my database to check the data. In all sorts of possible ways... Triggers are slated for the 5.1 timeframe, along with FK constraints for all table types (including BDB?). Check constraints have beem discussed in various presentations (at the 2003 MySQL conference, they were mentioned specifically with regard to MySQL's compliance to SQL92 and SQL:1999). I expect them in the 5.1 timeframe too, since you can implement check constraints in triggers. But the question remains if we can expect a stable 5.1 before 2006. Jochem -- I don't get it immigrants don't work and steal our jobs - Loesje -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
Additionally, it is an accepted fact that MySQL is faster than the mighty, mighty PostgreSQL. It is an accepted fact that PostgreSQL developers don't lie. The PostgreSQL developers say that they are faster than most commercial databases in their normal fsync mode. Therefore, by communicativity of implication, MySQL is faster than most (if not all) commercial databases. I do have to agree with Jochem here -- I would certainly sacrifice speed, regarding some issues. And time-to-market is important as well. Remember no FKs with MySQL? cause you can do that in your application... ahum. I think that your (one of) statement is not needed - InterBase seems to have been the first, with Oracle coming along later and thinking This thing is so funky! Quick, we must build one!. At the moment though, I can only name the following 5 multiversioned engines: MySQL/InnoDB, PostgreSQL, Oracle, Firebird, Interbase Do you have any others to add? ThinkSQL ( www.thinksql.co.uk ) and I believe MimerSQL as well ( www.mimer.com ) but I'm not sure. Then there are a lot of smaller db engines that use the same technique. And of course the storage engine inside www.netfrastructure.com - also created by the original creator of InterBase. But it's more refined and faster - obviously, the effect of modern hardware and less worries about memory etc... Mimer seems to have a fair bit in common with MS SQL Server. Not really. In some ways, they're more advanced - at least, more SQL whateverthelatestspecis compliant. In others, they're a bit lacking. Visual tools, for example ;-) For instance, one of their big features is Optimistic Conflict Control. They do claim non-locking transaction control though. I haven't looked at it thorougly yet. Yukon definitely won't be I do believe Yukon get's a snapshot transaction isolation - any word on how they are going to implement this? In an amazingly dodgy manner? Given the amount of time they've been working on it, I'd say we're either going to see something entirely new (mutliversioning perhaps) or something bolted on to the old model that's just taking forever to implement and debug. *g* ... still, I'm interested to see how they pulled it off ... either way, they will probably say that multi-versioning is something very new!! And that MS has figured it out!! (kinda like they did with, well, everything else) Admittedly, I haven't read through the licence, but the assurances you get on the licence document are a lot more comforting than the If SQL Server 2000 shaves your cat, it's not our problem. If SQL Server 2000 shaves your neighbour's cat due to you installing a device with terrible drivers, you'll pay our court costs when we get sued. Don't forget the you can use this software whereever you like except in true critical areas clauses... And the You will not do compatibility testing! Documents relating to this are available! Make do with those!!! clause. :-D Aren't licenses great... (don't check mine) 8. MS SQL's additional tools may be of interest to you (see MS's product page, particularly their product comparison page for the number of nice things included with SQL Server). The vast majority of this stuff exists for MySQL as well though, you will have to get your hands on it seperately though. no comment. I should have really mentioned that MS SQL Server comes with a hot backup tool, an added extra for MySQL. That said, there are alternatives to MS's tool that make backups a lot more managable and scriptable. I bet one of the reasons why there are so many MSSQL tools is that where there's MSSQL, there's money. No offence, but from what I see sometimes in open source worlds (I had this with Firebird too) is that I - as a tool vendor - get questions like you create a tool for an open source product and you're asking MONEY for it? tss tss... Well, bread, table and so on :-) Which miserable sod would question your right to charge cash for your tools? Oh, believe me - it happened. More than once, actually. Needless to say, I'll just continue making tools and earning money for it... Nothing is stopping them from creating a free alternative and your contribution to the free software world in other ways is quite notable. The fact that you even support the big open source databases is an excellent push for funky software that comes with source code!! I also know of several of these initatives saying I can do that and become a total failure afterwards when they find out it's actually quite (ahum) a bit of work ;-) Obviously true. Except for the license price of MS SQL - there's always the how to get a discount guide :-D For anyone reading this message, allow me to sumarise the document that Martijn has pointed out above. Have a 3 hour conversation with an MS Sales rep at your office and mention all of the following terms: --8-- snipped secret document part :-) woohoo, darn, there goes the
Re: SQL2000 and MySql
On Wed, 2004-02-11 at 22:29, Jochem van Dieten wrote: Chris Nolan wrote: Martijn Tonies wrote: Additionally, it is an accepted fact that MySQL is faster than the mighty, mighty PostgreSQL. No, it is not. It is an accepted fact that MySQL is faster than PostgreSQL for certain tasks. You're totally correct. I should have qualified my statement. As I mentioned earlier in this thread, I'm hanging out for new performance data on recent releases on the open source databases currently available, particularly for Firebird 1.5 and 2.0 (when each is released as stable) and PostgreSQL 7.4 (considering some of the excellent optimiser enhancements). As I also mentioned, it's a terrible shame that the big three all require written permission for you to actually publish benchmark information in most cases. This is completely stupid, and gives people like me a few less means of engaging in discussions like this. The PostgreSQL developers say that they are faster than most commercial databases in their normal fsync mode. GreatBridge LLC claimed their PostgreSQL version was faster than most commercial databases, in their specific benchmark. I am not aware of any such claims from the current PGDG. But there are a few gripes I have with comparing databases on just performance: - Performance data is not portable. You can't say that just because one database is faster in one case, it will be faster in another case too. - Performance is overrated. For most applications, there is some treshhold after which a database is 'fast enough'. I don't care if I can serve 1200 or 1201 customers, if I only have 20 and grow at a rate slower than Moore's Law. - In most cases, you are not measuring database performance, but DBA performance or developer performance. Your last point above couldn't be more true. Thankfully, both MySQL and PostgreSQL have well developed APIs in a selection of languages. I'd dare say PostgreSQL has a slight advantage for some programs due to it's asynchronous query interface option and MySQL has the option of being embedded into your app for additional performance. I can think of a few others: - stored procedures (not finished with MySQL) - triggers (not even on the roadmap with MySQL?) - check constraints (please, Heiki?!) I'm a constraint-freak, if you like. I want my database to check the data. In all sorts of possible ways... Triggers are slated for the 5.1 timeframe, along with FK constraints for all table types (including BDB?). Check constraints have beem discussed in various presentations (at the 2003 MySQL conference, they were mentioned specifically with regard to MySQL's compliance to SQL92 and SQL:1999). I expect them in the 5.1 timeframe too, since you can implement check constraints in triggers. But the question remains if we can expect a stable 5.1 before 2006. Looking at 4.1's development cycle, it seems time between releases has contracted slighlty compared to 3.23 and 4.0. One must wonder about the impact of resources being devoted to the upkeep of 4.0, the stablisation of 4.1 and the development of 5.0 all at once though. Heikki would be the person to ask, as everyone knows of that the creator of InnoDB makes a hobby out of predicting relase dates for MySQL releases. Hopefully, we'll have PostgreSQL-style check constraints that are simply declared at table creation time and hopefully we'll also get PostgreSQL-style DEFAULT specification options instead of expressions that have to be evaluated statically at table creation. Jochem -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
On Feb 10, 2004, at 9:12 AM, Chris Nolan wrote: 12. MySQL AB weren't responsible for afflicting the world with the Jet database engine (Access) or Visual FoxPro, thus they are more trustworthy than MS! :-) Microsoft *bought* FoxPro; they didn't develop the database engine. FWIW, it is one of the fastest engines for local manipulation of data. I frequently use Visual FoxPro to grab data from a MySQL database, make the updates locally, and then pump the changes back. VFP rocks with MySQL! ___/ / __/ / / Ed Leafe http://leafe.com/ http://opentech.leafe.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
Yes, we all know that Microsoft *bought* FoxPro's underlaying technology, that is *FoxBASE*! Everything ever called FoxPro has been a Microsoft product. Agreed that FoxPro's xBase implementation is quite quick, but the fact that it's pushed as a high-performance multi-user engine is a bit of an insult. If one more of my clients calls me saying Help! Our medical management software won't start! Help! and it turns out that a reindex was attempted while someone was busy inserting pictures of fresh incissions I'll be very annoyed (and charging accordingly). Regards, Chris Ed Leafe wrote: On Feb 10, 2004, at 9:12 AM, Chris Nolan wrote: 12. MySQL AB weren't responsible for afflicting the world with the Jet database engine (Access) or Visual FoxPro, thus they are more trustworthy than MS! :-) Microsoft *bought* FoxPro; they didn't develop the database engine. FWIW, it is one of the fastest engines for local manipulation of data. I frequently use Visual FoxPro to grab data from a MySQL database, make the updates locally, and then pump the changes back. VFP rocks with MySQL! ___/ / __/ / / Ed Leafe http://leafe.com/ http://opentech.leafe.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
On Feb 11, 2004, at 7:31 PM, Chris Nolan wrote: Yes, we all know that Microsoft *bought* FoxPro's underlaying technology, that is *FoxBASE*! Everything ever called FoxPro has been a Microsoft product. Sorry, you're off by a few years. FoxPro had been out for several years before Microsoft bought Fox Software. All of the *Visual* FoxPro releases have been by Microsoft, though. I'm sure you're not familiar with it at all (Microsoft tries so hard to keep it a secret), but Visual FoxPro is a powerful object-oriented development system that can handle all 3 tiers of a typical 3-tier app design. Granted, the data store part of it is lame compared to a real RDBMS, but it is more than sufficient for many apps. Agreed that FoxPro's xBase implementation is quite quick, but the fact that it's pushed as a high-performance multi-user engine is a bit of an insult. If one more of my clients calls me saying Help! Our medical management software won't start! Help! and it turns out that a reindex was attempted while someone was busy inserting pictures of fresh incissions I'll be very annoyed (and charging accordingly). Well, I'm sure that I could write some equally horrible scenario using *any* system out there. And I've seen tons of crap in all languages on all platforms. Done intelligently, though, a Visual FoxPro app that uses VFP for the GUI and business logic, and which uses MySQL as the back end, is an incredibly powerful combination. I haven't done VFP development that uses Xbase-type tables in years. You'll never hear about it from Microsoft, though, because they'd rather sell you the full Visual Studio package along with a bunch of Microsoft SQL Server licenses. As an aside, the VFP community has never really integrated into the whole Microsoft way of doing things. There is a large group of developers who develop business apps for Windows desktops in VFP, and use MySQL on Linux servers for the data. At a recent VFP conference, a session on using MySQL was packed. ___/ / __/ / / Ed Leafe http://leafe.com/ http://opentech.leafe.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
Ed Leafe wrote: On Feb 11, 2004, at 7:31 PM, Chris Nolan wrote: Yes, we all know that Microsoft *bought* FoxPro's underlaying technology, that is *FoxBASE*! Everything ever called FoxPro has been a Microsoft product. Sorry, you're off by a few years. FoxPro had been out for several years before Microsoft bought Fox Software. All of the *Visual* FoxPro releases have been by Microsoft, though. I'm sure you're not familiar with it at all (Microsoft tries so hard to keep it a secret), but Visual FoxPro is a powerful object-oriented development system that can handle all 3 tiers of a typical 3-tier app design. Granted, the data store part of it is lame compared to a real RDBMS, but it is more than sufficient for many apps. Well, the miserable sod that has that history up mentioning the product FoxBASE 2.0 has incurred my wrath. I will ensure that their OS options from now on are limited to the awful kludges that are OpenServer and UnixWare. I've done some FoxPro stuff in the past, but have found that there are ways more suitable to my needs for developing database-driven solutions. The multi-platform aspects of Java, PHP and C++ with wxWindows are just a few examples. Agreed that FoxPro's xBase implementation is quite quick, but the fact that it's pushed as a high-performance multi-user engine is a bit of an insult. If one more of my clients calls me saying Help! Our medical management software won't start! Help! and it turns out that a reindex was attempted while someone was busy inserting pictures of fresh incissions I'll be very annoyed (and charging accordingly). Well, I'm sure that I could write some equally horrible scenario using *any* system out there. And I've seen tons of crap in all languages on all platforms. I don't know if you could hope to match the horrible mess I'm referring to above with anything other than Jet. Seriously, the person who deployed this software needs to have a few things done to them. Interestingly, it's a FoxPro 2.6-based app. Done intelligently, though, a Visual FoxPro app that uses VFP for the GUI and business logic, and which uses MySQL as the back end, is an incredibly powerful combination. I haven't done VFP development that uses Xbase-type tables in years. You'll never hear about it from Microsoft, though, because they'd rather sell you the full Visual Studio package along with a bunch of Microsoft SQL Server licenses. Out of curiosity, have you ever migrated an application built using FP or VFP along with XBase-type tables to MySQL? There's a developer I know who would be interested in doing so and is looking for some advice if you're interested. As an aside, the VFP community has never really integrated into the whole Microsoft way of doing things. There is a large group of developers who develop business apps for Windows desktops in VFP, and use MySQL on Linux servers for the data. At a recent VFP conference, a session on using MySQL was packed. There's been a few threads on this list in the past regarding the difficulty in matching VFP's native datastore performance when using MySQL (mainly due to VFP's Rushmore optimisation engine). Have you experienced this problem to any degree? ___/ / __/ / / Ed Leafe http://leafe.com/ http://opentech.leafe.com Regards, Chris -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
On Feb 11, 2004, at 9:31 PM, Chris Nolan wrote: Done intelligently, though, a Visual FoxPro app that uses VFP for the GUI and business logic, and which uses MySQL as the back end, is an incredibly powerful combination. I haven't done VFP development that uses Xbase-type tables in years. You'll never hear about it from Microsoft, though, because they'd rather sell you the full Visual Studio package along with a bunch of Microsoft SQL Server licenses. Out of curiosity, have you ever migrated an application built using FP or VFP along with XBase-type tables to MySQL? There's a developer I know who would be interested in doing so and is looking for some advice if you're interested. Yes, I've done several. The level of difficulty depends on how well-designed the app was in the first place. If they used lots of the ancient Xbase commands to access data, it will be pretty much a complete re-write. However, if they used any sort of data classes, or if they used buffered SQL views instead of direct tables access, it can be converted without too much pain. As an aside, the VFP community has never really integrated into the whole Microsoft way of doing things. There is a large group of developers who develop business apps for Windows desktops in VFP, and use MySQL on Linux servers for the data. At a recent VFP conference, a session on using MySQL was packed. There's been a few threads on this list in the past regarding the difficulty in matching VFP's native datastore performance when using MySQL (mainly due to VFP's Rushmore optimisation engine). Have you experienced this problem to any degree? In many cases, there is nothing faster than the VFP data engine. It never ceases to amaze me how wicked fast it is with properly designed indexes. But there are few businesses today that can afford to keep their data in a data store with no security. With Xbase tables, if you have access to them at all, you have full access - there is no concept of levels of security. None of my clients would dream of trading the security and scalability of MySQL for a couple of milliseconds of improved performance. ___/ / __/ / / Ed Leafe http://leafe.com/ http://opentech.leafe.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
Hmmfor practical purposes: 1. MySQL is going to cost you a lot less, no matter which way you do things. 2. MySQL is going to perform better for the vast majority of workloads. The only place where MS SQL Server *might* have an advantage is in situations where it's additional language features are able to do things that you would need to do in your application should you use MySQL (and comparisons in this area in the past by many people have still shown MySQL to have a speed edge). 3. MySQL's primary (BDB fans, please don't flame me) transactional table type is the fastest transactional storage engine on the planet, has an option for proper binary backups and has very quick and automatic recovery, regardless of how ugly a crash is. MS SQL's old-style non-multiversioned system can be problematic in this regard in some rare cases. 4. ALTER TABLE statements in both products (currently at least) will result in a SHARED LOCK being placed on the table in question. Yukon (SQL Server 2003) will remove this limitation though. 5. MySQL has one of the most active communities of any database product. Getting help isn't a problem on this mailing list - it's more a question of getting people to stop giving you help. 6. MySQL's commercial licence is quite nice for businesses as there are written assurances regarding the software's capabilities. 7. BIG ARGUMENT: MySQL is multi-platform and quite platform agnostic. Migrating between architectures and/or operating systems is a non-issue. With SQL Server, you're stuck with either of the pathetic excuses for server OSes, Windows 2000 Server or Windows 2003 Server. 8. MS SQL's additional tools may be of interest to you (see MS's product page, particularly their product comparison page for the number of nice things included with SQL Server). The vast majority of this stuff exists for MySQL as well though, you will have to get your hands on it seperately though. 9. The general opinion in industry is that MS SQL Server's replication capabilities are not ready for prime-time. MySQL's replication capabilities are very solid. 10. With MySQL, it's easy to get support for it from the people who actually wrote it. If there's a feature that you desperately need and you're willing to pay for it (and paying for it equates to about the same as buying a decent MS SQL Server setup), they may very well be able to help you out! 11. If you change your mind later, migrating from MySQL to another database engine is a well-travelled path with utilities and full-blown product offers all over the place. 12. MySQL AB weren't responsible for afflicting the world with the Jet database engine (Access) or Visual FoxPro, thus they are more trustworthy than MS! :-) 13. You'll have my eternal gratitude if you use MySQL over MS SQL Server...I'll send you a postcard. Regards, Chris Martijn Tonies wrote: Hi, I have a software of insurance to do quotations directly on the web. It uses a SQL 2000 database and I want to use MYSQL database. Do you think it is possible ? That depends on the requirements, doesn't it. What do you use in your MS SQL 2000 database? For example, MySQL doesn't have triggers and stored procedures. (please reply to the MySQL list only, not to me personally) With regards, Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL MS SQL Server. Upscene Productions http://www.upscene.com Does somebody can explain the technical difference beetwen SQL2000 and MySQL In exactly what area? In short: MS SQL 2000 is more advanced, has more build in stuff, is more expensive, most probably has more security leaks :-) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
Hi Chris, I understand that you like MySQL but ... Hmmfor practical purposes: 1. MySQL is going to cost you a lot less, no matter which way you do things. This is a pretty bold statement. Can you back this argument with some references regarding TCO and development time for a particular project? Obviously, there's more than just licensing costs. As a personal note: at a company we started a few years ago, we actively select Linux as the server OS and Firebird as our primary database simply because of the licensing costs we couldn't afford then, but we did have the spare time for learning the more advanced Linux stuff (to our minds, that is) and the somewhat less catered for UI in Linux. Mind you: things are getting better in the Linux world :-) 2. MySQL is going to perform better for the vast majority of workloads. The only place where MS SQL Server *might* have an advantage is in situations where it's additional language features are able to do things that you would need to do in your application should you use MySQL (and comparisons in this area in the past by many people have still shown MySQL to have a speed edge). Despite comparisons: still a pretty bold statement. There are plenty of comparisons out there that don't say anything at all. Heck, the whole we can do this many transactions per second if we use 64 CPUs, this many drives etc etc on a clustering system is total hogwash, both you and me know that. It's just the sales people who are out of luck there ;-) 3. MySQL's primary (BDB fans, please don't flame me) transactional table type is the fastest transactional storage engine on the planet, has an option for proper binary backups and has very quick and automatic recovery, regardless of how ugly a crash is. MS SQL's old-style non-multiversioned system can be problematic in this regard in some rare cases. Multi-versioning - in my eyes - is the future when it comes to databases with regard to concurrency (MS SQL has row locks!). Nice to read that more and more database engines are using this MV instead of locks. Obviously, InterBase was (one of?) the first about 20 yrs ago. And yes, it certainly can help when stuff crashes. And it makes development easier as well. In short: good argument. 4. ALTER TABLE statements in both products (currently at least) will result in a SHARED LOCK being placed on the table in question. Yukon (SQL Server 2003) will remove this limitation though. no comment. 5. MySQL has one of the most active communities of any database product. Getting help isn't a problem on this mailing list - it's more a question of getting people to stop giving you help. MS SQL has an active community as well. Whenever I needed to know something, I got my answers, although I didn't always like them :-) 6. MySQL's commercial licence is quite nice for businesses as there are written assurances regarding the software's capabilities. no comment. 7. BIG ARGUMENT: MySQL is multi-platform and quite platform agnostic. Migrating between architectures and/or operating systems is a non-issue. With SQL Server, you're stuck with either of the pathetic excuses for server OSes, Windows 2000 Server or Windows 2003 Server. Win2K and 2K3 have become much better than the previous NT4. Nevertheless, being able to use a database engine on your favourite OS of choice, is, in my eyes, a pro-argument. 8. MS SQL's additional tools may be of interest to you (see MS's product page, particularly their product comparison page for the number of nice things included with SQL Server). The vast majority of this stuff exists for MySQL as well though, you will have to get your hands on it seperately though. no comment. 9. The general opinion in industry is that MS SQL Server's replication capabilities are not ready for prime-time. MySQL's replication capabilities are very solid. I cannot comment on the state of the MS SQL replication stuff. 10. With MySQL, it's easy to get support for it from the people who actually wrote it. If there's a feature that you desperately need and you're willing to pay for it (and paying for it equates to about the same as buying a decent MS SQL Server setup), they may very well be able to help you out! Obviously true. Except for the license price of MS SQL - there's always the how to get a discount guide :-D 11. If you change your mind later, migrating from MySQL to another database engine is a well-travelled path with utilities and full-blown product offers all over the place. Hmm. In your eyes, why would someone do that? ;-) Of course, there are some catches when it comes to MySQL. 12. MySQL AB weren't responsible for afflicting the world with the Jet database engine (Access) or Visual FoxPro, thus they are more trustworthy than MS! :-) *g* 13. You'll have my eternal gratitude if you use MySQL over MS SQL Server...I'll send you a postcard. Send beer instead... *g* With regards, Martijn Tonies Database Workbench -
Re: SQL2000 and MySql
Hi Chris, It seems that whenever we both comment in a thread, you enlighten me greatly! ;-) ... I'm learning more about MySQL with every post. Ok, maybe not every post, but still ... *g* I tend to be a critic sometimes, but I'm a really nice guy. Believe me on this one ;-) 1. MySQL is going to cost you a lot less, no matter which way you do things. This is a pretty bold statement. Can you back this argument with some references regarding TCO and development time for a particular project? Obviously, there's more than just licensing costs. The TCO paper on the MySQL site would be one of my primary points of reference. Ah, good. Mentioning this the first time in your statement would have pointed people to the right document in the first place. There are several points that would be hard to argue against though: * MS SQL Server has 3 licencing models - per processor, per user or per device. Either you can pay lots now and only pay a lot more if you decide you need more CPUs or take a gamble / educated guest about how many things you need to plug into it. Not having to worry about these factors is nice and the argument that you are able to use the software irrespective of upgrades, increased user numbers or more connecting devices is also very supporting of the above statement. * History has shown that applying patches to MS SQL Server is a process ranging from quite pleasant to quite painful (remember the initial Slammer patchset?). MySQL's upgrades are quite seamless by comparison, and I dare say are trivial to rollback. Downtime is one of the most often ignored factors in ROI and TCO studies. * MySQL training and certification is available and my research shows that MySQL AB are very reasonable with the charges associated with that service. * Assuming that my points below regarding performance are correct (I'm sure that Heikki will stand by InnoDB and back up anyone preaching it's performance benefits), the lower hardware costs are an important factor (as in lower for a given performance target). Note: when using InnoDB in 24x7 environments, you need to purchase an additional hot-backup tool to do your backups. Not expensive at all though. * Clustering packages are available for MySQL currently, but I can't figure out where on earth to look for them. I can say that MySQL AB are going to be demonstrating their clustering solution at the upcoming expo - let's hope it's under the same licence as all these other nice toys that come out of MySQL AB. As a personal note: at a company we started a few years ago, we actively select Linux as the server OS and Firebird as our primary database simply because of the licensing costs we couldn't afford then, but we did have the spare time for learning the more advanced Linux stuff (to our minds, that is) and the somewhat less catered for UI in Linux. Mind you: things are getting better in the Linux world :-) Things are getting better, but I often make an argument for having a higher entry barrier for technical people due to the large number of Windows experts who don't even know who Dave Cutler is. Either way, it's all good! As someone who uses Windows all day long and likes to argue with Unix/Linux techies: I really like the clickety-click stuff. But I do agree with your remark about the so-called experts. 2. MySQL is going to perform better for the vast majority of workloads. The only place where MS SQL Server *might* have an advantage is in situations where it's additional language features are able to do things that you would need to do in your application should you use MySQL (and comparisons in this area in the past by many people have still shown MySQL to have a speed edge). Despite comparisons: still a pretty bold statement. There are plenty of comparisons out there that don't say anything at all. Heck, the whole we can do this many transactions per second if we use 64 CPUs, this many drives etc etc on a clustering system is total hogwash, both you and me know that. It's just the sales people who are out of luck there ;-) Indeed! The fact that you need to marry the child of someone high up at any of the big three before you can publish benchmarks of their products *g* without getting into a lot of trouble doesn't help matters at all! I'm hoping that the new benchmarks page at MySQL's site will be up soon though, saving me from thinking too hard on this point. 3. MySQL's primary (BDB fans, please don't flame me) transactional table type is the fastest transactional storage engine on the planet, has an option for proper binary backups and has very quick and automatic recovery, regardless of how ugly a crash is. MS SQL's old-style non-multiversioned system can be problematic in this regard in some rare cases. Multi-versioning - in my eyes - is the future when it comes to databases with regard to concurrency (MS SQL has row locks!). Nice to read that more and more database
Re: SQL2000 and MySql
On Tue, 2004-02-10 at 08:38, Martijn Tonies wrote: * Assuming that my points below regarding performance are correct (I'm sure that Heikki will stand by InnoDB and back up anyone preaching it's performance benefits), the lower hardware costs are an important factor (as in lower for a given performance target). Note: when using InnoDB in 24x7 environments, you need to purchase an additional hot-backup tool to do your backups. Not expensive at all though. Martin, This is not exactly the case. There are several ways to get Innodb hot and consistent backup. Commercial Innodb Hot Backup tool by Innobase Oy is the easiest to use and fastest. Alternatively you can use LVM (or similar tool) to get the consist read only snapshot and use it as backup or use mysqldump --single-transaction to get consistent text backup. As Innob has versioning these selects will not lock anything. -- Peter Zaitsev, Senior Support Engineer MySQL AB, www.mysql.com Meet the MySQL Team at User Conference 2004! (April 14-16, Orlando,FL) http://www.mysql.com/uc2004/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
Martijn Tonies wrote: Hi Chris, It seems that whenever we both comment in a thread, you enlighten me greatly! ;-) ... I'm learning more about MySQL with every post. Ok, maybe not every post, but still ... *g* I tend to be a critic sometimes, but I'm a really nice guy. Believe me on this one ;-) You have to have critics, otherwise myths get propogated everywhere!! 1. MySQL is going to cost you a lot less, no matter which way you do things. This is a pretty bold statement. Can you back this argument with some references regarding TCO and development time for a particular project? Obviously, there's more than just licensing costs. The TCO paper on the MySQL site would be one of my primary points of reference. Ah, good. Mentioning this the first time in your statement would have pointed people to the right document in the first place. Yes, but that would have required some actual thought on my part. :-) There are several points that would be hard to argue against though: * MS SQL Server has 3 licencing models - per processor, per user or per device. Either you can pay lots now and only pay a lot more if you decide you need more CPUs or take a gamble / educated guest about how many things you need to plug into it. Not having to worry about these factors is nice and the argument that you are able to use the software irrespective of upgrades, increased user numbers or more connecting devices is also very supporting of the above statement. * History has shown that applying patches to MS SQL Server is a process ranging from quite pleasant to quite painful (remember the initial Slammer patchset?). MySQL's upgrades are quite seamless by comparison, and I dare say are trivial to rollback. Downtime is one of the most often ignored factors in ROI and TCO studies. * MySQL training and certification is available and my research shows that MySQL AB are very reasonable with the charges associated with that service. * Assuming that my points below regarding performance are correct (I'm sure that Heikki will stand by InnoDB and back up anyone preaching it's performance benefits), the lower hardware costs are an important factor (as in lower for a given performance target). Note: when using InnoDB in 24x7 environments, you need to purchase an additional hot-backup tool to do your backups. Not expensive at all though. Not expensive doesn't do justice to the excellent value proposition that InnoDB Hot Backup is. * Clustering packages are available for MySQL currently, but I can't figure out where on earth to look for them. I can say that MySQL AB are going to be demonstrating their clustering solution at the upcoming expo - let's hope it's under the same licence as all these other nice toys that come out of MySQL AB. As a personal note: at a company we started a few years ago, we actively select Linux as the server OS and Firebird as our primary database simply because of the licensing costs we couldn't afford then, but we did have the spare time for learning the more advanced Linux stuff (to our minds, that is) and the somewhat less catered for UI in Linux. Mind you: things are getting better in the Linux world :-) Things are getting better, but I often make an argument for having a higher entry barrier for technical people due to the large number of Windows experts who don't even know who Dave Cutler is. Either way, it's all good! As someone who uses Windows all day long and likes to argue with Unix/Linux techies: I really like the clickety-click stuff. But I do agree with your remark about the so-called experts. The rate that KDE and GNOME are advancing at reminds me of the landscape a few years ago, when usability experts said that Windows and MacOS were starting to reach parity in terms of usability. Hopefully the open source world won't just settle for parity (they're way ahead in many ways in my opinion). 2. MySQL is going to perform better for the vast majority of workloads. The only place where MS SQL Server *might* have an advantage is in situations where it's additional language features are able to do things that you would need to do in your application should you use MySQL (and comparisons in this area in the past by many people have still shown MySQL to have a speed edge). Despite comparisons: still a pretty bold statement. There are plenty of comparisons out there that don't say anything at all. Heck, the whole we can do this many transactions per second if we use 64 CPUs, this many drives etc etc on a clustering system is total hogwash, both you and me know that. It's just the sales people who are out of luck there ;-) Indeed! The fact that you need to marry the child of someone high up at any of the big three before you can publish benchmarks of their products *g* Additionally, it is an accepted fact that MySQL is faster than the mighty, mighty PostgreSQL. It is an accepted fact that PostgreSQL developers
SQL2000 and MySql
Does somebody can explain the technical difference beetwen SQL2000 and MySQL Thks a lot Bertrand -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
Hi, Does somebody can explain the technical difference beetwen SQL2000 and MySQL In exactly what area? In short: MS SQL 2000 is more advanced, has more build in stuff, is more expensive, most probably has more security leaks :-) With regards, Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL MS SQL Server. Upscene Productions http://www.upscene.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
And then there's the whole opensource thing :) Your platform focus depends a lot on it too. If you're a MS shop, I'd imagine SQL would be the way to go. All the fancy MS integration stuff is there. Connecting to it from other OS's is generally done with ODBC. ODBC is pretty stinky as it's an abbreviated syntax in most senses. There are probably a thousand points one can make to differ the two. 'Technically' (and broadly) they are the same thing. 'Practically' you'd need to figure out the other parts of the solution before honing in on a choice. -Martijn Tonies [EMAIL PROTECTED] wrote: - To: [EMAIL PROTECTED] From: Martijn Tonies [EMAIL PROTECTED] Date: 02/09/2004 12:16PM Subject: Re: SQL2000 and MySql Hi, Does somebody can explain the technical difference beetwen SQL2000 and MySQL In exactly what area? In short: MS SQL 2000 is more advanced, has more build in stuff, is more expensive, most probably has more security leaks :-) With regards, Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL MS SQL Server. Upscene Productions http://www.upscene.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL2000 and MySql
Hi, I have a software of insurance to do quotations directly on the web. It uses a SQL 2000 database and I want to use MYSQL database. Do you think it is possible ? That depends on the requirements, doesn't it. What do you use in your MS SQL 2000 database? For example, MySQL doesn't have triggers and stored procedures. (please reply to the MySQL list only, not to me personally) With regards, Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL MS SQL Server. Upscene Productions http://www.upscene.com Does somebody can explain the technical difference beetwen SQL2000 and MySQL In exactly what area? In short: MS SQL 2000 is more advanced, has more build in stuff, is more expensive, most probably has more security leaks :-) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
