Thread: MySQL or SQL Server
01-19-08, 14:46 #1Registered User
- Join Date
- Aug 2006
Unanswered: MySQL or SQL Server
Ok, so I'm thinking about trying to make my backend of the database converted from Access to MySQL or SQL Server.
I'm trying to figure out or get peoples opinions on what would be easier and why ? Like why would you use one over the other?
Keep in mind, this is in a business environment not home or anything.
01-19-08, 16:46 #2SQL Consultant
- Join Date
- Apr 2002
- Toronto, Canada
01-20-08, 00:27 #3Moderator
- Join Date
- Dec 2004
- Madison, WI
SQL Server express might be a good solution. Personally, I'd recommend SQL Server over MySQL. But I used an older version of MySQL and I didn't like the way it managed editing tables and backups (in the MySQL version I had, editing and creating tables was mostly done via creating code to do it.) I also liked the way SQL Server easily manages backups and permissions. I also found SQL Server very easy for creating stored procedures and triggers. It took me about 3 days to get the hang of MySQL and it took me about 3 hours to get the hang of SQL Server. The upsizing wizard also works very well for upsizing Access tables to SQL Server (I do this all the time.)
MySQL is noted as being extremely fast but I think coming from an Access background that you'll find SQL Server much easier to use for creating and managing tables.
Tough call but my vote would be for SQL Server. Either way, you can download each of them free and try them out.
Last edited by pkstormy; 01-20-08 at 00:31.Expert Database Programming
MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)
01-20-08, 16:55 #4www.gvee.co.uk
Provided Answers: 12
- Join Date
- Jan 2007
01-20-08, 17:26 #5Registered User
- Join Date
- Jul 2007
I would pick the best one for the project in hands. As Rudy said, porting access to MySql or SQL Server is the easiest part.
Could you provide us with more information about what the DB is going to handle, what kind of application(s) is going to be developed on top of it, number of estimated concurrent users, your company licencing plan (with Microsoft) if applied. Also it's important to know if your budget for this project can accomodate a SQL Server + Windows Server licence, in case it exceeds express edition limitations. If it doesn't then you have the answer just there
01-20-08, 17:46 #6Jaded Developer
Provided Answers: 59
- Join Date
- Nov 2004
- out on a limb
Although there are differences in the detail I don't think there are significant differences between most server productson the market. they all have their idiosyncracies, they all have their (well at least their marketing departments idea of) killer features.
Personally I'd discount (some) Pauls comments as they refer to older versions of MySQL. As I see it the version 5, and soon to be Version 6 are dramatic developments of the server to come close to existing mature server products.There is no doubt that the introduiction of version 4 was a huge step change, and many 'references' and 'experinces' you hear of date back to version 3.
Fundamentally it comes down to what your business needs, what it can afford and what it is familiar with.
If you are a Microsoft house then there is a lot to be said for staying within the Microsoft stable, there is much tighter integration of features, secuirty and user authentication is probably easier to implement in an all Microsofdt house. Mind you, because its easy to use SQL server tables in Access its also easy to design a Access app poorly, by not using unbound control, disconnected recordsets and so on.
I think one of the biggest bugbears in going done the MySQL route may be the paucity of really good capable MySQL DBA's and developers, something that SQL server and other products have in abundance. Thats all part of the so called 'total cost of ownership' marketing mumbo jumbo software vendors tend to talk about.
If your application is about marshalling large amounts of data, not a huge amount of transactional inserts or updates then without doubt MySQL is probably the performance contender. If you are in a data warehousing application then SQL server is almost certainly better. If you are in the transactional arena then probably SQL server is preferred, If its comfort zone then its a no brainer.. SQL server. If its corporate kudos, the SQL Server, Oracle, DB2.....
To many developers and IT Professionals (both real and self styled) MySQL isn't a real db, like Access isn't a real development tool.
I think you will find it easier to get a guru SQL server DBA to tune and tweak and maintain the db, I know that MySQL is also going down the certification route but generally speaking MySQL gigs don't attract the same money as SQL serve gigs so the better players may well go SQL server. Some of those issues can be resolved by taking out an enterprise license.. it means you are paying MySQL for support, it alters the costs but MySQL is still dramativcally cheaper. There are no more concerns about how many client licenses do we need to support this application..
if you are doing the development work yourself, in house then you will find more documentation, training and support in the SQL Server choice than MySQL. The documentation also tends to hang together better in SQL server, whereas the MysQL documentation is good, I don't think its as well though out as SQL server.
So its a tough choice
If its your job, and....
if its budget led.. I'd almost certainly go MySQL
if its not budget led, then FUD would rule the roost and I'd probably go SQL Server.
If its your business and you are happy taking on the technical risk then I might opt for MySQL, although FUD is still a mighty factor.
in some ways its a biut like talking to a lwayer... either choice is fine, assuming evrythign goes OK either choice is fine, if it turns to a crock of...... its probably going to be easier to rescue a crock of SQL Server than MySQL.
Of course the smart aleck response is probably to design your app so you can use either.. making sure that the db calls are in separate clases so if you need to move to another db engine it involves a rewrite of the db abstraction layer, not the presentation layer
sticking firmly on the fence... its over to you