MySQL VS SQL Server

I introduced our organization to SQL Server about 5 years
ago and we have created a lot of applications around it.
My management is beginning to think that maybe we should
be switching over to MySQL, primarily because of (CPU)
costs.
I am not for a switch and would rather stay in SQL
Server. Does anyone have any knowledge of what SQL Server
can do that MySQL cannot?
Thanks
Russ"Russ" <anonymous@.discussions.microsoft.com> wrote in message
news:041701c3a245$e182e180$a401280a@.phx.gbl...
> I introduced our organization to SQL Server about 5 years
> ago and we have created a lot of applications around it.
> My management is beginning to think that maybe we should
> be switching over to MySQL, primarily because of (CPU)
> costs.
> I am not for a switch and would rather stay in SQL
> Server. Does anyone have any knowledge of what SQL Server
> can do that MySQL cannot?
>
MySql is really not a comparable product to Sql Server.
SqlServer, like Oralce, DB2 and PostgreSQL is designed to be an enterprise
RDBMS server. This means that there is a server process which handles
management of the data, clients have no direct access to the data store. It
supports ACID transactions, online backup and recovery, declarative
referential integrity, etc.
MySql is an ISAM RDBMS. Architecturally MySql is more comparable to Access
or FoxPro than Sql Server. As such it is perfectly suitable for many
applications, but it is not designed to support large numbers of network
clients, and not a safe place to keep mission-critical enterprise data.
So if you are looking for a free alternative to Sql Server, you might check
out PostgreSQL instead.
David|||I have no idea how they compare on technical capabilities because I'm not
familiar with MySQL.
I would have thought that the biggest thing in SQLServer's favour (or not -
depending on your point-of-view!) is its dominance on the Windows platform.
The size and growth of its installed base means there is, and should be for
the forseeable future, a vast pool of IT professionals with SQLServer
skills, plus wide availability of support and third-party products.
But I would suggest you look objectively at which product makes sense for
your organisation without pre-conceived ideas. Maybe "they" are right. Why
not propose a technical evaluation of MySQL alongside SQLServer? That way
you get the chance to develop some skills in another product as well.
Hope this helps.
--
David Portas
--
Please reply only to the newsgroup
--|||"Russ" <anonymous@.discussions.microsoft.com> wrote:
>I introduced our organization to SQL Server about 5 years
>ago and we have created a lot of applications around it.
>My management is beginning to think that maybe we should
>be switching over to MySQL, primarily because of (CPU)
>costs.
>I am not for a switch and would rather stay in SQL
>Server. Does anyone have any knowledge of what SQL Server
>can do that MySQL cannot?
G'day Russ,
Hopefully you'll get some good performance and stability related answers
from others here.
From the perspective of a developer, I've found that MySQL does not yet
support two basic features that I rely on in my software designs.
Stored Procedures:
absolutely essential for partitioning the database code from the
application code, allowing better database management, simplified
deployment of database changes, and localisation of complex
multi-statement atomic actions at the server. Putting complex SQL code
into the client or middle tier is for rapid prototyping only, not robust
production systems, IMHO.
Column Constraints:
I don't like leaving things to chance, and trust the "application code"
to keep the data within the correct ranges. Being able to constrain the
values of a column is essential IMHO. I guess you could kludge this one
with foreign key constraints referencing lookup tables, but why when you
can just use a real RDBMS in the first place?
--
Ross McKay, WebAware Pty Ltd
"Words can only hurt if you try to read them. Don't play their game" - Zoolander|||"David Browne" wrote
> .
> SqlServer, like Oralce, DB2 and PostgreSQL is designed to be an enterprise
> RDBMS server. This means that there is a server process which handles
> management of the data, clients have no direct access to the data store.
It
> supports ACID transactions, online backup and recovery, declarative
> referential integrity, etc.
> .
I guess you forgot about:
'InnoDB is a MySQL table type which provides transactions, row-level
locking,
non-locking consistent SELECT (multiversioned concurrency control), foreign
key constraints, and a non-free hot backup tool for backing up InnoDB
tables.'
Since a stable MySql 4.x.x and a stable MaxDB will be available
way before a RTM of Yukon, I suggest you do some more homework.
The whole thrust of MySql AB is now toward the enterprise.Their goal
is to offer a commodity rdbm (with sql99) as an alternative to MS,IBM
and Oracle.Do you wish them luck? :~)|||"Zeppo" <nospam@.aol.com> wrote in message
news:OsLIJPuoDHA.2216@.TK2MSFTNGP12.phx.gbl...
> "David Browne" wrote
> > .
> > SqlServer, like Oralce, DB2 and PostgreSQL is designed to be an
enterprise
> > RDBMS server. This means that there is a server process which handles
> > management of the data, clients have no direct access to the data store.
> It
> > supports ACID transactions, online backup and recovery, declarative
> > referential integrity, etc.
> > .
> I guess you forgot about:
> 'InnoDB is a MySQL table type which provides transactions, row-level
> locking,
> non-locking consistent SELECT (multiversioned concurrency control),
foreign
> key constraints, and a non-free hot backup tool for backing up InnoDB
> tables.'
> Since a stable MySql 4.x.x and a stable MaxDB will be available
> way before a RTM of Yukon, I suggest you do some more homework.
> The whole thrust of MySql AB is now toward the enterprise.Their goal
> is to offer a commodity rdbm (with sql99) as an alternative to MS,IBM
> and Oracle.Do you wish them luck? :~)
>
I sure do. My impression, though, is that PostgreSQL is a lot farther down
the road already.
David|||On Tue, 4 Nov 2003 09:56:26 -0500, "Zeppo" <nospam@.aol.com> wrote:
>I guess you forgot about:
>'InnoDB is a MySQL table type which provides transactions, row-level
>locking,
>non-locking consistent SELECT (multiversioned concurrency control), foreign
>key constraints, and a non-free hot backup tool for backing up InnoDB
>tables.'
>Since a stable MySql 4.x.x and a stable MaxDB will be available
>way before a RTM of Yukon, I suggest you do some more homework.
>The whole thrust of MySql AB is now toward the enterprise.Their goal
>is to offer a commodity rdbm (with sql99) as an alternative to MS,IBM
>and Oracle.Do you wish them luck? :~)
I absolutely wish them luck, but the lack of SPs is still killer, and
what kind(s) of locking do they provide?
Have they learned to keep statistics and optimize queries, yet? Do
the transactions work, and what do they cost in performance? Have
they learned to do subqueries?
MySQL has been up to now a nice, fast, low-function product. It's a
whole different animal, competing with SQLServer. I'd love it if they
could do so, I'm happy when anybody can press Microsoft on any product
at the same or better price/value levels, but it's tough!
J.|||"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote
> I sure do. My impression, though, is that PostgreSQL is a lot farther
down
> the road already.
Yes, in many ways they are.(But I can't understand why they don't
have a native windows version:).But I believe in the short run they
will be eclipsed by a feature richer MySql/MaxDB.
As for a current snapshot Oracle and DB2 are much further down
the road than server:~).