Oracle hurls MySQL at Microsoft database wobblers Migration tools come and go in the turf wars between the enterprise vendors. Over the years we’ve had Lotus Notes and Microsoft Exchange migration tools and tools to swap one company’s database for another. Under the latter category, Oracle is now throwing open source at Microsoft in the form of a migration tool to shift …
What about Application Express for MySQL? I know Excel is not a database but people try to use it as one anyway because the standard version of MS Office doesn't include a proper one and because it's quite an easy way to generate quick charts and reports. It's all very well having a powerful database engine but it needs something a bit more user friendly than phpMyAdmin or an SQL prompt if people who aren't database programmers are going to use it. Same applies to SQL Server Express.
"....Oracle claimed MySQL would reduce total cost of ownership for database customers by up to 90 per cent when compared to Microsoft’s SQL Server 2012...." So I suppose it would generate a 180 percent saving if it did the same for Oracle DB to MySQL then? And will it allow me to export my M$ SQL database to Larry-free MariaDB?
"it would be much more fun for MS to release a tool to migrate Oracle users to MySQL :) or postgres :D"
The other hardware vendors have been pushing Oracle migration tools for a while:
http://www.theregister.co.uk/2011/07/05/enterprise_db_hp_ux/
http://www.redbooks.ibm.com/abstracts/sg247048.html
But it's the thrid parties that have done some interesting Oracle migrating tech:
http://www.convert-in.com/ora2sql.htm
http://wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL
It would be pretty hilarious if MS's response to Oracle is that they agree. MySQL is terrific and they would encourage Oracle DB users to consider the cost advantages of MySQL for the majority of their workloads which do not require RAC or Oracle's high end features... which would be a good portion of the Oracle install base.
"But it's the thrid parties that have done some interesting Oracle migrating tech"
It is exactly the same with ERP and Financial systems: SAP couldn't offer any tools to help a customer downsize from R3, however, third parties could offer tools and satisifed customers that enabled my client to downsize from R3 to their much more reasonably priced suites ...
It depends upon the application. I'm working with a medical practice management vendor who is moving from MS SQL to MySQL. They've reported to me that the move has gone perfectly including stored procedures and they're into testing with only three weeks development time. This is a particularly attractive venture when considering that Microsoft does not offer upgrade paths from existing SQL licenses. 55 users on SQL 2000 cost about $8,000 in the day (give or take) and "upgrading" those 55 users to SQL 2012 (with 2008 down-grade rights IF you purchase the installation media for another $70 or so) gave a price of around $12,000.
MySQL seems the more attractive offer. And, honestly, amongst all of the "free" database engines out there, I much prefer MySQL over Firebird or Pervasive. I've never seen PostgreSQL used in an application environment, but I can imagine it performs in the "meets or exceeds expectations" category.
Paris, needs improvement.
SQL Server to MySQL?! Good luck with that.
I can see that maybe at the ultra high end, someone might move from SQL Server to Oracle RAC,but to the rest of the product range? No reason what so ever. SQL Server is cheaper to run, more secure and easier to manage, and is better tested on a more Secure OS (Windows) whereas Oracle is primarily tested on the Swiss Cheese of Linux - and to mySQL? Lol, I just can't see that happening.
I note from Secunia that there are 110 known vulnerabilities in MySQL5 versus 20 in SQL Server 2005 and 2! in SQL Server 2008....
"Baby's first database" is running some pretty massive workloads, like facebook for instance. Their access control, RAS and extension are not great, but you can workaround/not need those features. MySQL has experience running absolutely crazy scale workloads, highly modified. I am not familiar with any massive, high performance workloads running on MS SQL. You rarely see MS SQL on upper mid range workloads either, like the average company's SAP environment. If you are looking for a DB with training wheels, MS SQL is way easier to manage than MySQL. That is why most people use it. MS SQL doesn't do anything particularly well and it not best of breed in any category, but it works alright and requires little advanced skill. In short, it is a Microsoft product.
This post has been deleted by its author
That is information from Microsoft. As Microsoft only has 17% of the overall DB market, per Gartner, it seems unlikely that they would have a 2-1 market share on SAP as compared to the rest of the workload market. .NET applications is where MS SQL is most common. The vast majority, like 90%, of large SAP users, say 1,000 plus users, run on either Oracle or DB2 for core SAP.
I believe Oracle is still the largest DB install for SAP (Oracle claims that over 2/3s of SAP users run Oracle DB, but that is probably overstated). IBM DB2 is undoubtedly growing the fastest for SAP workloads, primarily because DB2 is SAP's preferred DB. Many of SAP's largest installs, e.g. Coca-Cola, Pepsico, Siemens, 3M, SAP (internal use SAP environment), Welch's, Pfizer, Cardinal Health, Medtronic and many others, have migrated from Oracle to DB2 in the last few years. SAP and IBM have built a deep compression algorithm for SAP data which reduces the storage requirements by 60%, DB2 is integrated into the SAP cockpit and operates as part of the SAP environment.
The apparent contradiction is because Microsoft includes any customer running any application or tier at all associated with SAP which uses MS Server or SQL as being an "SAP on Microsoft" install. There is no way on earth that 57% of SAP customers run their core DB tier for SAP on Windows Server, but they might run an application or presentation server on MS Server.... or they might run some reporting module on SQL with the core FICO and other core modules running on AIX - DB2 or Oracle.... Microsoft would include that customer as a "Microsoft install" even though the environment is predominantly running on something else with one small component running on SQL or MS Server.... Oracle does the same thing with their 2/3s number.
If you need high end functionality (e.g. active-active clustering, multi-TB scale, granular block partitioning, advanced indexing and look-ups, advanced encryption and access control, etc), it is either Oracle RAC or DB2 PureScale. Most people and workloads don't need that functionality, but the ERP and high end transactional systems are in the Oracle and DB2 range.
If you need mid-range, lower end DB functionality, it is MS SQL or MySQL (or one of the MySQL forks)... or Postgre. MySQL will almost always blow past MS SQL in performance primarily due to its MyISAM default table format which is very lightweight and it relatively easy on the CPU cycles and memory usage. You also have your choice of table formats, or engines, in MySQL whereas MS SQL is their Sybase derivative proprietary, for better or worse. MySQL also wins in replication and scale as they use a binary log of changed data, whereas MS SQL replicates everything and sucks a bunch of storage and system performance. Obviously MySQL is less costly and allows for platform choice where as MS SQL is all MS, all day. The area where MS SQL out performs MySQL is in recovery. The MyISAM engine can become corrupted pretty easily in the event of a power outage where as MS SQL has more advanced recovery functionality with check points and process memory. MS SQL probably has a slight advantage on the trigger and embedded functionality side as well. MS SQL obviously integrates well with MS Server and .NET tools, but the downside is that MS doesn't integrate well at all with the open web stack (LAMP and the like) and the Java world.
For most situations, MySQL or Maria (same difference) will probably be the best bet. If you have bet the ranch on MS technology and need mid-range (but not enterprise) RAS and extension, MS SQL will be easier.
but the downside is that MS doesn't integrate well at all with the open web stack (LAMP and the like) and the Java world.
Sez who? We've got several Java systems storing their data in MS SQL right now, no problem -- and I've worked on a few projects where Apache, PHP, and even MySQL talked with MS SQL fine. I haven't done any of that work with Linux specifically, so I won't comment there, but I can safely say that 4/5 of your comment is bunk.
MS SQL is an ANSI SQL DB (based on Sybase), so it will work with Java, PHP, etc. I am not saying it won't work. I am saying it is not designed to work with open stack and third party technologies to the degree it is designed to work with .NET and MS technologies. You can only run it on the MS platform. That is only true of MS SQL. Oracle, DB2, MySQL, Postgre, etc all run on every major platform, including enterprise platforms (Unix). MySQL will support all of the open stack engines, Inno, Merge, MyISAM, memory, cluster. MSSQL supports MSSQL's Sybase engine, that's it. MySQL and MS SQL are about at parity with Java, they both have a decent JDBC driver. PHP can natively create a MySQL DB and perform basically every function in the DB without ever needing to use a MySQL editor. That is nice and can't be done with MSSQL. Oracle and DB2 can both store Java procedures in the database, I don't think there is any comparable level of integration with MS SQL. DB2 and Oracle will both handle Java functions such as garbage collection, Java multithread support. MS SQL will work with PHP, Java, etc through a connector, but MS is not going out of their way to help you with Java or open stack technologies. They want you to use .NET and MS platform, IIS, etc.
MySQL just set the world record on the SPECJ benchmark.
http://www.mysql.com/why-mysql/benchmarks/
Benchmarks, especially Oracle benchmarks, are not great predictors of real world performance as they are almost always highly modified versions of the DB which rarely have an apples to apples hardware configuration. The best predictor of scale and performance are real world results. facebook, Google, Yahoo, Ebay and many of the other highest IO, both read and write, applications in the world run on MySQL with the Inno engine. It is more than capable of handling the highest of the high end workloads from a performance perspective. MySQL lacks enterprise security/access, extension, and some RAS functions, but performance and scale is definitely not an issue.
> MySQL will almost always blow past MS SQL in performance primarily due to its MyISAM default table format which is very lightweight and it relatively easy on the CPU cycles and memory usage
The more you talk ...
> You also have your choice of table formats, or engines, in MySQL whereas MS SQL is their Sybase derivative proprietary,
... the more you sound ...
> MySQL also wins in replication and scale as they use a binary log of changed data
... thirteen.
As a longtime user of mssql I'm damned if I'm going to praise it but you should just shut up.
Great, more timewasting on an idiot troll. Very well.
> MySQL will almost always blow past MS SQL in performance primarily due to its MyISAM default table format which is very lightweight and it relatively easy on the CPU cycles and memory usage
If you don't distinguish between read and write performance, that's a major problem. For read performance (which makes up the majority of db work), one b*tree is going to be much like another b*tree. Also you fail to understand the relevance of the optimiser, which has a vastly greater role in read peformance than you seem to realise.
Also, claiming that "MySQL will almost always blow past MS SQL in performance" without providing any evidence of this rather contradicts your own suggestion that the claimant should be "providing evidence" (to wit: "as opposed to providing evidence which would contradict any of the above"
> You also have your choice of table formats, or engines, in MySQL whereas MS SQL is their Sybase derivative proprietary,
outstandingly stupid comment. The back end does not matter, only the result set (or whatever) output. I suppose that if you want fast write performance than unlogged MyISAM then occasionally I'd agree with you. In the main, for real work, I would not.
> MySQL also wins in replication and scale as they use a binary log of changed data
Like, the transaction log in mssql is not binary? WTF? perhaps it's handwritten XML by the gnomes that live in the server.
Good bloody night.
"If you don't distinguish between read and write performance, that's a major problem. For read performance (which makes up the majority of db work), one b*tree is going to be much like another b*tree. Also you fail to understand the relevance of the optimiser, which has a vastly greater role in read peformance than you seem to realise."
I can come up with some SPEC benchmarks, but they are generally pretty worthless as the hardware is never apples to apples and its more of a tuning test than anything you are likely to see in the real world. MySQL does have the SPECJ record, but I assume Oracle used some crazy config. The best way to judge performance and scale is to look at what has been done. Most of Google, Yahoo, facebook runs on MySQL. Not familiar with any MS SQL applications with that read or write performance or scale.
One b*tree, or columnar comparison tool, is not like all others. You write that "one b*tree is going to be much like another b*tree", but in the next sentence you mention optimizers... meaning that one b*tree, or look up, is not going to be like the next b*tree. For instance, MySQL uses a special algorithm in LIKE string look ups, called boyer-moore, to initialize the pattern for a string and perform the search quickly which limiting the index range for the search. MySQL also has a pretty slick hash index optimizer. There are all sorts of details, but, point being, one b*tree is not like every other and there are various optimizers for improved reads in MySQL.
"outstandingly stupid comment. The back end does not matter, only the result set (or whatever) output. I suppose that if you want fast write performance than unlogged MyISAM then occasionally I'd agree with you. In the main, for real work, I would not."
I certainly does matter. The use of different engines allows you to have, for instance, tables which are transactional or not, in-memory or not, compressed for a particular application/workload, columnar vs. relational, row level lock (Inno) vs. table level lock (ISAM), foreign keys or not, various relationship constraints or not, etc. The engines acts as an optimizer for a particular workload as opposed to the general table style. If the back end did not matter at all, why are all these columnar DB companies wasting their time?
"Like, the transaction log in mssql is not binary? WTF? perhaps it's handwritten XML by the gnomes that live in the server."
You, I assume intentionally, did not respond to the full sentence. MySQL uses a log based replication method as opposed to a data based replication method. Instead of replicating all of the data to the slave copy, MySQL only replicates the binary changes (differential at the block level) to the slave. MS SQL, unless it has changed recently, uses a publish and subscribe paradigm. MySQL has way less data to replicate, way faster.
> I can come up with some SPEC benchmarks, but they are generally pretty worthless as the hardware is never apples to apples and its more of a tuning test than anything you are likely to see in the real world. MySQL does have the SPECJ record, but I assume Oracle used some crazy config.
Good, an intelligent comment. You can haz an extra upvote and I'll try to take you a bit more seriously.
> The best way to judge performance and scale is to look at what has been done. Most of Google, Yahoo, facebook runs on MySQL. Not familiar with any MS SQL applications with that read or write performance or scale.
Their businesses to deal with very large amounts of low quality data (low quality can mean either just that (tweets), or it can be lost without much consequence (tweets again), or can be recaptured (Google spider spiders again). If you want to run a business where any data failure can be expensive then you may not wish to go with the cheapest options (RBS, NatWest). I think you are trying to compare things which shouldn't be compared. Do you think they run their payroll on hadoop & mysql?
> One b*tree, or columnar comparison tool, is not like all others. You write that "one b*tree is going to be much like another b*tree", but in the next sentence you mention optimizers... meaning that one b*tree, or look up, is not going to be like the next b*tree.
Absolutely wrong. The optimise I am referring to optimises at the logical level of the data and the data distribution, with some reference to the physical extras such as the presence of indexes. An example. You have a million row table (mrt) and a thousand row table (trt), both are indexed and you want to join them. Do you join the mrt to trt, meaning that you go through a million rows and try and find the matching row in trt (using trt's index), for a total of 1,001,000 logical reads (a million reads of mrt with a thousand reads of trt), or do you join the trt to the mrt (using mrt's index) for a total of 2000 logical reads (a thousand reads of trt with a thousand reads of mrt)? 500 times diffrerence in performance and in many other cases it can be much, much greater. This may not be a great example but this is where the real value of an optimiser lies, and none of it cares about the underlying physical data structure.
Here's a link to an article on the subject which links to an entire book on the subject (which I only discovered today and which I must read) <http://www.simple-talk.com/sql/sql-training/the-sql-server-query-optimizer/>
> I certainly does matter. The use of different engines allows you to have, for instance, tables which are transactional or not,
if you want non-transactional-respecting reads, use isolation level read uncommitted, or equivalent hints. Available in mssql.
> in-memory or not,
A decent db will cache read data in memory and not touch the disk again if mem is adequate
> compressed for a particular application/workload,
Hmm, can't speak on that.
> columnar vs. relational,
you seem to be comparing relational with non relational. Does mysql have columnar data layout? If not, why do you ask it of mssql?
> row level lock (Inno) vs. table level lock (ISAM),
furheavensake do you think mssql doesn't provide this, in a more flexible form? You can hint the locking level. Go here and look for tablock <http://msdn.microsoft.com/en-us/library/ms187373.aspx>
> foreign keys or not,
irrelevant to reads. These are a write issue.
> various relationship constraints or not, etc.
vague
> The engines acts as an optimizer for a particular workload as opposed to the general table style. If the back end did not matter at all, why are all these columnar DB companies wasting their time?
I think you are confusing yourself here. All the back ends to MySQL are tabular aren't they? Yes or no? As for columnar DBs, they are addressing a different kind of workload.
> You, I assume intentionally, did not respond to the full sentence. MySQL uses a log based replication method as opposed to a data based replication method. Instead of replicating all of the data to the slave copy, MySQL only replicates the binary changes (differential at the block level) to the slave. MS SQL, unless it has changed recently, uses a publish and subscribe paradigm. MySQL has way less data to replicate, way faster.
You are completely wrong here. Replication based on logs was always available, see<http://nirajrules.wordpress.com/2008/12/08/snapshot-vs-logshipping-vs-mirroring-vs-replication/> for a whole list of options including log shipping. What you seem to be confusing it with is a snapshot replication, which it has as well (you pick whichever suits your problem best). I'm not an expert on the subject and what I do know is rather stale so I'm not going to say any more on it.
Please don't make unsubstantiated claims based on things you clearly don't know. It does you no credit.
"Their businesses to deal with very large amounts of low quality data (low quality can mean either just that (tweets), or it can be lost without much consequence (tweets again), or can be recaptured (Google spider spiders again). If you want to run a business where any data failure can be expensive then you may not wish to go with the cheapest options (RBS, NatWest). I think you are trying to compare things which shouldn't be compared. Do you think they run their payroll on hadoop & mysql?"
I wrote in my original post that MS SQL had an advantage over MySQL in data quality, used the example of corruption in the case of a power loss with ISAM. As I mentioned, however, MS SQL is certainly not best of breed in this category either. Oracle or DB2 have far more advanced corruption protections and HA protections (e.g. data guard, datalens and RAC and the IBM equivalents) than MS SQL. To my knowledge, RBS and NatWest run their payroll and all other critical data on DB2, not on MS SQL. If you need those advanced features, you are likely not using MySQL or MS SQL. The comment wasn't directed toward data quality. It addressed performance.
"Absolutely wrong. The optimise I am referring to optimises at the logical level of the data and the data distribution, with some reference to the physical extras such as the presence of indexes. An example. You have a million row table (mrt) and a thousand row table (trt), both are indexed and you want to join them. Do you join the mrt to trt, meaning that you go through a million rows...."
The engine will absolutely effect the read performance for various queries, as will optimizers that determine the most efficient way to run the query (e.g. transforming a subquery into a semi-join operation and then treating semi-join like another join operation throughout the optimizer). MySQL has query optimizers and different data handling engines. Many different engines with many of different data handler profiles. The link below provides various benchmarks for different MySQL engines using the same read queries on the same data set with the same "normal" OLTP physical structure. If the engines made no read performance difference, there would be no difference on these benchmarks as the only changed variable is the engine.
http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/
Here is a benchmark on the various engines for JOIN queries, based on your example. Different results for different engines.
http://www.mysqlperformanceblog.com/2006/05/29/join-performance-of-myisam-and-innodb/
On the run down of features, I was just throwing out examples of various differences at the database engine/server level that can effect read or write performance or both. Point being, engines effect performance, having a wide variety of engines or being able to develop/donate your own (if you are Google or fb) is a benefit for performance of a particular workload as opposed to being forced to use the standard MS (Sybase) engine.
"you seem to be comparing relational with non relational. Does mysql have columnar data layout? If not, why do you ask it of mssql?"
Yes, the Calpont and KFDB engines are columnar.
"Replication based on logs was always available, see<http://nirajrules.wordpress.com/2008/12/08/snapshot-vs-logshipping-vs-mirroring-vs-replication/> for a whole list of options including log shipping. What you seem to be confusing it with is a snapshot replication, which it has as well (you pick whichever suits your problem best). I'm not an expert on the subject and what I do know is rather stale so I'm not going to say any more on it."
Yes, MS SQL can log ship, but does it do it at the binary level as opposed to the SQL statement level which then need to be compiled (binary vs. transactional logs)? It may be possible, but it was my understanding that MS SQL ships the transactions. Binary obviously being higher performance.
> I wrote in my original post that MS SQL had an advantage over MySQL in data quality, used the example of corruption in the case of a power loss with ISAM. As I mentioned, however, MS SQL is certainly not best of breed in this category either.
That's an incredible and unsubstantiated statement from somebody who clearly doesn't know much about MSSQL.
> Oracle or DB2 have far more advanced corruption protections and HA protections (e.g. data guard, datalens and RAC and the IBM equivalents) than MS SQL.
You are confusing data corruption with high availability, they are not the same thing.
> To my knowledge, RBS and NatWest run their payroll and all other critical data on DB2, not on MS SQL.
My point was that you don't want to do things on the cheap, I was not suggesting that they did run any particular database.
> [...] The link below provides various benchmarks for different MySQL engines using the same read queries on the same data set with the same "normal" OLTP physical structure. If the engines made no read performance difference, there would be no difference on these benchmarks as the only changed variable is the engine.
I never said that the underlying table structure had no effect, in fact I'd be very surprised if they didn't, but you didn't seem to understand what the query optimiser was and how important it was -- orders of magnitude instead of small constant factors or multiples to the point where the underlying storage mechanism can become almost irrelevant. The query optimiser is never to my knowledge used with reference to the underlying table structure, only logical rewriting of the query. I believe this is the standard terminology.
> On the run down of features, I was just throwing out examples of various differences at the database engine/server level that can effect read or write performance or both. Point being...
*Point being*, that you didn't know that MSSQL provided most of what you are talking about and you're trying to cover that up.
> Yes, the Calpont and KFDB engines are columnar.
from <http://en.wikipedia.org/wiki/Calpont> "InfiniDB is accessed through a MySQL interface.[8] It then parallelizes queries and executes in a Map-Reduce fashion (similar in concept to the methodology used by Apache Hadoop).[9] Each thread within the distributed architecture operates independently, avoiding thread-to-thread or node-to-node communication that can cripple scaling.[10]"
This is hardly a drop-in storage engine of the type of innodb or myisam, is it? It's an entire database back end.
From <http://en.wikipedia.org/wiki/Kickfire>: "
* MySQL integrated as a storage engine plug-in, with special modifications to the optimizer to allow query rewrite optimizations over a column store.
* An FPGA-based "Query Processor Module" which attaches via external PCI-X bus to a base linux server module. The QPM features a dataflow architecture and implements relational algebra in run time reconfigurable hardware for SQL join execution."
Bloody ditto, with dedicated hardware thrown in.
> Yes, MS SQL can log ship, but does it do it at the binary level as opposed to the SQL statement level which then need to be compiled (binary vs. transactional logs)?
Here's what you originally said: "MySQL also wins in replication and scale as they use a binary log of changed ***data***, whereas MS SQL replicates everything and sucks a bunch of storage and system performance"
Well, you said 'data' (see above). You did not mention sending the actual SQL so I took you on what you said and responded accordingly. You also said that: "SQL replicates everything and sucks a bunch of storage and system performance" which was just plain bollocks, which you've not acknowledged.
Also a bit of reading up on MySQL replication and to my surprise, I have to admit, it can do SQL shipping instead of data shipping (my terminology here). I didn't know any current system implemented that. However it can do both and by default does, from <http://forge.mysql.com/wiki/MySQL_Internals_Binary_Log>
"There are two types of binary logging:
* Statement-based logging: Events contain SQL statements that produce data changes (inserts, updates, deletes)
* Row-based logging: Events describe changes to individual rows
Mixed logging uses statement-based logging by default but switches to row-based logging automatically as necessary.
Row-based (and mixed) logging is available beginning with MySQL 5.1. "
So, both. Not one or the other. Why? Well perhaps this will help: <http://dev.mysql.com/doc/refman/5.1/en/replication-sbr-rbr.html> "16.1.2.1. Advantages and Disadvantages of Statement-Based and Row-Based Replication"
You don't seem to know much about databases and given that you seemed to know less about MySQL replication than 20 minutes of googling could provide, I'm reverting to my original view that you are a timewaster.
"You are confusing data corruption with high availability, they are not the same thing."
Yes, I know. I included the superior HA features in Oracle/DB2 because of your spider example (i.e. you want to use MSSQL over MySQL for workloads where you can't recapture the data). This assumes that MSSQL is superior in HA as the DB going down would be the reason for recapture. If you have a workload where you cannot recapture data (live OLTP for banking transactions or the like), you would want to use a DB with a proper HA architecture like Oracle or DB2. Also, HA and data quality go hand in hand. The most common reason for a data corruption or a contiguity issue in the DB is that the DB goes off-line. Data quality isn't an issue in the normal course of operations. It is when something goes wrong that data quality becomes an issue. HA/data quality are inherently linked.
"My point was that you don't want to do things on the cheap, I was not suggesting that they did run any particular database."
Yes, and my point is that MSSQL and MySQL are both doing things on the cheap. Neither are enterprise grade at the RBS level.... MSSQL forces you to run on the MS NT platform, the opposite of mission critical. MSSQL cannot do contiguous paging, still uses standard 8 KB blocks, few data transfer options, is missing a whole range of indexes, could go on. I am sure RBS has never considered either MSSQL or MySQL for the workloads you are talking about, so the advantage for MSSQL over MySQL is a false comparison. Neither have that level of enterprise functionality. Using "RBS applications" enterprise grade functionality as a counterpoint to MySQLs scale, flexibility and cost advantages is false.
"This is hardly a drop-in storage engine of the type of innodb or myisam, is it? It's an entire database back end."
More of a drop in than the non-existent MSSQL options.
"*Point being*, that you didn't know that MSSQL provided most of what you are talking about and you're trying to cover that up."
No, the I acknowledged that all of the features were not specific to read performance and that I was throwing out possible advantages the engines could provide for different types of workloads. MSSQL does provide many of them, but you can tailor your engine to your workload which is not available in MSSQL.
"You also said that: "SQL replicates everything and sucks a bunch of storage and system performance" which was just plain bollocks, which you've not acknowledged."
Acknowledged, I was mistaken. MSSQL can do transactional log ships. I know about the types of binary logging.
"I never said that the underlying table structure had no effect, in fact I'd be very surprised if they didn't, but you didn't seem to understand what the query optimiser was and how important it was -- orders of magnitude instead of small constant factors or multiples to the point where the underlying storage mechanism can become almost irrelevant. The query optimiser is never to my knowledge used with reference to the underlying table structure, only logical rewriting of the query. I believe this is the standard terminology."
Actually, you wrote "outstandingly stupid comment. The back end does not matter, only the result set (or whatever) output." The table structure (back end) does matter, obviously. Yes, query optimizers matter as well, and are by no means only available on MSSQL. Different engines are an advantage for MySQL which MSSQL does not have, so, like I wrote originally, score one for MySQL.
> The most common reason for a data corruption or a contiguity issue in the DB is that the DB goes off-line.
Well, if db goes offline then it's not corruption. Unless it's caused by corruption. But that's not causing corruption, it's caused by. Isn't it.
"Contiguity"? WTF?
> It is when something goes wrong that data quality becomes an issue
Good god, let me hire you immediately! We need sharp-as-a-hammer guys like you. You'll be an admin before you know it, parachuted in to deal with DR/HA, and on triple your current pocket money!
> MSSQL cannot do contiguous paging,
what is that and why does it matter?
> still uses standard 8 KB blocks,
err, how is that a problem?
> few data transfer options,
what options does it not have? I really have no idea.
> is missing a whole range of indexes,
You mean other than hash indices, what is missing? Please say it doesn't have clustered indexes! pleeeeze!
> More of a drop in than the non-existent MSSQL options.
You have no real world experience
> MSSQL does provide many of them [features], but you can tailor your engine to your workload which is not available in MSSQL.
You have no real world experience Part 2: The Sequel (plus you didn't understand my answer last time round, but that's ok)
> Acknowledged, I was mistaken
credit due
> Yes, query optimizers matter as well, and are by no means only available on MSSQL.
WHO SMUGGLED A QUERY OPTIMISER INTO A DATABASE ENGINE AND DIDN'T TELL ME!? I'LL SKIN THE BASTARD! I'LL HAVE EAGLES ALL OVER HIS LIVER FOR ETERNITY.
> Different engines are an advantage for MySQL which MSSQL does not have, so, like I wrote originally, score one for MySQL.
You have no real world experience Redux. In fact, you don't have sweet FA in any field I suspect.
Truth is, you've gone beyond pissing me off and this has now become entertaining. I'm happy to carry on.
Your move.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
