Today we features a mini-Q&A with Alex Roedling, MySQL‘s Senior Product Manager, about all things MySQL, the competition, technology, licensing and more.1. The new mySQL license is said to not be so compatible with PHP and other software that mysql works together. Is this the case?
Alex Roedling: MySQL offers licensing that is compatible with the licensing terms of most software. MySQL AB has two licensing options:
– For software with proprietary licensing, MySQL offers a proprietary license.
– For use with Free/Libre and Open Source Software (FLOSS) such as Linux and PHP, MySQL is available under the GNU General Public License (GPL).Some FLOSS licenses (e.g. BSD-like licenses used by PHP and Apache) are not compatible with the GPL. To allow for greater compatibility with FLOSS licenses, MySQL provides a special exception to the terms of the GPL. This enables non-GPL software like PHP and Apache to use MySQL.
2. Are there any of the issues mentioned here being worked on by your engineers?
Alex Roedling: Like all successful databases, MySQL has its own dialect of SQL. The above is a listing of the idiosyncrasies of our dialect. With MySQL 5.0, we will give users the flexibility to continue using the MySQL dialect, or to set a “strict SQL2003” flag if they want to only use standard SQL-2003.
3. How much external help you had from individual contributors after MySQL became open source? Do you get a lot of patches from third parties?
Alex Roedling: All of the contributors to MySQL are employees of MySQL. The MySQL codebase is ‘owned’ by MySQL which is what enables MySQL to implement the dual-licensing model. However, we do get a lot of feedback throughout the development process from our vast user community. Essentially our community acts as a very cost-effective testing and QA resource.
4. Please explain to us the MaxDB concept and how it differs from the Plain mySQL version.
Alex Roedling: MaxDB is MySQL’s SAP-certified open source database. MaxDB enables SAP customers to significantly reduce their database Total Cost of Ownership (TCO). For an example of how MaxDB reduces costs of an SAP implementation visit here.
MySQL Server is MySQL’s general purpose open source database that is widely used in web applications and embedded systems.
5. Can’t help it but compar your business to Oracle’s. What’s the best Way to “steal” Oracle’s business long term? What is your strategy?
Alex Roedling: MySQL has an enormous user base consisting of 5 million users and 5000 commercial customers that we are focused on making successful. So, our roadmap is focused on satisfying the emerging needs of our existing users and customers. For example, MySQL recently released MySQL Cluster which satisfies our customers requirements for high-availability as they rely on MySQL for their mission critical applications.
Many Oracle (and other database) customers find that MySQL is very cost-effective, highly reliable, easy to use and administer database.
6. Please tell us about the new features to be found on mySQL 5.x. Is There an ETA?
Alex Roedling: The major new features of MySQL 5.0 are Stored Procedures, Views and Triggers. A Development version of MySQL 5.0 for previewing and testing new features is currently available for download. The production version is scheduled to be available in early 2005.
The major new features of MySQL 5.1 will be Triggers. A Pre-release version of MySQL 5.1 is scheduled for early 2005 and the Production release will follow late 2005.
7. While MySQL is wildly popular, many insist that PostgreSQL is “better” in a number of ways, however they accept the fact that mySQL development moves faster than PostgreSQL so it catches up quickly. Are you happy with the pace of development, and how do you see your competition to PostgreSQL, Berkeley and FireBird? Do you face it the same way you would do with commercial DBs like DB2, Oracle, SAP etc?
Alex Roedling: We take a customer focused approach to development regardless of who our competitors are. We enhance MySQL based on the needs of users and customers without sacrificing the primary features that has made MySQL successful; reliability, performance and ease of use. One thing we hear our customers say over and over is ‘It just works’. Our customers have been running MySQL for months, even years without any issues or downtime. By listening to our customers and focusing on maintaining reliability, performance and ease of use, we have a winning strategy.
8. According to your engineers, what is the “next big step” in the Database technology in general? What’s the next big thing?
Alex Roedling: 64 bit computing and affordable database clustering for high-availability (99.999%) computing is where we see the next big wave of adoption. Keep in mind, MySQL is in the commodity database business – we provide 80% of what the ‘Big 3’ (Oracle, DB2, MS SQL) provide at 10% of the cost.
If by 80%, you mean 20%, then yes. 😛
I don’t think anybody accepts that mySQL development moves quickly. People have been asking for subqueries and stored procedures for a long time now.
hi, in norway we learn access before we start with mssql. are there any plans for making an light sql with frontend like access?
His answer to question 2 left me speechless.
The MySQL Gotchas page doesn’t merely list idiosyncracies of particular dialects of SQL. It lists several fundamental flaws in the MySQL design, such as transaction handling, NULL handling, input validation, etc. That he sidesteppped the question is truly appaling.
This “interview” was really just marketing fodder. It was completely devoid of any substance.
Bjorn asked:
“hi, in norway we learn access before we start with mssql. are there any plans for making an light sql with frontend like access?”
Actually a GUI already exists for some administration tasks.
If you are looking for something to restructure a mySQL db using PHP, I would suggest PHPMyAdmin (see http://www.phpmyadmin.net/home_page/ )
If you were more intereted in the VB based frontends that can be made through Access itself, I can’t answer that…but sure would be nice.
well it more like “Bergen’s CTO: Why we moved to Linux” http://www.zdnet.co.uk/print/?TYPE=story&AT=39157746-39020463t-2000…
and
Norway’s second city embraces Linux
http://news.zdnet.co.uk/software/linuxunix/0,39020390,39157677,00.h…
if we are using linux, and then we use openoffice, well openoffice dont have that db and frontend like ms access have. soo i wos wondring if they are going to make an small db with a good front end for “home users” like ms office have in access.
What are the main differences and the advantages of each? I’ve always used MySQL because it’s free, but now I’m curious.
OpenOffice can connect to MySQL though OBDC. It then behaves and acts very much like Access.
Access can also connect and be used as a front-end to a MySQL database. Do your research.
(and if you’re looking for an equivalent to phpMyAdmin, try PhpPgAdmin)
How can they grant exemptions to PHP, I thought that part of the LGPL was that rights can be taken away? Do they just say “you can use it”?
Before this MySQL licencing guff I didn’t consider the user benefits of choosing OSS software with many authors. It’ll be one of my considerations in the future. MySQL changed the conditions, and people were surprised. It’s not like nothing happened.
IMO there are several new things that MySQL/Postgres should work on. XML datatypes is an obvious thing, for example, storing a gig of xml and being able to extract a node as part of the query. The coming overlap between newer filesystems (ReiserFS, WinFS) and databases will be interesting to see.
“We take a customer focused approach to development regardless of who our competitors are”
Heh. The whole answer to question 7 is pretty funny. I wonder if there should have been more consideration of the audience… it’s Osnews.com you’re responding to, not CNet
MySQL –> free (GPL) or for-fee (commercial), fast SELECTs, just recently supported transactions, no subqueries/stored procs/views/triggers in current stable version, supports many platforms (including FreeBSD,Linux & Windows)
PostgreSQL –> free (BSD-like), good overall performance, supports transactions/subqueries/stored procs/views/triggers/lots of data types, supports only UNIX (no stable native Windows version yet)
MS SQL –> works only on Windows, not free (of course), good overall performance, supports transactions/subqueries/stored procs/views/triggers, built-in full-text search engine, OLAP capabilities
Oracle –> supports many platforms, overall recognized leader in performance and scalability, supports transactions/subqueries/stored procs/views/triggers
well that’s all i know
Thanks andre. Very informative.
Pretty bad interview. Certainly not Eugenia’s fault, though — Roedling simply avoided giving direct answers; it almost seemed like he just copied’n’pasted some prepared marketing paragraphs. Very dissatisfying. A perfect example of how the “marketing” approach can fire back at you: When your answers are too general and out of touch with the actual questions, you quickly start to appear as if you’re evading specific issues altogether, which in turn makes you look dishonest and not very trustworthy.
“…openoffice dont have that db and frontend like ms access have. soo i wos wondring if they are going to make an small db with a good front end for “home users” like ms office have in access.”
That’s a very good question. Yes, Access can front a MySql db, though what would be the point, Access alone is so much simpler. So where is an open source solution?
The closest so far may be Rekall, built on QT: http://www.rekallrevealed.org – but it seems they are still in an early stage of development.
I think in the ideal world, if Corel ever opensourced the Paradox database, that would be outstanding, and would become incredibly widespread.
By the way, what has happened to Paradox lately, is Corel even still making new versions?
the whole point of mysql (was) to be fast. so to be fast they sacrificed triggers, stored procs, proper RDBMS relational functions etc.
so now they are adding them in. so now they wont have claims of being the fastest anymore. i would rather they spent all their time on maxdb to bring that up to spec and into the future. it has a better code base than mysql.
i agree with you…MySQL should just spend their time tweaking SAPdb and making it protocol-compatible with vanilla MySQL rather than reinventing the wheel just to implement its features in MySQL 5. when they announced that they were taking over sapdb.org before, i thought that it was their way of getting ready for version 5. apparently MaxDB (formerly SAPdb) and the vanilla MySQL will stay apart for quite a few more years.
what attracted me to MySQL was how quickly it developed…but to be honest i’m getting impatient waiting all these years for the features they have promised. i have since moved on to postgresql and firebird for open source DBs.
I quite don’t see how MySQL 5.0 could be “production” in early 2005 when MySQL 4.1 is still in alpha stage (and there are beta and gamma to go before production).
Contrary to the interview I find MySQL developpment a lot slower than PostgreSQL. It only seems to be catching up on PostgreSQL because PostgreSQL has already most of the feature of a modern database, and hence there’s not much new stuff being added.
(disclaimer : I’m a MySQL 4.0 user, just tired of waiting)
MySQL became the simple DB for most of the websites when the DOTCOM took off initially because you didn’t need stored procedures etc to run a simple website. It you did then you would have gone with PostgreSQL or similar. Its like with a lot of people, they wont change something they are comfortable with using.
Release 4.x will be the database for those who don’t want/need the new features in 5.0
5.0 is a development tree according to their website so it being developed in parallel with 4.1, production release is possibly LATE 2005 so thats still at least another year development and testing.
Right, but MySQL AB (the company) shows no signs of actually fixing any of the issues listed on MySQL Gotchas. Until they address those issues (many of which are very serious), I still don’t see how anyone can use it for serious us. I know people do, and, frankly, it scares the hell out of me.
Lot of java web programmer’s use hsqldb database, its a very light weight database.
For RDBMS databases PostGreSql and Firebird are good.
Firebird lacks a free Replication utility compared to PostGreSql.
Firebird runs well on both Windows and Linux while PostGreSql’s windows port is still cooking.
Currently we are using MySql and been through its gotchas. Soon moving on to Firebird or PostGreSql.
In my personal opinion MySql’s 4.0.18 stable version isn’t all that stable.
Wish MySql could use some simple language when they explain their complex license.
is that mysql was born to be as fast a server as possible – pushing data out. That’s why other more tradition business functionality was left out (like trigers and constraints etc..) Why don’t use mysql as a front end for postresql for websites
I’m just kidding – keep using postgresql of course!
You can have a look at kexi (part of koffice), it uses SQLite to have a simple database engine, but it’s still in alpha.
imho sqlite is better for a simple website database
mysql will still turn out better performance than sqlite when concurrency comes into play, because sqlite will keep opening & closing the database file (and locking it too) for every attempt to update it.
Thanks for the heads up on Kexi – will check into it
I don’t think some (or perhaps most) of the gotchas in MySQL will be fixed (at least in near term). It will break many apps that use MySQL.
MySQL has always had these philosophies: *) don’t complain too much; *) do/pick the best for user, silently if possible; *) easiness and speed comes first, data integrity second.
Imagine the complaints of people when suddenly, for example, they cannot insert string longer than the defined length (MySQL currently just truncates the long string silently instead of returning an error). Or MySQL rejects a large integer that is larger than the integer column size (currently MySQL just inserts the largest allowed value instead, silently).
MySQL just forgives and allows too much, and many users depend on this behavour.
<p>i agree with you…MySQL should just spend their time tweaking SAPdb and making it protocol-compatible with vanilla MySQL rather than reinventing the wheel just to implement its features in MySQL 5.</p>
as if it were that easy
remember, SapDB is a complex and i’d guess is composed of millions lines of code. plus it has been in the hands of Germans for several years, meaning it’s probably even more complex
the MySQL people have been only familiar with the SapDB code for 1-2 years. I don’t believe that they have even fully understood it.
for comparison, the firebird developers spend many months understanding and tidying the interbase 6.0 source code before they can even begin adding features or fixing bugs in them.
Anybody know?
In response to Steven Haryanto: the examples you give can be caught in application code. One thing I have learned through experience is to never trust a backend product to cleanly enforce its limits. Storing bad data (as you say MySQL does) is worse than storing nothing at all while returning an error, so in my view MySQL must change but not for the reasons you state.
It is the responsibility of the developer who creates an application that makes use of MySQL to properly handle errors and validate inputs before they go into any sort of storage. It’s not that much extra work to do proper range checking in languages like PHP.
>In response to Steven Haryanto: the examples you give can be caught in application code.
…snip…
I don’t even know where to start with this one. You may as well NOT use a DBMS, then.
Plenty of people complain about MySQL and how lenient it is on users. Plenty of people complain about PHP for the same reason. It’s not typed. It’s not good for big projects. It’s OO model is a mess.
Well, news flash people. They freakin’ work. They are easier to learn, which means they are cheaper to build in, initially if not forever. And trained DB people always have a coniption fit when anyone suggests that data integrity is optional, even in many business settings. Well, take an economics class, people. Data integrity isn’t something you put on the box of anything BUT a DB. And for internal apps there is no box. It’s about results. And speed of production, ease of install, and ease of maintenance can offset the risk of data loss. Shocking, but true.
Besides, MySQL (yawn) does have transactions, if you care to edit one line of my.cnf to allow for the use of InnoDB tables. It has a binary log for recoveries. And it will run for years at blazing speeds without you ever changing a single default value in the server configuration. It’s not the app for all occasions, but anyone who can’t see the incredible usefulness of MySQL is blind.
That’s like saying that it’s OK if your filesystem were to randomly truncate files or mix two files together. Becuase, hey, it works and it’s fast and who cares if you lose a few bits here and there?
It’s interesting that you make an economic argument about using MySQL. I’ve always maintained that it’s far more economical to use a better-designed DBMS. PostgreSQL, FireBird, Oracle, etc, will all let you put your business rules and integrity checking in one centralized place – the database itself. If you do that, you don’t have to code your business logic and integrity checks into every app (which saves a lot of time and effort, esp when debugging them). I’ve worked on projects which use PHP, Perl, Python and Java to talk to the same database. Why write, test and debug your integrity checks in four different languages when you can do it once?
Most of the time a DBMS is nothing more than a fast way to store large numbers of records and sort/search them quickly.
Many stock webservers from hosting providers come with nothing else than MySQL these days so you’d be screwed integrity-wise. I for one do not trust user input one bit and intend to validate and check it on as many occasions as reasonably possible. The integrity of the stored data is my own responsibility, so my own code is going to do the checking.
The DBMS can be a very good final line of defense against malformed input but ignoring the possibilities of javascript (extremely fast client side form validation) and server scripts (extremely flexible, able to correct many input errors) would seem to me a missed opportunity.
That’s fine, but I would argue that is a very narrow perspective on what a database is and does. You are talking about a database with only one purpose. But, if you have a large general-purpose corporate database, where there often is more than one application involved, as well as possibly more than one administrator, etc… who can perform queries, then that “final line of defense” is absolutely critical.
Also, it’s not just about constraints, but about helping the programmer. If the data model and column definitions of your application don’t correspond properly with that of the database, MySQL will often *not even provide an error message*, but silently truncate strings, or reduce ints, or add weird defaults, etc… For any sort of serious database work, this ought to send shivers down your spine.
Eugenia,
As a PostgreSQL developer, I will happily endorse the idea that MySQL has done some things better than us, just as the reverse is true. But “it’s generally accepted that they have faster development”?!? Huh? Where did that come from?
While we’ve been waiting for MySQL to add all of the features promised in 4.0 (most of which have been put off until 5.0, with no release date in sight) the PostgreSQL community has released versions 7.3 and 7.4 — each of which had 4-5 major new database features. So, by my count, PostgreSQL development is just about twice as fast as MySQL development.
Josh Berkus
PostgreSQL Community Member
That’s like saying that it’s OK if your filesystem were to randomly truncate files or mix two files together. Because, hey, it works and it’s fast and who cares if you lose a few bits here and there?
The analogy is wrong. There’s nothing random here – MySQL behavior is documented and known. If MySQL truncates strings longer than the column they are stored into, then you know exactly what is going on and can adapt your programs accordingly. There’s only data loss if you agree to it. If your code is proper (ie : checks string length before storing them) it will work equally well with MySQL or another database.
As a sidenote MSDOS used to truncate filenames to 8 chars (the tragedy !).
“That’s like saying that it’s OK if your filesystem were to randomly truncate files or mix two files together. Becuase, hey, it works and it’s fast and who cares if you lose a few bits here and there?”
Betcour made the best counterpoint, but even if it *were* just random data loss, it would be in the same category as something like ReiserFS. There are a few horror stories out there, and some people stay away from it because they don’t consider it mature enough yet. That’s fine. But when tens of thousands of people have used it for years without experiencing a single glitch, don’t expect them to go streaking home to ‘fix’ their files servers just because they hear one of those stories. There are acceptable levels of failure even at the FS level. It’s very close to zero, but it’s still there.
People also tend to talk as if “business data” is all highly valuable and irreplacable. Sure, there’s a decent amount of that, but there’s also a bunch that is enitirely replacable because it was imported to begin with. Databases are often used just to munge data, not as the sole repository. Second, many businesses have daily backups. I’m not saying it’s okay to write leaky programs because people should make backups: I’m saying that sometimes people may not give a rip about the possiblity of a program leaking because they know it’s replacable without a lot of work. As long as it’s sufficiently unlikely, it doesn’t even make it onto their ‘cons’ list.
Frankly, one of the reasons I don’t mind the lack of features in MySQL is that I find SQL harder to write than code – and so do a lot of intelligent coders that I know. More elegant perhaps, and even faster at run-time, but if it’s going to take 3 times as long to write, contain more bugs, and be more difficult to maintain, I’d rather put it in code. Not to mention that putting a bit of logic in code means never having to come back to make a ‘minor’ tweak and realize “Damn, this SQL statement can’t possibly be arranged to add that feature.” In which case you are either writing a *lot* more SQL or rewriting the entire bit of logic in code – which means you’ve now done it both ways. Maybe I’m just a bad SQL guy, but I suspect there are a lot of us. Just one more reason why MySQL is perfectly accessible to a huge crowd.
The “SAPdb” code base is much like that of MySQL; the only way anyone would be prepared to work on it is if they are being paid a full-time salary to do so.
Consider:
– It uses custom build tools rather than Makefiles that took quite a while to port into “open sores” form;
– It uses cryptic “German-English” mnemonics to name objects inside the code base;
– SAP gave up on it, effectively giving it away to MySQL AB.
All of these signs bode extremely badly for the ongoing ability to maintain it let alone improve it. No one that actually understands software projects would imagine that there would be any likelihood of there being any way of integrating much code from one database implementation into the other. That’s the same kind of idiocy as imagining that somehow GNOME and KDE could be deeply integrated together.
How can MySQL AB do more than keep the bits from rotting away TOO completely???
The likely scenario is that what MySQL AB is TRULY planning is to maintain SAPdb, giving them experience with its features, and will then focus on adding those features to MySQL that are necessary in order to allow it to be usable for supporting small SAP R/3 systems. After all, R/3 doesn’t use stored procedures, triggers, views, constraints, domains, and other such “relational fluff.”
The result of that would be that MySQL would become the “Oracle alternative” that SAP AG can use as a bludgeon when negotiating license prices with Oracle.
“Open sores” is pretty irrelevant to all that, of course; if that emerges as MySQL AB’s new marketing plan, they’d presumably drop their use of “open sores” releases as a marketing ploy…
I would have to agree totally with Josh Berkus. PostgrSQL development has been proceeding at an impressive pace. I think much of the open source community has no idea of the serious amount of brainpower behind PostgreSQL. It’s not the quantity of developers, but the quality. These are people that could easily be developing for any of the top DBMS vendors, such as Oracle, IBM, Sybase, but they choose to slave away at PostgreSQL, for often very little recognition. Kudos and thanks to you all ;-).
I would say, after doing some serious study on the relational model and its implementations, that PostgreSQL implements 99% of the *logical relational* capabilities of any DBMS out there (and often supersedes these DBMS’s at certain relational operations), while it implements about 85% of the enterprise-level data storage features. (notice, logical capabilities are different from storage implementation, such as tablespaces, clustering, replication, etc…)
Meanwhile MySQL is still struggling even to implement such basic things as views and triggers, with many serious constraint and integrity capabilities not even on the radar yet. For Roedling to say that MySQL provides 80% of what the “big three” are capable of is an incredible stretch. Maybe it provides 80% of what most developers use a DBMS for, but the serious databases are not “for” developers, but for the owners of the data. This is an important distinction that many developers don’t understand. A developer often will deal with only a small part of a database for any one application, while the company or organization must hire data modellers and DBAs to ensure the overall integrity and conceptual unity of all company data. And yes, the data *is* important. It will be needed far longer than your application.
@Anonymous (above, responding to derek):
Your comments, I think, perfectly highlight the difference between 1) developers who grok relational databases and 2) those who don’t. Please, I’m not saying one is better than the other, because often the second group will be better at other areas, such as event-driven programming, I/O, network protocols, etc… But any developer who says it is easier to write code than SQL statements falls into that second category. I personally, even though I am a developer and not a DBA or data modeller, have always found it easier (and requiring much less code) to handle logic on the database side than on the application side. I think the world needs both kinds of developers, but when it comes to the long term value of data, any dev team needs at least one developer who groks databases.
“There’s nothing random here – MySQL behavior is documented and known.”
Hardly.
Check out http://sql-info.de/mysql/referential-integrity.html#3_6 — this is a Gotcha that I submitted.
Basically, MySQL implements the ON DELETE/UPDATE RESTRICT and ON DELETE/UPDATE NO ACTION in a highly “aberrant” manner, and doesn’t bother to document it. The only reference to this little gem of a gotcha was on a MySQL listserv a few months ago — there is no mention of it in the MySQL online manual.
This particular bug is really bad for anyone porting an existing schema to MySQL. The SQL would be parsed fine, and MySQL wouldn’t print an error or warning, but it would do the exact opposite of what any reasonable DBA would expect.
Toad®, Market-leading tool provides quick and easy database development and administration. … Toad is an official Quest Software release.
http://www.toadsoft.com/ – 5k – Cached – Similar pages
Oracle. PostGreSql, and even MS Sql also provide recovery when the hardware and/or power fails, upto the last transaction completed, even if you have to re-constitute at a disaster recovery site. MySQL is only as good as that last cold backup, which could be a week old. Transactions since then, not important according to them. Course it wasn’t the MySQL engine that failed, so I guess they have a point, don’t they??