Linked by Eugenia Loli on Thu 17th Jun 2004 21:11 UTC
Original OSNews Interviews 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.
Order by: Score:
80% my foot
by Anonymous on Thu 17th Jun 2004 23:11 UTC

If by 80%, you mean 20%, then yes. :-P

"moves quickly"
by Anonymous on Thu 17th Jun 2004 23:12 UTC

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.

by Bjørn on Thu 17th Jun 2004 23:48 UTC

hi, in norway we learn access before we start with mssql. are there any plans for making an light sql with frontend like access?

by derek on Thu 17th Jun 2004 23:52 UTC

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.

RE: access
by Jason on Fri 18th Jun 2004 00:53 UTC

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 )

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.

by Bjørn on Fri 18th Jun 2004 01:06 UTC

well it more like "Bergen's CTO: Why we moved to Linux"
Norway's second city embraces Linux,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.

Mysql, PostGresql, MS Sql and Oracle
by DaMasta on Fri 18th Jun 2004 01:15 UTC

What are the main differences and the advantages of each? I've always used MySQL because it's free, but now I'm curious.

by Eu on Fri 18th Jun 2004 01:34 UTC

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.

by Another matthew on Fri 18th Jun 2004 01:37 UTC

(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 you're responding to, not CNet ;)

by andre on Fri 18th Jun 2004 01:38 UTC

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 ;)

by DaMasta on Fri 18th Jun 2004 02:08 UTC

Thanks andre. Very informative.

Bad public relations work
by Eike Hein on Fri 18th Jun 2004 02:10 UTC

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.

RE:access - @Bjørn
by sandy on Fri 18th Jun 2004 02:13 UTC

"...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: - 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?

by xyz on Fri 18th Jun 2004 02:36 UTC

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.

by andre on Fri 18th Jun 2004 04:35 UTC

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 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.

MySQL 5.0 in 2005 ?
by Betcour on Fri 18th Jun 2004 06:46 UTC

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)

re: MySQl in 2005
by iain_peters on Fri 18th Jun 2004 07:05 UTC

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.

re: MySQL 5.0 in 2005
by derek on Fri 18th Jun 2004 07:28 UTC

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.

the trio: MySql Firebird PostGreSql
by Anonymous on Fri 18th Jun 2004 07:36 UTC

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.

my understanding
by Chris on Fri 18th Jun 2004 07:46 UTC

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!

RE:access - @Bjørn & sandy
by cyb on Fri 18th Jun 2004 08:23 UTC

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.

by xedx on Fri 18th Jun 2004 08:56 UTC

imho sqlite is better for a simple website database

by andre on Fri 18th Jun 2004 09:54 UTC

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.

@Cyb - re: Kexi
by sandy on Fri 18th Jun 2004 13:27 UTC

Thanks for the heads up on Kexi - will check into it

MySQL gotchas
by Steven Haryanto on Fri 18th Jun 2004 14:15 UTC

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.

by Steven Haryanto on Fri 18th Jun 2004 14:19 UTC

<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?

RE: MySQL Gotchas
by Bas on Fri 18th Jun 2004 14:41 UTC

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.

by rycamor on Fri 18th Jun 2004 15:45 UTC

>In response to Steven Haryanto: the examples you give can be caught in application code.


I don't even know where to start with this one. You may as well NOT use a DBMS, then.

sour grapes
by Anonymous on Fri 18th Jun 2004 16:53 UTC

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.

re: sour grapes
by Derek on Fri 18th Jun 2004 17:52 UTC

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?

by Bas on Fri 18th Jun 2004 18:33 UTC

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.

by rycamor on Fri 18th Jun 2004 21:03 UTC

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.


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

by Betcour on Sat 19th Jun 2004 06:52 UTC

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 !).

@derek II
by Anonymous on Sat 19th Jun 2004 08:37 UTC

"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.

Some codebases are too hard to work with...
by chris on Sat 19th Jun 2004 11:39 UTC

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.


- 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.

Re: @ derek
by derek on Sat 19th Jun 2004 18:11 UTC

"There's nothing random here - MySQL behavior is documented and known."


Check out -- 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.

by nGc on Tue 22nd Jun 2004 19:38 UTC

Toad®, Market-leading tool provides quick and easy database development and administration. ... Toad is an official Quest Software release. - 5k - Cached - Similar pages

RE: Mysql, PostGresql, MS Sql and Oracle
by Dick Goulet on Tue 22nd Jun 2004 19:52 UTC

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??