Slashdot Mirror
MySQL A Threat to Bigwigs?
Disoculated writes "Is MySQL a threat to bigwigs? is the question asked in CNN's technology section. The article notes that MySQL is running perhaps 20% of the web databases but its revenue is merely 0.02%... yet the company is still making money and putting out an excellent product. Is this a sign that the database market is in for a drastic change? Of course, there's no mention of PostgreSQL or mSQL, but I guess that's typical."
Sorry.
The GPL, one of the licenses under which MySQL is distributed, states that if you re-distribute it, you are also required to share the changed source code.
My complaint was that the article was imprecise. If a company changes, but does not re-distribute MySQL, they are under no obligation at all, ethical or legal. If they re-distribute it then they are under a legal obligation to share their changes to anyone who uses it (not just MySQL AB).
J'aime mieux les méchants que les imbéciles, parce qu'ils se reposent. -- Alexandre Dumas
The GPL does not merely give you an ethical obligation to share your modifications with anyone you distribute them to. It gives you a legal obligation. Until shown otherwise by a court, the GPL is legally binding. As such, stating that the (presumably only) obligation that someone modifying the code has in an ethical one furthers the outdated notion that all pieces of Open Source Software are amateur projects that are only held together by people who choose to donate their time for whatever higher reason. Not that there is anything wrong with volunteering your skills, but there are major businesses investing time and money in OSS.
From a business standpoint, OSS is legitimate. It would be nice if CNN reported it that way.
Note: I contacted CNN.com regarding this when they first posted the article. Predictably, I have not yet received a response.
My legal education, in nifty podcast format
MySQL is a phenomenal product, in terms of just how much a small to medium size business can accomplish with it, for so little cost.
;)
Having to use a data-storage solution like Oracle is simply unfeasible for anyone but large companies. I've been using MySQL for 3 years to build web applications, and I've never had a crash or corrupted data. The only problems I ever ran into was when one of my systems had a table get to 2GB on the 2.2 kernel, but that wasn't MySQL's fault
With the inclusion of InnoDB, MySQL definitely becomes a threat. The main problems I've run into with MySQL is backing up/restoring without locking up the whole system (table-level locking). InnoDB of course removes this!
I see no reason to use Oracle over MySQL for anything but the largest system. Then again, why even that? Doesn't Slashdot run on InnoDB...?
I moderate "-1, Fool"
That's hard? Give me a break. MySQL is so internally inconsistent that auto_increment is practically the only atom in the entire data definition syntax that uses the underscore! How about this bit of MySQL genius:
Which is the default: 42, or max(foo) + 1? The statement is internally inconsistent but MySQL allows it anyway. Nevermind the stupidity of requiring a unique index on the auto_increment column.
PostgreSQL has a number of operational problems -- vacuum, toast table indexes, and so forth -- but the SQL syntax is not one of those.
Uhuh.......... CREATE TABLE foo (bar SERIAL PRIMARY KEY); (PostgreSQL)
CREATE TABLE foo (bar INT AUTO_INCREMENT PRIMARY KEY); (MySQL)
In both of the above tables, the bar column will behave pretty much the same way in each database. Yes, annoyingly difficult compared to MySQL because....... the syntax is different? Maybe if the first db you used was MySQL things seem "harder" because Postgres is a little different, but you'll see differences like that moving between any database.
In any case, even though I use Postgres, and prefer it over MySQL (which I have used extensively before), I am happy that opensource dbs are getting recognition out there.
MySQL has the power (pretty much) to replace MS-SQL Server.
OMG, you didn't really mean that, did you? Oh, that's so cute...
MySQL is barely ACID compliant, doesn't support triggers or stored procs or views (just for starters), and you say it has the power to replace MSSQL Server?!?!? For goodness sakes, MySQL just NOW has a shared SQL area (query cache). You gotta crawl before you walk, and you gotta walk before you can run with the big boys. MySQL is a very capable database in its own right, but it's still in it's infantcy.
With some of the best replication and datawarehousing functionality on the market and consistently a price/performance leader, I don't think MSSQL Server is going anywhere anytime soon.
BeFS didn't do it. BeFS had attributes, which was a definate step in the right direction.
The Newton OS did it, with an object database. Down the line, other PDA OSes did it as well- Palm OS and the Helio's VT-OS both provided a database as the only means of data persistence. The Palm OS and VT-OS DB systems are quite a bit more restricted than the Newton OS's OODB or the theoretical system-wide relational DB we're discussion.
Dynapad (my PDA OS/OE) take an approach similar to the Newton OS with an system-wide object database.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
MySQL is very adequate for 99% of all users including most large enterprises and certainly most websites.
u me nts/all/html/db_compare/db_compar_chp01.html
I used to be a big fan of MySQL, mostly because it was moderately capable and free. Now that I have tried Postgres though there is no way I would go back.
Yes, version 4 will be an improvement, BUT it is still missing many key features like views, triggers, full outer joins, update with subselect, that are already present in Postgres, and the fact is I've been using the features that MySQL is promising for the future for a year and a half now.
The following site does a very good comparison between the feature sets of MySQL, Oracle and Postgres.
http://det-dbalice.if.pw.edu.pl/det-dbalice/doc
Sure.
Look here and here. Both of these websites mention what postgreSQL (and Oracle)offers that mysql is lacking as well as how to migrate to PostgreSQL. Keep in mind I am not a database administrator or do I consider myself a sql guru. I only use them to write web enabled apps as a hobby and not in a corporate environment.
However it was rumoured that postgreSQL lacked real backup tools to fix a corrupt database. I believe this might of been fixed but was an issue 3 years ago. This is the only downside I see. Both Mysql and Oracle have tools to fix such a problem. Maybe someone who is reading this who is more familiar with administering databases can comment on this.
http://saveie6.com/
Not to mention column and table constraints, stored procedures, extensible datatypes, user-defined operators, query rewrite rules, and schema and domain support.
- You can find lots of documents online at oracle, but I guess you didnt care
- Speed, MySQL is speedy, because it doesn't have to do anything
- Again, no refirental integry (OOps, I didn't mean to change that foreign key, now I don't know what it pointed too, my database is corrupt! AAARG!)
- Rollbacks are not fancy stuff, they are essential to a real database
- Hardware levels? Ok, go back to your parents basement
With Oracle you can choose: speed, security.Mysql: Speed. Only.
Mysql is like a dragster, fast but no control.
Next time you want to start karmawhoring, at least pretend that you know what you are talking about.
Look here [webtechniques.com] and here [sitepoint.com]. Both of these websites mention what postgreSQL (and Oracle)offers that mysql is lacking as well as how to migrate to PostgreSQL.
The first article was written in September 2001. The second article was written in October 2001. The person who replied to your post cited an article from 2000, almost three years ago. The PostgreSQL vs. MySQL argument would be a whole lot more interesting if the articles cited were actually relevant to newer versions of both databases. It would also be great if they were more than just, "Hey, look, I got my inefficient bulletin board working a little better under database XYZ."
The best database is the one that has the features you need, the performance you desire, at a price you're willing to pay.
that have received little comment so far:
* Firebird (ne: Borland Interbase)
* SAP-DB (ne: Adabas-D)
Both are good, high quality, commercial or formally commercial products released under an open source license. (interbase public license and GPL respectively)
Further, SAP-DB has excellent commerical support available from SAP, the company, at or better than the same level of responsiveness as, say, Oracle support.
Both are fantastic, enterprise level full ACID RDBMS's with all the great management features a heavy duty shop could want:
* online backups,
* transaction logs,
* restore to point in time
* subselects, views, rules/triggers, procedures, etc.
* great storage management
Check 'em out.
-- Pat
The biggest problem with communication is the illusion that it has occurred
I disagree with the idea that small projects should use flat files or XML in place of MySQL. First of all, the flat file only looks good while there seems to be a single entity in the system - let's say person. It rapidly turns into a convoluted mess when a second entity rears it's head - let's say a person can have multiple cars. Second, many applications end up developing reporting requirements that were not envisioned in the original design. That's what makes relational databses great - ad hoc reporting.
Another way to put it - as the application grows in complexity, more functionality will be added to the data store as the programmers painfully rediscover all the challenges which real databases have already conquered. Of course MySQL doesn't cover all of those, like ACID, but it covers most. Look at the amount of effort that went into MySQL, Postgres and Oracle - it's huge.
Of course, you may be thinking of simpler applications than I am. If the data can legitimately be represented by one table, with no denormalization, then I agree a database may be overkill.
Actually, this is an interesting point, but it isn't as valid as you make it out to be. There is absolutely no good reason to embed an RDBMS into an operating system. Not at the level that you are referring to anyways. If you mean filesystem attributes, then that is a different fish, but making a database part of an OS is a bit much.
;)
XML and flat files are good for data that does't change very often, and are only ever edited by a single user. (XML is also a good way to feed data fram a database into an application) Beyond that, they are pretty useless. They require far too much time on the developer's part when data within given contraints are needed, and coordinating updates between multiple processes can easily turn into a nightmare. Not to mention scalability. XML can get pretty large, and due to the non-indexed nature of the data, it can take a long time to read through it all looking for what you need. For many applications, using a database just makes sense.
The whole point of an app using a database is to offload the storage specifics onto another program. I applaude the developers of these "MySQL (ab)using programs" for making the decision to focus on their products features and stability, rather than on how they will store their records. Besides, once you install MySQL (or Postgres) once, then it is there for all of your DB dependant apps to use.
Not to mention the fact that MySQL 4 has standalone features that make your argument pretty moot. Any application can link in the MySQL core at build time, and will be able to have it's own MySQL databases separate from any active system wide MySQL instance. This gives developers an SQL storage system, without requiring the user to install a database on their own. It just comes bundled with the app, and when the app loads, the MySQL core is loaded right along with it.
I'll keep using databases for storage, and flat files for configuration data, thanks though!
Great discussions on this thread! We are reading them carefully to learn what we can do better.
Let me just comment on the overall impact of having such articles appear on Fortune.com and CNN.com:
The article is indeed the result of PR work done by MySQL AB, but the value of it will benefit the entire free software / open source community. We need to get many more business articles out there, so let's be happy about this one, and let's produce more of them!
Although this very article mentions MySQL only, please have a look at other articles where we at MySQL AB consistently mention the other open source databases. Here are two such articles on prominent business-focused sites (one of which, incidentally, is powered by MySQL):
= A2 44_0_1_0_C
http://www.open-mag.com/01943583279.htm
http://www.alwayson-network.com/comments.php?id
Our ambition is not to be a threat to bigwigs per se, but to make superior database software available AND affordable to all. With your help we can do it.
Marten Mickos
CEO, MySQL AB
Simply put, if you expect your web application to get any amount of decent traffic (say 100,000 pageviews+ per day), then MySQL is simply not an option.
FYI. 1.5M per day - we run MySQL. It has and continues to run like a champ every single day for the last 2+ years.
Of course, we've thrown some pretty high-end hardware at it to keep it running this long.
MySQL cannot scale reliably, period. Having two database systems act as a pool, under MySQL, is a crapshoot at best. Unless you like designing single points of failure into your web applications, stay away from MySQL.
Nail on the head here. InnoDB (the real seller for MySQL, since it gives them ACID compliance) *really* sucks under load. It starts chewing itself apart. Funny to watch, not funny to clean up - since you really can't.
We've been using replication in MySQL for backup purposes. (The replication has always been reliable for us) We can take the slave down for snapshots. But that is *all* we use it for.
MySQL will last us just long enough to finish our PostgreSQL migration.
Hi!
Can you describe the index problem in more detail? Please send a bug report to mysql@lists.mysql.com.
- What MySQL version did you use?
- Did CHECK TABLE report the table ok?
- What kind of SELECT queries did you execute and what did they report?
- Are you aware that in the AUTOCOMMIT=0 mode you have to COMMIT your read transaction to advance the consistent read timepoint? Some users do not know this and then wonder why committed data is not visible in another connection. InnoDB serializes read-only transactions at a precise timepoint so that all consistent reads are really consistent with respect to each other. The default transaction isolation level is therefore called REPEATABLE READ.
Best regards,
Heikki Tuuri
Innobase Oy