Slashdot Mirror
MySQL Beats Commercial Databases in Labs Test
An anonymous reader writes "Many of the big players now offer free or 'light' versions of their databases, some would call them crippleware. Builder AU compared databases from Oracle, IBM, Microsoft and MySQL, and the open source offering came out on top."
I thought the reason MySQL don't post their own comparisons is because the EULAs of Oracle etc. specifically forbid public posting of benchmark results?
Nowhere.
Is it really fair to compare an open-source project, designed to compete with for-pay commercial products, with crippled versions of said commercial products?
Of course, I don't really care what the answer to that is -- either way, I win. Either commercial DB vendors really are releasing heavily crippled versions (bad for them), or MySQL really is the best DB out there (good for it).
And what about postgres?
Don't thank God, thank a doctor!
And what about PostgreSQL? It should fare very well.
Sig is on vacation
Can you elaborate on this please? I used MySql for a minor windows app. It uses a database with about 4 tables and is in 3rd normal form. I chose MySql as a free alternative to M$ Sql server for this simple database only.
Are you saying it gives "estimates" for some queries?!
I only skimmed TFA, but why are they using Microsoft's Express Beta version? rather than SQL Server Standard edition? Kind of rigged, ne? Plus, it's a beta! Come on! I know it's microsoft, and this is slashdot, but please!
"It is possible to commit no errors and still lose. That is not a weakness. That is life." -Peak Performance
I personally believe that sort of condition in a EULA is unenforcable (even assuming the EULA proper is enforcable - which I don't believe either), as it is anticompetitive. Either way, the test was done by an Australian company, and that could lend a legal hand by setting up international roadblocks to EULA enforcement.
First, you would think that PostgreSql would be top o' the heap because it's equal to / arguably better than MySql in features, and it's under a more permissive licence.
Second - Sweet Hog of Prague! Oracle 10g costs $24 grand Per CPU!?!?!?!?
NeverEndingBillboard.com
NeverEndingBillboard.com
So, look at the pages dedicated to MS SQL Express and IBM DB2. DB2 costs thousands of dollars, MS SQL Express is free. DB2 has a slightly superior feature set and additionally runs on Linux... and they rate it drastically higher, even though it's ridiculously expensive in comparison. Don't even get me started on the fact that the MS SQL version they tested was a beta (almost every Beta MS releases is far slower than the release versions, and contains tons of additional debugging code - VC# Express Betas were drastically slower than the release version of VC# Express.) Of course, none of this is really a suprise, since the 'labs test' is pretty obviously nothing of the sort.
And of course, absolutely no mention of stability, reliability, bugs, robustness, etc... what a suprise, considering that both MSSQL and MySQL are arguably far behind in those areas.
Where are the test cases? Where is the testing methodology? How about some explanation of particular cases where one solution didn't compare with the others, or where one solution excelled? This 'labs test' reads more like a sales pitch than anything resembling an actual test.
using namespace slashdot;
troll::post();
[Fuck Beta]
o0t!
from TFA: "bringing administration and configuration within the realms of the novice" and "Obviously ease of configuration and administration is paramount -- the in-house staff must be able to easily enter and update data, while the novice administrator must be able to make minor changes to the database on the fly."
Is it Just me or are we awarding our winners based on how easy it is to use, as compared to how much more power it places in our hands?
I love humanity, it is people I hate
So Microsoft's SQL Server Express got the lowest 2.5 stars rating. Why I am not suruprised? I knew the guys in the lab have high anti-microsoft sentiments.
"Our scenario in this comparison calls for a database solution for a relatively small e-commerce company with less than 200 employees. The company sells DVDs and books over the Internet and will initially have around 1000 customers"
Lemme see...five customers for each employee? With an American workforce pulling down $40K each with benefits, that means each customer needs to buy $8K of useless crap from this one company every year.
I quoth from the MySQL reference manual:
MySQL solves this by counting inserts and maintaining this in a separate segment in each BDB table. If you don't do a lot of DELETE or ROLLBACK:s this number should be accurate enough for the MySQL optimizer, but as MySQL only store the number on close, it may be wrong if MySQL dies unexpectedly. It should not be fatal even if this number is not 100 % correct.
SQL Server Express is not really meant for any serious production environments. I suppose one could use it for a personal web site here and there, but it is a tool primarily meant for developers.
Instead of having to have access to a full fledged SQL Server, you use SQL Server Express to develop your application and then deploy it to a full SQL Server when that server becomes available.
Since SQL Server Express supports the vast majority of the features that a developer might need, it is very useful during the initial development of an application.
In my experience, SQL Server Express is great for basic projects (like a personal web site or blog) and for the initial phases of development of a "real" project. Once you start getting into the realm of serious applications, where one might need finer grained control of isolation and locking, or when you are at the point where you need to do performance testing of your application, you really do need to move up to the full SQL Server box.
At any rate, I'm not really sure this comparison is all that fair. MySQL makes an attempt to be a database server for "real" applications, where as SQL Server Express is more of a development tool / MS Access replacement that is targeted at personal projects.
Even the crippled versions of DB2, Oracle, and MSSQL still have the underpinings for advanced features that MySQL doesn't support. From real replication to actual performance monitoring (all three of the big guys provide detailed hooks into the guts of the DB) to support for multiple filegroups and indexes and databases spread across filegroups, the big DB's have features that are important but impact performance.
Heck, you want to see MySQL get its ass kicked on performance? Run a test on a filesystem against MySQL.
Comparing performance among databases is only meaningful if all of the candidates have the features you need. MySQL has come a long way, and I use it in production every day, but this is kind of a silly comparison. The free versions of the big DB's are meant to provide an easy migration path to more feature-complete versions; if you use SQL Server Express and want to upgrade to something that that supports clustering and log shipping, you may your money and get your features. With MySQL, if you outgrow it, you either need to start writing code, migrating to something else, or sitting on your hands waiting for it to get there.
Recap, for those who won't RTFC and want to slag me: I like MySQL. I use it for mission critical purposes in production environments. However, comparing a simpler product's performance to (crippled versions of) more robust products is silly.
Cheers
-b
If I wanted a sig I would have filled in that stupid box.
Not the original poster and I know nothing of what he was refering to, but if you're doing a minor app, I suggest SQLite -- a fully standalone SQL implentation. As in, you specify a database.db file and can do all the sql fun you want in it, but never have to deal with telling the user to set up mysql + authentication + etc, which is a big hassle when all you want sql for is your own data manipulation.
Pretty fast(I never benched it, but its never been an issue), very portable, works in all major languages, overall a very nice tool to have.
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
Uh? What are you talking about? COUNT(*) has never given estimates in MySQL. That's why it's so friggen slow with InnoDB...
When I read your comment, I thought you were joking (I don't follow the MySQL scene at all). A quick google pulled up this link and sure enough, what you posted is true. The worst part about this is that the status is 'Not a bug'. Huh? Even if this is over a year old, and even if this isn't in the current release, and even if anything, how could anyone think this isn't a bug?
Thats how it is bad for them. The free versions of the software are basiclly demos. If the demo doesn't work well who is likely to pony up and buy the main product?
BTW, from what I read of the article it doesn't look like they used the free version of Oracle. It listed a unlimited cpu lic. fee of $19K.
I was impressed with some of the features of MySQL. Since I looked at it years ago it looks like it has come a long way. However I now work at a big company with a site lic. for Oracle, its unlikely I'll use it professionally.
Think Deeply.
How can one even take this seriously with unsubstantiated statements like:
Brilliant scaling capabilities "as is".
Who says so? Based on what data? In this context, sure it "supports" tables up to 64TB, that doesn't mean it scales, just that it supports big tables.
Er, I give the article an unsubstianted 0 out of 4 stars based on my own ad-hoc comparisons to other articles. See, I can do it too, whee!
Actually, it's quite true, and if you look at what's actually going on behind the scenes inside the database, it makes sense.
:)
If there's nothing going on in the database, then the 'summary' value that MySQL keeps is probably spot on accurate. But, if there's lots of simultaneous inserts and deletes, then it's really going to be very approximate. Until things are all flushed, the summary may include all the inserts and none of the deletes, or vice versa. If you wanted to make the summary information accurate, then you'd have to establish locks and the like around that summary value, and THAT will slow the database down. As it stands, inserts and deletes can be executed with ZERO regard to each other.
Postgresql has a similar problem, except instead of offering a summary value and informed that it's an estimate, whenever you do a count(*) it actually scans the entire table file looking for 'valid' rows. Ie, count(*) is not instantaneous. I think they were going to address this issue in a later release (or perhaps it's in 8.1 already), but it's NOT a simple thing. However, if you wanted instant answers in Postgresql NOW, you can do it by setting up a trigger on insert and delete, and maintaining your own summaries. This is a performance hit, of course... but you'd get the same, or a similar hit, if the database was maintaining for you.
What the 'big guys' do, I don't know. But... don't knock MySQL for doing something weird
Postgresql, for comparison, will give you an 'accurate' value, but it actually has to create rows: it can't rely on summary information.
the money you can get paid as a DBA for each type of database...
"Waste not one watt!" - CZ
Both you and the parent aren't reading what they wrote. SELECT COUNT (*) is accurate, it was SHOW TABLE STATUS that gives the estimate (as it should, IMO).
Read the bug report again.
It states that SHOW TABLE STATUS differs from SELECT COUNT(*) because SHOW TABLE STATUS guesses.
SHOW TABLE STATUS is just a misc admin command.
I don't know... Their "results" are laughable. MySQL above SQL Server Express (and BETA too)? Yes, the Express ed limits you to 1 CPU (they HAVE to limit it in some way so large companies buy their product), but otherwise.... It's FAR better than MySQL! And then they compare that with a 20k$+ RDBMS (Oracle; and also DB2 which also costs thousands)... If you include such an expensive DB, why not include SQL Server (the "real"/uncrippled thing) for comparison? MySQL may not be limited in terms of what HW it will run onto, but it's FAR lesser of a "enterprise grade" RDBMS than ALL the other solutions they evaluated (and that would include PostgreSQL too). At that rate I wouldn't be surprised to see them praise SQLite over Oracle or such. It sounds like this guy has NO clue about MySQL's real-life limitations - perhaps he's never used it...
There are all kinds of different DBs to fill different needs. Use whatever works for your scenario... MySQL is about the last one I'd use in most cases. And again, not including PostgreSQL?
For many businesses, a database is the vital organ that lives, breathes, and protects precious data -- the treasured jewel of their enterprise. Everything they know, and every way to know it, is dictated by these all-powerful tools.
The author definatly sounds like a product of the 60's or the 70's.
While there are other popular database products available, such as Sybase, we will save a full comparison for another time.
Sybase?
When rows are constantly being added and deleted, how do you define the row count at any one instant in time?
At that one moment in time, you can't look at the entire table and count the rows - that takes a finite and measurable amount of time. And unless you lock the entire table while you're doing that count, rows that you say are in your count can be deleted, or rows added to places in the table you've already "looked at".
So, Oracle et al have to do something similar - lock the table, count, and unlock. Or they're just giving an "estimate" also.
Parent is quite right. Count(*) is expensive, especially on big tables, so it's handy to have a quicker way that's not as accurate. MSSQL has it, too: ...basically, you're querying the table that the query optimizer uses, asking for how many rows it thinks there are in the primary key.
select rows from sysindexes where [id]=object_id('tablename') and indid2
Nothing wrong with that not being accurate. It's much faster than counting every row, and if all you care about is whether there are less than 1,000,000 rows or something, it's fine. If you care about exact numbers, use count(*), which IS accurate on MySQL.
-b
If I wanted a sig I would have filled in that stupid box.
To be fair to MySQL, that's only for tables of type InnoDB. MyISAM and other storage engines do return an accurate count. From here:
It should be noted, though, that you have to use InnoDB tables for all those "modern" database features like transactional support* and foreign key constraints.
It may be a bit of a bother, but it's not that hard to create the "counter table" for whatever it is you need to count. All the major DBs have something that's a pain in the ass...at least with MySQL you didn't have to pay for the pain.
*BDB and NDB Cluster are apparently transaction safe as well, but I have no experience with them; and for whatever reason, they don't seem to be popularly used.
@ASP.NET's parent-teacher meeting: "Little Johnny.NET is very bright, but he doesn't play well with others."
Until things are all flushed, the summary may include all the inserts and none of the deletes, or vice versa. If you wanted to make the summary information accurate, then you'd have to establish locks and the like around that summary value, and THAT will slow the database down. As it stands, inserts and deletes can be executed with ZERO regard to each other.
And that's exactly what you'd do if you needed to depend on the result. All the subsequent inserts and deletes are irrelevant, as they lie outside the transaction context.
Postgresql has a similar problem, except instead of offering a summary value and informed that it's an estimate, whenever you do a count(*) it actually scans the entire table file looking for 'valid' rows.>
Doesn't Oracle do that as well? Until you do a count, it only has an estimate of the table's size.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
This sort of technical reason is why MySQL is still considered toy in my mind.
Just because something is "hard" doesn't mean that its acceptable to not do.
It would be more acceptable to leave out COUNT(*) functionality than to do it wrong. (Yes, if it gives an number other than the number of rows committed to a table it is wrong. "Weird" is what you call LISP.)
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
By The Way.... X11R7.0 was released today... go to www.X.org for details.
"Would it kill you to put down the toilet seat?" -- Maya Angelou
The gratis version of MySQL is released under the GPL with the exception that it can be included in ANY F/OSS software. If you are creating an open source product or won't distribute your software, this is great. If you are producing commercial proprietary software, you must purchase a license to MySQL. I believe that many of the gratis, proprietary programs don't carry this restriction.
Open source allows more people to work on the project. Which usually means that code is more streamlined and efficient. Streamlined, efficient code is usually faster than closed source alternatives which often tend to be much more poorly written.
-1 disagree is not a modifier for a reason. -1 troll, flaimbait, redundant, overrated are NOT acceptable substitutes.
seriously...why bother to do any test ? for high end, Oracle, IBM, and Microsoft is pretty good at mid level while MySQL kill in low end. there are a lot of standard features in DB2, Oracle, and MS SQL that Mysql 5 still doesn't have. why compare crippled db against an opensource db that isn't crippled? Another OSS FUD!
I have a sneaking suspicion that you don't use heavily loaded databases often.
count(*) against a table that is under heavy load and you get:
1) the count when you issued the command, via a lock (table) and scan
2) a secondary table/counter that gets updated automagicaly with each insert/delete commit
mysql chooses number 2. why? Well by the time you can do anything with the results, the lock will be gone. The table will no longer be in the state it was when you asked. Good for you, you just wasted DB cycles because you want 'accurate' data.
grape - the GNU free, open source rape
This is THE most retarded review of modern database systems that I've ever read. From the moment I read the overview of MSSQL Express, I knew what the writer's opinion was going to be, and that was completely tilted in MySQL's favor. The basic descriptions of product feature were in most cases wrong. One would get the impression from this article that a major RDBMS would always allow dirty reads. And while it's true that you CAN do that, it is not the default behavior for any of them. It has to be explicity done and you have to go out of your way in your SQL code to make that happen.
It's things like that where you just ultimately conclude that the writer(s) of this article just does not know what the hell he's talking about and doesn't have a basic understanding of the concepts or products under review. It's just more OSS nonsensical propaganda in my opinion. And don't fool yourselves into thinking that an article like this is going to change any IT manager's mind about what DBMS he's going to deploy in his enterprise.
...leaving out PostgreSQL was a glaring omission.
I am so damn sick and tired of biased headlines and (often) even more biased comments. I know Slashdot is part of OSTG and all, but come on - it is beneficial to all concerned to be FAIR and unbiased. To compare MySQL to Oracle, DB2, or SQL Server is a joke. Anyone with half a hint of what they are talking about would know this. MySQL is only better for SMALL websites where speed is more of a deciding factor.
In any case, even ignoring the fact that these are crippled versions of the real deal, this isn't even a proper test! Let's see what a REAL DB comparison looks like:
Complete TPC-H Results List
I know that MySQL and PostgreSQL aren't included in that result list but that is how a test SHOULD be performed, not with the ridiculously hand-wavy methods the authors use to 'score' each DB software.
That being said, no one has any business saying MySQL >> DB2 or Oracle. That's a joke. MySQL would SUFFER in the 10TB test. Also, where is Teradata? Furthermore, the way that the article treats SQL Server is even more ridiculous, because their 'free' version is likely the least functional of the lot since it is SPECIFICALLY aimed at learning on one's own desktop. Nothing to see here, just a random useless article trying to say something to push its writers' ideas without much basis.
The reviewers know databases about as well as my grandma knows sports cars. They seem to mean well, and admit that this comparison was complex and hard. In the end they were unfortunately over their head.
PRODUCT SELECTION
1. where's postgresql? This is the product that the commercial vendors need to be the most nervous about. Sure, they're loosing more low-end revenue to mysql right now, but postgresql is getting picked up by some big players. It is far more mature than MySQL, doesn't have the quality issues, isn't partially owned by Oracle, etc.
2. where's at least a mention of all the various other solutions - from Firebird to Derby (Cloudscape)
FUTURE PROOFING
1. They mistakenly say that mysql doesn't require scaling up to enterprise versions like db2/oracle do. This is incorrect because mysql lags behind oracle & db2 for performance in many situations:
- since it doesn't support query parallelism (which provides near linear performance improves to db2/oracle)
- since it doesn't support partitioning (which can provide 10x performance improvements to db2/oracle)
- since it doesn't have a mature optimizers (which means that queries with 5 table joins can tank)
- since it lacks memory tuning flexibility
Together this means that as your data increases you have to continue moving a mysql database to larger & larger hardware.
In other words, if you need to scan a table with 10 million rows in it, then join that data against 6 other tables - db2/oracle can:
- leverage partitioning so only scan 1mil rows or so instead of 10mil
- split the scan across four cpus
- leverage more efficiently tuned memory (ensuring little tables & indexes stay in memory)
- use the best possible join
and probably complete the query in 1/60th the time that mysql would take. And that means that you could get better performance from db2/oracle on a $25,000 four-way smp than from mysql on a $2,000,000 32-way.
2. They fail to mention that Oracle now owns the most valuable parts of the MySQL solution (Innodb). Oracle has obviously purchased this component (which is how mysql supports transactions, pk/fk constraints, etc) in order to harm MySQL. Since there is no other viable replacement for Innodb the MySQL future is in serious doubt.
3. They probably weren't aware that MySQL is the least ANSI-SQL compliant database in the market. This is means that porting mysql code to another database is a royal pain in the butt compared to code supporting postgresql, db2, etc. Though, to be fair, it is getting much better.
LICENSING COSTS:
1. mysql isn't necessarily free, and can cost more than the commercial alternatives for small distributed commercial apps
2. db2 licensing only provided for DB2 Express- which is the low-cost 2-cpu model. That's often ok, hardly compares to Oracle standard edition also included. Also, I think they may have gotten their db2 costs mixed up between express & workgroup editions.
CONCLUSIONS & MISC
They mentioned some of the great mysql features like clustering and fault tolerance. Sorry, but mysql cluster solution is a separate telecom product that they purchased, that stores your data in memory - limiting your database size to however much memory you can afford. Not a practical solution for very many.
The mysql fault tolerance is really just replication. That's sad.
They mention one strength of mysql is their maximum database size of 64TB - which is nonsense, just because its internal registers and pointers can handle a theoretical maximum of 64TB doesn't mean that it would ever make sense to put more than 20 GB on it. DB2 & Oracle can go to 64TB, but today almost nobody is going beyond 10 TB just due to backup performance, cp
this is why mysql is a joke
- invalid-data.html
http://dev.mysql.com/doc/refman/5.0/en/constraint
" Before MySQL 5.0.2, MySQL is forgiving of illegal or improper data values and coerces them to legal values for data entry. In MySQL 5.0.2 and up, that remains the default behavior, but you can select more traditional treatment of bad values such that the server rejects them and aborts the statement in which they occur. This section describes the default (forgiving) behavior of MySQL, as well as the newer strict SQL mode and how it differs."
" MySQL allows you to store certain incorrect date values into DATE and DATETIME columns (such as '2000-02-31' or '2000-02-00'). The idea is that it's not the job of the SQL server to validate dates. If MySQL can store a date value and retrieve exactly the same value, MySQL stores it as given. If the date is totally wrong (outside the server's ability to store it), the special date value '0000-00-00' is stored in the column instead."
This is still a hobbiest toy.
That really cuts down on salary expenses and on their clothing allowance.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Actually, even the crippled versions of DB2, Oracle, and MSSQL still have the underpinings for advanced features that MySQL doesn't support. From real replication to actual performance monitoring (all three of the big guys provide detailed hooks into the guts of the DB) to support for multiple filegroups and indexes and databases spread across filegroups, the big DB's have features that are important but impact performance.
SHOOT!! you want to see MySQL get its bum kicked on performance? Run a test on a filesystem against MySQL.
Comparing performance among databases is only meaningful if all of the candidates have the features of which you need. MySQL has come a long way, and I use it in production every day, but this is kind of a silly comparison. The free versions of the big DB's are meant to provide an easy migration path to more feature-complete versions; if you use Sequel Server Express and want to upgrade to something that that supports clustering and log shipping, you may your money and get your features. With MySQL, if you outgrow it, you either need to start writing code, migrating to something else, or sitting on your hands waiting for it to get there.
Recap, for those who won't RTFC and want to slag me: I like MySQL. I use it for mission critical purposes in production environments. However, comparing a simpler product's performance to (crippled versions of) more robust products is silly.
Cheers
-AC
>The table will no longer be in the state it was when you asked.
Yes, everyone who ever uses a database should know this already. Thats the whole purpose of transactions and consistancy.
>Good for you, you just wasted DB cycles because you want 'accurate' data.
vs. using DB cycles for inaccurate data?
"Yes the result is wrong but look how many cycles we saved!"
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
Product comparison by reading the feature list on the back of the box. Now THAT'S a great idea! Saves the work of actually testing the products.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
What crackhead MySQL developers have you been talking to?
This just in! 3 out of 4 people make up 75% of the population.
this is similar to table statistics in the oracle database -- updated when statistics are rebuilt (automatic or manual), and only accurate as of that moment, though much quicker to query if you keep your statistics fairly up to date.
Seymour Cray built a very succesful computer company on the idea of getting a wrong answer quickly.
How they only give Oracle say 2 1/2 rating for interoppability and tool set is beyond me. Oracle 10g even the light version with Toad, Oracle Developer 10g, any Application sever (or php if you wish) is a smoking combination of not just performance but high availability, recoverability and reliability.
MySQL can actually cost more then all of the others since they charge per instance for support. Oracle is support for your environment but license for production. (so you get service levels for test/dev/uat/prod so on and so forth)
Mysql is fine for what it is, but even 10glite cutback from its big brother has so many other features its like comparing gwbasic against c++.
On http://xooglers.blogspot.com/ (ex google employees blog), it is mentioned that Google had started their adsense and adwords programs in MySQL. They moved to a "real" database and had so many problems that they decided to migrate back to MySQL, which they are still using to run Adsense and Adwords today. http://xooglers.blogspot.com/2005/12/lets-get-real -database.html
This just in! 3 out of 4 people make up 75% of the population.
Have you not ever ran Excell? Closeness works fine for 90% of the country. And the other 15% can run whatever.
I prefer the "u" in honour as it seems to be missing these days.
As I was struggling through an Oracle install a while back that Oracle doesn't have a great incentive to keep their products easy to use. Many common tasks, such as adding a column to a table or even just allowing clients to connect, are needlessly complex. I figure that this is actually part of their business model. Customers realize that they're in over their heads with the Oracle database, so they pay for premium support, trained Oracle consultants, and the like. Think of all the consultants who would starve if Oracle was easy to use.
Contrast this with MySQL. Installation is a breeze, and it's pretty flexible after it's installed: you can add or resize columns on the fly. Plus no TNSNAMES.ORA to worry about. I figure this is because MySQL is open source and the developers want to get you productive right away so that you continue to use their system, and eventually pay them for consulting and support, even when your application has outgrown the software.
Your design to a real part online: Big Blue Saw
with crippled versions of said commercial products?
The poster meant differently abled versions.
Happy random day in December!
"MySQL Beats Commercial Databases in Labs Test"
In other news, bicycles found to have two wheels.
I loved these zingers:
"What Express does not include when compared to SQL Server SE and above is Analysis Services, Reporting Services, Data Transformation Services, and Notification Services but some users would argue that these features are crippleware anyway."
Crippleware? What are the "some users" that argue this? The users that hate Microsoft? Also, DTS has been discontinued, and is not in any version of SQL Server 2005, so these guys obviously did not do their homework.
"There is no denying that SQL Server Express is the weakest of the databases in this group but..."
How exactly is there "no denying it"? Based on what is this claim made? Express isn't even designed for production use anyway...it aimed at developers and enthusiasts/students who want to learn their products.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
This is utterly false.
MSDE is based off SQL Server 2000, which itself a revision to SQL Server 7. MS Access has NOTHING to do with SQL Server (excpet proving nice single DB front ends via ADPs). When your dishonest (or just stupid) so early in a article, you loose your reader.
Speaking of all this, when was the last time ANY meaningfully large database was accurate? They all contain inconsistancies - no, not bad records, just bad data. I think we spend entirely too much time making databases etc. 99.9999999% reliable when humans are only 99% (if that), so the database as a system cannot exceed 99% anyway.
Instead of spending that $10M for that last 9, spend $50K on a customer service rep with the power to overide the system!
while (sig==sig) sig=!sig;
Amen to that. I know MySQL has its advantages, but when I go to the MySQL homepage and I see "October 2005 - NOW WITH TRIGGERS!!!" it makes me wonder. Now, I know triggers suck and should not be used unless absolutely necessary, but its just an example of one of may things... I expect a DBMS to have that ability, whether I use it or not... and other DBMSes have done it for years...
Lab test? where? misleading title by Mysql zealot. sale advocacy......
Lab test? What test? This was a list of features from the product documentation. What a disingenuous title.
Slashdot - where whining about luck is the new way to make the world you want.
Give me a break. This guy has reviewed databases on the basis of features, with, as far as I can tell, not a single real performance evaluation in different kinds of applications (OLTP, DSS, data warehouse), data volumes, or query complexity.
It gets better. In discussing Oracle, he explains: That is not to say the other databases serve up incorrect data but with some database engines when the workload is high, uncommitted data can be flushed from buffers to disk potentially creating a dirty read. MVRC also ensures that readers do not block writers and visa versa. HUH? I can't speak for EVERY database out there, but for most of them, you'd have to specifically set a "read uncommitted" isolation level to actually read dirty data. The majority of the databases would simply give a lock-and-block situation while the second reader waits for the writer to complete. Oracle's MVRC (and PostgreSQL's scheme) both prevent this lock-block situation. But, really, to say that this would potentially create a dirty read situation is just silly.
He also didn't speak of Oracle's new Express Edition. Yeah, it's limited to 1 CPU and has a cap on its data volume, but you get all of Oracle's core features (including PL/SQL) for FREE.
Nothing to see here, folks. Just move along.
It's not bad to get 'accurate data' *AT THE TIME OF QUERY*. That's something a lot of people forget about. When you issue your SQL statement, it's the state of data at the time of the query. Things can still go on and change the state of the data, and you can't account for that while your query is running, for you'd never know when to stop your query.
There are also several databases that always know simple things like table counts, or distinct counts of specific fields. One nice one I played with a few years back was the Nitro EDB. Billion record table sets and subsecond response to things like select(distinct somefield) from sometable where _some_daterange_. It maintained hierarchal indexes and some sensible aggrigation.
Here's some thoughts I have on this strange dichotomy between 'schema' and 'indexes':
I see that there is unstructured data, and lots of ways we want to access said data. To access data quickly, we need to index or order it according to some principle. Different needs require different organizational principles. The original structure of the data is logically nice from an aesthetic perspective. E.g. a normalized database with referential integrity makes it easier for us to conceptualize casgading deletions, but it doesn't do much to improve query time. Snowflake and other transformations make the data conceptually closer to analytical use-cases for the data (but harder to load and delete). Then there's the behind the scenes indexes. I find it very difficult to determine exactly *how* an index is being constructed. Is it balanced? How does it optimize itself? I don't like spaghetti-pasta wall approaches like 'drop the indexes and re-create them to see if they're faster'. That's not computer science. It seems to me that an RDBMS should focus more on really great index construction. Keep the data in a form that's very easy to load, change and dump. If that's 3NF, 5NF, something else, great. But the key is just to create a system we can rapidly load, change, dump. After that, let's enter indexland, where we abandon querying our load/change/dump schema, and instead set up some extremely fast, highly space inefficient structures to let me at my data with blinding speed.
There are so many tools for managing schemas, and so few tools by comparison for seamlessly working with indexes. Can anyone tell me which indexes are better/faster under which conditions for MySQL's different engines (InnoDB vs. MyISAM for instance)? MySQL's on-site training couldn't tell me! It's too black box.
I remember using a java Arraylist once as a Fifo queue, and found that if I enqueued a bunch of objects, there was a tremendous non linear slowdown as the implementation of the Arraylist was terrible (it copied itself to new arrays as it grew). And I found out it was O(N) on an element deletion (dequeue), so if I dequeued, I'd have a thousands object reference copies to recon with.
Why don't they even tell us the time complexity of different operations on these index implementations? It seems silly we have to do experiments to reverse engineer these basic things at this point.
Am I right here?
IIRC, EULAs are considered void in Australia because it's a contract occuring after the monetary transaction. After you paid, there is no way additional conditions can be added.
When you buy downloadable software, you are given the chance to review the EULA before you enter your payment information. Should this ruling against EULAs stand up in court, I can see Amazon or foreign counterparts doing the same for boxed software under heavy pressure from major BSA publishers.
"But what about retail sales in person?" The United States has enacted the Digital Millennium Copyright Act and has imposed identical conditions on Australia through a recent un-Free Trade Agreement. Under the DMCA, decrypting a copyrighted work is an exclusive right of the copyright owner. This means that a retail software transaction can now be decomposed into two separate offer-acceptance-consideration sequences: The first is a regular sale, where money is traded for a box containing a disc. The second is a license or licence to decrypt the installer, where your rights are traded for decryption during the install process. The disc is useful only as a toy until you enter into this second contract.
Even if this DMCA-based theory doesn't hold water, nothing stops a publisher from requiring all authorized retailers to make a working Internet terminal available to customers and putting a conspicuous notice on the packaging: "This sale is subject to your acceptance of terms and conditions displayed at http://eula.microsoft.com/windows/xp". In fact, this method has been upheld in a U.S. Court of Appeals.
the "accurate" data ios still inaccurate by the time you get to see it the real value has changed
Snowden and Manning are heroes.
Yes, those light versions are handicapable.
We do not live in the 21st century. We live in the 20 second century.
if you're moving data in & out frequently, then you should look at partitions rather than indexes.
BTree indexes are usually only useful when you're selecting less than 2% of the data. Partitioning works great with 10%, 20% or even 80%. And can often allow you to move partitions in & out of the database within a transaction.
I agree that updating a snowlake is tougher, but it depends on what you want to optimize for. If you want to optimize for fast & easy retrieval for analysis, you really want to use a star schema most of the time.
I thought that MySQL is a commercial product with dual licensing, GPL and some other. There is company backing, the software is developed money in mind, it is commercial. Commercial doesn't mean non-free .
(Do the editors even have a clue or do they just click "Add article")
min(performance.a)= or b or a b
the meaning full part of the statement is that over "all possible methods derived from objects
a or b" this really means you need to extend the case to of best/worst case analysis to all
polynomial bounds the "meaningful problems" presented to by objects a and b.
It would be more acceptable to leave out COUNT(*) functionality than to do it wrong. (Yes, if it gives an number other than the number of rows committed to a table it is wrong. "Weird" is what you call LISP.)
or leave it in and give lots of documentation about why it does what it does for developers to be aware of it... this was news to me.
Can we get over mysql already? Even sqlite is a better, and faster, database now. It's ACID, which mysql is not: http://www.sqlite.org/lockingv3.html
And Postgresql is far more robust and performs just as well.
What does mysql offer any more that the other OSS databases don't? Is it just that it's the M in LAMP? I'm so tired of hearing about Mysql, and all the Mysql drama, when it's just a shitty database that has a lot of mindshare.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
Berkeley DB is not a relational database. It is a key/value pair database, much like a set of files in an individual directory in a filesystem. Apples and oranges :)
I don't see how the inability of the person who started this thread branch to read documentation is a technical problem with MySQL. COUNT(*) works correctly in MySQL, giving an accuate count of the number of items.
When you hear politicians talk free trade, that free as in "free beer for all my buddies, courtesy the taxpayers", not free as in "free speech".
I'd expect PostgreSQL to utterly ace MySQL feature-for-feature. ibFirebird probably not, but it should still scare the "serious" databases on some points. Serious is not an accurate name. Perhaps "attitude-encumbered" or "reputation-enhanced" would be better.
Performance depends so much on what you're doing that it's easy to fudge up benchmarks to make your pet DB "the best". I'd like to see some real-world application benchmarks done by someone with no axe to grind, 'coz I reckon there'd be red faces all around. (-:
Got time? Spend some of it coding or testing
I can picture Arjen grinning as he rea dthat. (-:
.org domain (parent of SlashDot's domain, of course) is run on it.
OTOH, the same can be said of PostgreSQL, and nobody has yet. The
Got time? Spend some of it coding or testing
It's just not true. If you are working in a transaction with higher isolation level than read committed, the locks will hold until the transaction is committed.
The whole point of using an ACID RDBMS is knowing you're dealing with accurate data and not guesses or estimates.
If you want to distribute MySQL with your application to a customer, you have to pay a license fee. That means that for many people, MS SQL Express may be better.
If I wanted to do some complex database logic, I'd probably consider MS SQL Express, as stored procedures on MySQL haven't been out there for long.
If you are building a database to go on low-cost LAMP hosting, MySQL does the job well.
For a piece of shareware requiring a small database, something like SQLLite is probably better than these options.
Comparing the free offering of SQL Server to the full version of mySQL is just about as biased a comparison as Microsoft's "Get the facts" campaign..
I am the maverick of Slashdot
If it's an in-house web application, and he's not distributing it to a third party, the GPL requirement to distribute code along with his application no longer applies. The users are using the services the software provides, but at no time is it distributed to them.
Of course, GPL 3 works around this by applying to web services as well as software distribtion. So it's just a question of when / if MySQL AB adopts GPL 3.
Those contracts (which usually go through some dunderhead in legal) are quite specific in what you can and can't do. For example: They may specify the number of seats, if and in what form the db may be connected to the internet, or even the business in which the product may be used for.
Those are very much legal contracts and have (even though you may call it an EULA) not a helluvalot to do with shrink-wrap or click-through EULAs.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
That whatever database you choose or if you change your mind, you can use a Free(LGPL) Kettle to build your data warehouse on it or migrate it :-)
Homepage: http://www.kettle.be/
Project page: http://kettle.javaforge.com/
Cheers,
Matt
News about the Kettle Open Source project: on my blog
What Express does not include when compared to SQL Server SE and above is Analysis Services, Reporting Services...
It's worth noting that free version of Reporting Services will be included in the Express edition soon.
Many of the free commercial apps include more restrictions..
MySQL is available under the GPL _OR_ a commercial license..
If you include the GPL version for free, you must comply with the GPL same as any other piece of GPL code, that is give away the source code too.. So if your using MySQL unmodified, you just give a copy of the source tarball, easy.
If you need to modify MySQL, and merge it with code you'd rather not release under the GPL, then you *can* buy a commercial license and distribute the whole package as a proprietary closed source app.
The free commercial databases may let you distribute the binaries for free (or they may not, not sure of the licensing terms) but you certainly can't modify them, so you don't gain anything you wouldn't already be able to do with MySQL. After all, if your distributing an unmodified copy of MySQL why would distributing the sourcecode hurt you? people can just download it from mysql.org anyway.
On the other hand the commercial free versions may place restrictions on redistribution, and that may cost you more too.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Read more about MySQL licensing.
that this is a terrible review, there really isn't much option for the average site.
Have you checked the licenses on Oracle for instance. If I remember correctly, the commercial license prevents publications of benchmarks without approval from Oracle.
Having said that, if *I* were supreme overload of database comparisons, here's what I would do:
- Decide on a reference hardware platform in both 32 and 64 bit. I would also include a non-x86_64 hardware platform such as pSeries. Of course this will limit the SQL Server tests but that's Microsoft's own choice.
- Also decide on a common disk layout for the databases. Many commercial databases and even PostgreSQL will perform poorly out of the box on a flat disk layout. Seperate index, data and logs on unique volumes. If you decide to go RAID5 for any LUN, stick at least 6 disks under that LUN. RAID1 for log files. You also need to decide on which filesystem you want to use. This all of course determines which OS you use. I'm assuming Linux in this scenario. Most PostgreSQL recommendations I've seen recommend XFS on RAID10 but RHEL and SUSE don't include XFS support without going unsupported with the vendor in a kernel recompile.
- Bring in a skilled DBA for each product. It shouldn't be too hard to find someone who wants to get published in his respective product.
- Provide no OS tuning except the defaults recommended by the manufacturer of the database. OS tuning varies from vendor to vendor. Some suggest SHMMAX to be one setting while others suggest another number. You can't compare apples to apples when you've tuned I/O at 64k blocks for DB2 and 128K for Oracle (not that you would for either).
- Test all workloads. You may notice that some vendors provide a different product configuration for DSS, OLTP and OLAP. Some vendors even provide a different version of the product for a specific workload.
- Use the same DDL where possible. Really think about this for a moment. Alot of tests I've seen determine raw select, raw insert and raw update speeds but don't take into account the complex DDL that most business have. Take our layout for instance:
1) We have an OLTP system.
2) It also has a schema for OLAP that is populated by triggers from the OLTP tables.
3) We load our warehouse off of the denormalized tables and also provide the OLAP functions within our application from those tables. (Our warehouse is updated each morning but we have a requirement in the application for realtime data for the current business day)
Now with those above requirements, INSERT and UPDATE are going to perform much slower than what a raw benchmark would tell me and IMHO is much more indicative of real world design.
- Note which "levers" you have available to pull. With DB2, I can put specific tables on different LUNs via tablespaces. I can also assign tables and indexes to different bufferpools. Quite honestly, I can't do any of that with MySQL (well with InnoDB I can via some symlink madness). I can accomplish the tablespaces option with PostgreSQL but not the unique bufferpools for certain tablespaces or indexspaces.
- Also note what maintenance is required to actually keep the database performing. REORGs in DB2. VACs in PGSQL. I can update and insert 10mil rows to DB2/MYSQL/PGSQL but what happens when I need to go back and select out those rows? This leads to the next test:
- Test the optimizer! This is probably the biggest thing for me. How does the optimizer determine which access path to take? What factors influence that? I would not intentionally write shitty SQL but developers aren't DBAs. They don't normally concern themselves with the BEST path or even the quickest path to the data as long as they get the data they need. Don't talk to me about OR functions or LEFT OUTER JOINs that I've seen spit out by ORM products or worse yet SELECT * and doing the logic in the application. Run EXPLAIN plans on all queries you're testing. In the end, the optimizer is the biggest factor in the database per
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
The software company's solution to that problem, shuld it happen in the US, would be to buy off congress to get this to happen:
Wal-Mart Clerk: Are you over 18, yes or no?
You: Yes
(Wal-Mart Clerk presses a button on her keyboard.)
Wal-Mart Clerk: Do you agree to the EULA, yes or no?
You: No
Wal-Mart Clerk: Sorry, I can't sell it to you.
Usurper_ii
Ron Paul
Not really. Neither MySQL nor PostgreSQL were "designed" to compete with commercial databases. That they do on some level is nice, but you'd be hard-pressed to find a DBA that really believes that they compete (OK, well, PostgreSQL is there in a lot of ways).
Me: Here's five bucks, your hourly wage.
Clerk: (clicks "yes") Thank you, come again.
Personally, I just have my cat click the Agree button. (Or rather, I leave for a while and when I come back, the software installed itself without me seeing the EULA. Prove that that didn't happen.)
My other car is first.
Is there any open source in memory database?
Prefereable fast and stable?
I find it silly if people run benchmarks with real database software,
but in setups where all the data would fit into the ram of the server -
even several times. In memory databases could be a lot faster for those
situations.
Also it would be nice to see some setups that are realistic, i.e. at least
the data doesn't fit into ram, maybe even setups where the indices are too
big to be kept in ram completely all the time. Would be interesting which
databases still work acceptable in such situations.
Example where I have that: backup servers.
The "file" table with all files backed up and still kept
somewhere on tape is about 10-15gb, and of course the server
is 32bit, dual xeon, and only 4 gb of ram.
However, nothing is stopping me from writing my own client libraries under whatever-the-fuck-i-want license and using those instead of MySQL's license. Unless MySQL completely sucks, it does the "hard" stuff in the server... the client libraries just send commands to a socket or named pipe.
This means I can write a completely commercial MySQL app, and not GPL any of it. (If you disagree, remember that connecting to a GPL'd webserver from IE doesn't require MS to open IE's source code.)
<sarcasm> Damn the client-server model!</sarcasm>
My other car is first.
Like most slashdot articles comparing things, this is an apples vs. oranges argument. Look at some of the comparisons when they line them up side by side. Some of the comparison factors are completely useless and only present to make MySQL appear better than it really is. I'm a MySQL fan, but I'm also a fan of using the right tool for the job. If you use MySQL in a production environment, you better hope you never need to expand much. MS, IBM, Oracle all provide migration to beefier versions that will do a whole lot more than MySQL and thats what their express/limited versions are targeted towards. Migration to a better product as the need arises, without having to restructure your applications.
Most who really care about distributing proprietary software charge money to their customers & can pass the license cost of a database off onto the customer. The lowest risk option would be to NOT develop your own libraies.
Of course, if they can't justify the cost, they should just use postgres or some other database whose license conforms to their needs.
For those committed to using MySQL clients for free in a proprietary app, the best bet is probably the legacy "public domain" version (I suspect these are the old LGPL libraries, but haven't looked more closely).That is how I read the GPL, but IANAL & that isn't how MySQL AB (who has lawyers) reads the GPL. They claimI personally don't think it would be worth the risk to test this & would be conservative. If I was making proprietary software, I'd either pony up for the license or choose another database.
From the definition of a relational database (below), the reviewer clearly has no clue what he is talking about:
Relational Database: A collection of "related" databases, for example and travel agent booking system consisting of customer, airline and account details, can be combined and would be referred to as a Relational Database.
Slashdot title suggests lab testing - special environment, procedures and so on. TFA is nothing like that - just a summary of features and prices.
So far, the only serious test of MySQL I have seen is jAppServer2002.
I expect TPC-C results for MySQL to be published in 2006, unless Oracle bought Innobase only in order to kill it.
Laugh your heart out.
I've got 3 mission critical banking applications running on Sybase 9. Works like a champ with little or no maintenance, and almost never crashes (unlike MS-SQL which we also run).
Didn't have a choice though. As an earlier poster mentioned (rightly) usually the application vendor 'decides' what SQL server you will be using for their app. Mostly this is due to support issues and not technical issues.
I don't know how Oracle could possibly "get you" if you published benchmarks of your APPLICATION when using each RDBMS, as long as you are careful not to go into too much detail about your database implementation.
As long as you talk about app performance and steathily avoid flogging Oracle, then you should be O.K.
Dup;licate. Dgguplicate. Duplicate. Duplicat5e. Du5plicate. Duplicate. Duplicate. Dugplicate. Dup5licate. ;Duplicate. Duplicate. ;Duplicate. Duplicate. Duplicate. Duplicate. Duplicate. Dueplicate.e Duplic5atee Duplicate. Duplicate. Dup5licate. ;Duplicgate. Duplicate. 5Duplicate. Duplicate. Duplic;ate. Duplicate.
Duplicate. Duplicate. D;uplicat5e. Duplicate. Dupleicate. Duplicate. Duplicate. Duplicat5e. Duplicate. Duplicatee. Duplicate.
Duplicate. Duplicate. Duplicate. Duplicate. Dugplicate. Duplicate. Duplicate. Dupli5cate. Duplicate. Duplicate. Duplicate.
Duplicate. Duplicaete. Duplicate. Duplicate. Duplicate. Duplicate. Duplic;ate. Duplicate. Dupligceate. Dupli;cate. Duplicate.
Duplic;ate.
Duplicate. Dueplicate. Duplicate. Duplicate. Duplicate.
Du;plicate. Duplicate. Duplicate. Duplicate. Duplicatge. Duplicate. Dup;;licate. Duplicate. Duplicate. Duplicagte. Duplicate.
I think that PostgreSQL and Firebird are good candidates in a lot of bussiness/academic/websites situations. Why PostgreSQL doesn't appear in benchmarks?
"how to make a toy from a DVD" - zero hits.
Tried the first few results from aol cd uses?In that case, if you use MySQL as a datastore in your application, you will need to buy a "commercial" licence, in order to avoid having to GPL your own software.
And what's so bad about GPLing your own software? There are business models other than that based on restricting copying and redistribution. For instance, Sun is distributing programs as free software and making money on hardware and support. A developer of Free enterprise automation (CRM, ERP) software, which in the proprietary world costs in the five or six figures per installation, could charge for labor during the inevitable process of customizing the software to fit a given company's existing processes.
And speaking of process, given what I know about MySQL, it'd be easy to make a client that operates in a separate process through a pipe: SQL in, tab-separated out, making two mere-aggregated programs whose licenses do not interfere.
Comparing column name lengths is only important if one falls seriously short (like 5-chars) or if your organisation wants_to_name_all_of_their_columns_with_a_very_lo
I can just see managment deciding that to pick a database based on the chart and not based on things like performance, true scalability (not the glossy version), and as others have pointed out: Application Vendor's recomendation...
I'm not saying mySQL doesn't have a place in the market, just that they compared a Toyota with a Ferrari and discovered that both had doors, wheels and engines, but oddly one cost more...
If you think imaginary property and real property are the same, when does your house become public domain?
even the crippled versions of DB2, Oracle, and MSSQL still have the underpinings for advanced features that MySQL doesn't support.
This comment is an exact copy of a post made 45 minutes later then this post. The only change I noticed was the word "Actually" was removed at the beginning. Mod this post DOWN.
FTFA: "Indeed it is probably a little unfair comparing MySQL directly with the low-end products from the other vendors as MySQL has been built to compete at the high end with the other vendors' enterprise-class databases."
The article didn't touch on how procedural SQL (i.e. PL/SQL) support in MySQL compares to that of other vendors. Pretty important if anyone was considering migrating.
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
"SQL Server Express is one of two free databases we tested and is actually Microsoft's replacement for its earlier free offering the Microsoft Desktop Engine (MSDE) which was based on the old Access technology"
Huh? How are we to believe an article that makes such a preposterous claim? MSDE IS SQL Server 2000 with a restriction on the number of concurrent connections. Makes me take the rest of the article with a grain of salt.
-k
Of course you're right. But you know, Microsoft and Oracle would never do something like that! I'll believe database benchmarks when Consumer Reports does 'em.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Comment removed based on user account deletion
Correctness covers a lot of things. You could even put transactions under that category (correctness of data at query time), for example.
Also, if you were worried about free (as in beer) databases, Microsoft (note that I didn't use M$ like a child) has offered a free RDBMS for a long time (Access, which was replaced by MSDE, which has been replaced by SQL Server Express). So, while MySQL *is* a free alternative to SQL Server, I would argue that your product selection to meet your criteria was flawed (as you didn't actually consider various free alternatives).
And yes, for some queries, MySQL is documented as being able to return incorrect values (as another poster has said). In fact, you should check out this site to see what all else some versions of MySQL do for you that are.... unexpected.
IMHO the real reason vendors like Microsoft and IBM offer the no/low cost versions of their database engines is for vendor lock-in. You write a small app, you're not going to buy an enterprise license right away. But by the time you need one you're locked into that DBMS. Or even if you need a big server dbms right away you might need to have part of the app run on laptops that aren't connected to the main server all the time, so of course you will want to use the engine your developers are comfortable using and administering. In that context this review makes a lot of sense. I think the low cost offerings, albeit slightly crippled, are excellent marketing by the big guys. Eventually a percentage of applications will grow into the big money licenses.
So we have "this review sucks" and "MySQL vs the world" debate all at once, which is a great treat for breakfast.
Yeah, alright, the review sucks. Not the first time and not the last time that someone posted something without reading it, and many people post replies without reading it, too. This still doesn't beat, in my book, the "nanotech sticker extends cellphone batterly life" post from a year or two ago that I can't seem to locate now...
As for MySQL, I have the same thing to say about it as I do about Windows; just because it's popular (even if I'm using it... teehee) doesn't mean it's good. It's just popular. This is true of everything. Our selection criteria is flawed, based on incomplete or flawed information and on the wrong reasons or reasoning (and, IIRC, on published benchmarks done without record locking, which all the other database vendors generally do not even allow to be disabled). That and the whole "what's better for you isn't better for me" deal - Slashdot is, after all, a biased audience.
To give a non-technical example, I believe that it's been shown a while ago that, on average, the nutritional value of fruits and vegetables available in your average supermarket is declining, because consumer preference selects for size and colour, which are at best loosly correlated with nutritional value. I'm not saying that software is getting worse - even Windows and MySQL continue to improve, but the aspects of the products that the consumers at large base their software decisions on are only loosly correlated to the quality of the code and the listed functional features of the software.
And that's my breakfast rant.
Even as you read this, your pants are strangling your loins! Aaa!
I hope the author is just trying to dumbify the article for an audience of PHBs...
EULA violations would come under contract law, which is a subset of civil law. All they have to meet (at least in the US) is preponderance of the evidence -- there is a greater than 50% likelihood that their version is correct -- and they win the case. Once they've presented their argument ("It's nearly impossible for the defendant to have walked away after inserting the media, only to have his cat press exactly the right series of keys to fully install the software"), it's then up to you to refute and show that this is more likely to have been the case.
Chances are that you would lose.
You can never go home again... but I guess you can shop there.
I don't know where you work, but every place that I've worked, I could call a sales rep and get an evaluation version for free. I've done this with Informix and Oracle, I'm sure it's true with DB2 as well (not so sure about SQL Server). They're usually pretty liberal with the trial period too, and the Informix guy kept wanting to send me one of their support engineers to help me port my data over.
Just junk food for thought...
They use MySQL V4.1.14 for their info, and feature comparison. Then in the conclusion the recomend V 5.0. WTF?
If your going to do comparisons, at least pick the best from the set you're comparing.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
ok, i shouldn't have gone french here... -lol-
health insurance *is* a problem in america. a *huge* problem.
health insurance for an employee can easily exceed $1,000 per month... and growing at about 10% per year.
sure, we in america have decided to mask all our financial mismanagement and thievery by setting up our grandchildren to be slaves to our debt... but that doesn't mean the disaster isn't right there... lurking.
health care costs aren't the whole problem, but they are a major portion of the problem... and getting drammatically worse over time.
Perhaps you haven't heard yet:
Version 7.4 (or 7.3, I forget) had the option of autovacuum as a standalone daemon.
Version 8.1 has autovaccum fully integrated into the product.
Effectively, the administrator hasn't had to worry about manual vacuums for well over a year.
- I don't need to go outside, my CRT tan'll do me just fine.
The reviewer should have factored in the cost of the hardware. After all what good is an application without the hardware. Why did they choose to use a quad Xeon box? I'm estimating $15-20K for that which brings the cost of MySQL to about half the cost of DB2. Also how do the different engines compare running on different hardware? I know that MySQL runs much better on an Opteron box than a P4 box of the same price point. Is that true for the other database engines? Does DB2 perform better under Linux or Windows 2003? Etc etc.... There are just too many holes in the review to take it seriously.
Genius. This is my new defence. :D
Of course they don't ever mention the issue of getting developers who know the product.
How many DB2 developers are there out there compared to the other platforms?
I've got pretty used to the anti-MySQL crowd around Slashdot. They will go quite out of their way to find bugs real or imagined. I've been using MySQL for five years now as the base of our company's custom billing software, which I originally wrote to work on top of Access. I've had one corruption in all that time, which, considering the hard drive died a week later, probably had nothing to do with MySQL at all. Providing you understand how to construct indexes and queries, the performance is quite good. Perhaps it's not as good as Oracle, but I find with databases that hardware plays a very critical role as well.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Yeah, and they didn't compare Sybase XE either, which from my experience is as robust as Oracle XE but allows more freedoms than Oracle XE. I use Sybase XE over MySQL for smaller projects because the MySQL query optimizer is a joke, and most "benchmarks" that show MySQL to be faster are doing real basic selects. Try joining three tables with foreign keys that form a triad and see how the databases perform, MySQL will most likely take a few hours while the commercial databases finish in under a second.
Mysql is great for development and for non-commercail sites...Over the past couple of years we have seen too many sites go down and DB's corrupt when someone hits the EPO(emergency power off) button at datacenters. The fact is under real load until recently it wasnt even a contender, and don't argue with me about your site and a Million page hits, Im talking real loads.
I do all my fun projects on mysql, but when it comes to busines and production environments I run Oracle(Linux) and MSSQL. nuff said.
Didn't anybody edit that before they printed it?
Only features.
They used the "lite" versions of expensive databases specifically to compare featuresets of semi-affordable databases.
The "real value" isn't allowed to change until you commit or abort your transaction" (unless the database can prove you would never see the difference). Preventing clients' updates from interfering with each other's work is half of what a database is for.
The other half is making sure that what you read matches what you last wrote. Early on the MySQL developers grew quite a reputation for being careless about both of these.
Just so's ya know. I just like to actually have the game if I'm going to have the name. That was the whole point of that second post... that was real overrated flamebait! Note how the supposed "flamebait" post got no replies, but you replied to this one!
Hell, I don't care if anybody listens to me, and I'm not out to prove anything. I say what I mean and mean what I say (well, usually) and don't really care if I get modded up or down, I've got /. karma to burn. Sometimes, not all the time, I just like to stir the shit.