Jump to content

Talk:MySQL

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Awfief (talk | contribs) at 05:00, 18 February 2010 (→‎Forks in Response to the Oracle takeover). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

MySQL/Sun

Sun Microsystems announced plans to acquire MySQL AB

Probably needs putting into the article ;)

—Reedy Boy 14:13, 16 January 2008 (UTC)[reply]

I put http://www.mysql.com/news-and-events/sun-to-acquire-mysql.html into the article, hopefully that helps. Awfief (talk) 04:46, 18 February 2010 (UTC)[reply]

Original pronunciation

As the company is named after the daughter My of Michael Widenius of Helsinki Finland the pronunciation is originally 'me'. — Preceding unsigned comment added by 90.5.12.208 (talk • contribs) 11:37, 18 January 2008 (UTC)[reply]

Interesting, if true. Sources? SaulPerdomo (talk) 02:39, 22 January 2008 (UTC)[reply]
Already dealt with in-article. Widenius is ambiguous as to whether his daughter's name has anything to do with the project's, and there's been an official pronunciation for years. Chris Cunningham (talk) 11:21, 22 January 2008 (UTC)[reply]
Couldn't be, since the pronunciation of me is [mi:], while My in Swedish and Finish is pronounced [my:] or [myʲ], which for those qnowwing German or French would be like "müh" resp. "mue". My is just unpronouncable in English. Said: Rursus ☻ 10:51, 6 February 2008 (UTC)[reply]

Criticism

Why are there criticism included in the article talking about issues with non-current versions? Most of these criticisms were addressed in 5.0 which was released two and a half years ago? Macutty (talk) 15:54, 30 January 2008 (UTC)[reply]

Good point. WP:BOLD - remove the criticism! --TimTay (talk) 16:32, 30 January 2008 (UTC)[reply]
I disagree, this is an encyclopedia and history is actually part of what makes the subject worthwhile of being here. The criticism should be placed into context, of course, such as "criticism of 4.x", but it should stay in the article. Otherwise it's not so much an encyclopedia article as it is a here-and-now MySQL page that you might as well have found on an IT blog somewhere. Ham Pastrami (talk) 09:31, 20 February 2008 (UTC)[reply]
Agree with Ham Pastrami. Also believe that having a criticism section is appropriate. 67.189.104.78 (talk) 02:42, 5 August 2008 (UTC)[reply]

The tags have been there for a while so I took some action. It makes sense to me to incorporate the criticisms into the product history section rather than a separate section as these criticisms mostly apply to a particular version or versions and a whole section seems unfair to the product which may have had such issues resolved in a later release. You would not want to remove the criticism entirely from the article if a problem gets resolved so it's better to put it in a historical context. As criticisms now exist in the article as part of the history of the product, and not as a separate section, I see no need for the undue criticism tags. If a general criticism arises that applies to the product generally as a whole (not just to a particular release) that can safely go in a separate criticism section. Hopefully, this satisfies everyone's concerns. 82.44.93.55 (talk) 18:08, 31 October 2009 (UTC)[reply]

I was just thinking after reading the product history section that it could probably do with some more positive significant history as well as the criticism I incorporated yesterday, if it is deemed significant enough, just to balance out the criticisms (for e.g. a well-publicised, high-profile performance test that showed MySQL performing better than it's rivals, or something similar). I hope someone can add something if they know of any such. 82.44.93.55 (talk) 02:31, 2 November 2009 (UTC)[reply]

MySQL Application of the Year winners

I think this section should indicate whether the GPL or enterprise license was used. —Preceding unsigned comment added by 38.101.0.100 (talk) 16:59, 4 March 2008 (UTC)[reply]

Too Technical

Whomever thinks that this article is too technical, can you give some examples of things that need to be improved? What part is too technical? —Preceding unsigned comment added by Rsshilli (talk • contribs) 19:10, 5 March 2008 (UTC)[reply]

I think it's too technical. I am a moderately competent computer user and I decided that I wanted to put some old family pictures on my website and allow for family members to comment so we can try to figure out what these pictures from 100 years ago are of. I make the pages for my site with Dreamweaver v.8, I have a domain name with free forwarding to a friend's server where I maintain the files. I did some quick researching about how to make a comments option, like I did when I put a BBS on my site last year for a high school reunion--which is working fine. I found a script that will do the job and I expect that my friend's server running Apache will probably already have what I need to run the script (ScriptsMill Comments v1.04). But I really don't understand what a MySQL database is and as that's one of the prerequisites for running the script on my friend's server, I turned to Google and found this entry on Wikipedia. I read, no scratch that, I browsed the entry and still had no idea what a MySQL database is or how it relates to the script I want to use. SO . . . a less technical explanation would teach me (in a very general and conceptual way) about MySQL, about what the database is, and hopefully even relate it to things like the script I'm planning to use. —Preceding unsigned comment added by 76.0.240.143 (talk) 23:34, 25 October 2008 (UTC)[reply]

This encyclopedia article gave me what I expected, an explanation of MySQL. I did not expect Wikipedia to show how to use the software. At the behest of my adult son, a computer tech, I've purchased a couple books that will help me develop databases with this software. A cursory on-line search of "learning mysql" or "using mysql" showed me what I need for a good start. I expect Wikipedia will provide an introduction to software. This article seems to do that despite the subjective text complaining about the shortcomings of this inexpensive software. I've heard of some really buggy, expensive operating systems that seem to dominate the market for commercial software. There seems little justification for using Wikipedia as a podium to voice opinions and vent frustration. //Don K. (talk) 06:02, 13 July 2009 (UTC)[reply]

Lists

This encyclopedia article clearly does not have enough lists. I count at least three maybe four paragraphs of prose. Moreover, somebody has really dumbed it down. There are sections that almost sound as if it were written for an audience that included non-programs of MySQL. And definitely, let's nail down that pronunciation. I think we should have a Finnish speaker pronounce it and then include the audio recording. I will volunteer to learn Finnish in furtherance of this task.

MySQLi

MySQLi redirects here, but this article has no information on it. --208.70.245.209 (talk) —Preceding comment was added at 18:45, 18 July 2008 (UTC)[reply]

It would be nice to see a list of BIG users

It would be nice to see a list of major users. I've seen a document which says Google (Adsense), YouTurbe, Facebook, Wikipedia and some others. It would be nice to see a referenced list of such users, but not a set of ads for small companies that use it. Drkirkby (talk) 18:20, 19 July 2008 (UTC)[reply]

http://en.wikipedia.org/wiki/Wikipedia:Be_bold

peterl (talk) 00:08, 20 July 2008 (UTC)[reply]

The "old bugs" edit warring

I've left a comment with the (new) user who is reinserting this material to explain why it isn't suitable. For now, let's calm down and discuss it instead of carrying on with an edit war which will result in the page getting protected. Chris Cunningham (not at work) - talk 12:48, 24 July 2008 (UTC)[reply]

Apparently an unhappy former user of MySQL: "The reason why I am after this is that I have wasted around 1 and a half year on MySQL without ever being able to come up with a reliable solution".[1]. So, looking at what he claims with this pair of edits:

  1. "Critical bugs sometimes do not get fixed for long periods of time."
    No reputable source for this claim is given, it seems to be just the unhappy former user claiming it. Two references are given:
    1. a PostgreSQL core team member claiming that much of the code removed in creating an experimental version called Drizzle is extremely buggy. PostgreSQL is a competing database that the unhappy user has switched to.
    2. one of MySQL's founders asking for help testing 5.1 so that all possible bugs are found before release
    With no citations for the comment it should be removed, unless a reputable source making the claim can be found.
  2. "An example is a bug with status critical existing since 2003" and citing bug 989.
    1. The Status is currently "Patch pending", not "critical".
    2. The Severity is "S1 (Critical)" apparently because it's a piece of missing functionality. The bug is that if one person started adding data to a table then another person threw the table away, an entry to the backup and replication log for the adding work would be made after the throw away entry, so if a backup was being restored there would be a warning message even though the data would be thrown away anyway, because the table where it was being added no longer exists. That hardly seems critical, which probably explains why MySQL hasn't fixed it yet.
    3. MySQL has a formal bugs classification process and that has graded this bug as:
      1. D2 (Serious) serious defect, but not D1, a critical defect.
      2. R2 (Low) risk of introducing new bugs by fixing this one.
      3. E3 (Medium) effort to fix it.
    So this single bug report also seems not to support the claim that critical bugs have remained unfixed for years.

I searched the MySQL bugs databases for all bugs that the formal process classed as D1 (critical). There are fifteen of them at the time I write this. Just three are more than seven months old:

  1. The first is bug 21476, if you deliberately set the stack size to two thirds of it's normal and recommended size you can make the server crash instead of giving an error message.
  2. Second is bug 28756, a crash in an old version of Mac OS used on one of MySQL's internal test machines and the suggested fix is upgrading the test machine operating system to a more recent version because it's not really a MySQL bug.
  3. Third is bug 31435, where the last comment says that it's fixed and should be closed.

So MySQL's bug system and formal bug classification system really says that the only critical bug in the server that's more than seven months old only happens if someone seriously misconfigures the server. That contradicts the claim that critical bugs are left unfixed for long periods of time. A similar criticism was first (?) added by the same user back in April 2008 and removed by Chris Cunningham (not at work) in May 2008. Given the clear motive of the person adding this, the lack of any reputable source for the statement and the lack of real support for it there seems little merit for its inclusion.

Since Chris Cunningham (not at work) has already engaged in several edits disagreeing about including this and I've done this analysis, would someone else review and act appropriately to continue the proces of establishing consensus that this is just POV-pushing by an unhappy user? Jamesday (talk) 06:02, 8 August 2008 (UTC)[reply]

Critical bugs

Thanks for that Jamesday. I really believe there is a lack of critical information about MySQL. The bug I came up with is just one example of a long list of critical bugs. For example try reading halfway down the page at http://www.oreillynet.com/pub/a/databases/2006/08/10/mysql-federated-tables.html?page=4 this issue is an ugly surprise when one tries to use the Federated engine for ad-hoc queries where it is impossible/impractical to create indexes for everything. Not sending the "where" clauses to the remote server is an amazing missing functionality (I cannot imagine any reason for this apart from extreme time pressure on the developer). In our case, we had a complete application, which to our surprise performed dreadfully when there were more than a few thousand rows in a table (as all rows where sent across the internet).

Do you understand why the bug I refer to in the article does not show up on the search you provided: http://bugs.mysql.com/search.php?cmd=display&bug_type=Server&status=Active&os=0&bug_age=0&priority=all&limit=30&defect_class=-1&workaround_viability=all&impact=all&fix_risk=all&fix_effort=all&reorder_by=date

It should surely show up there. Some time ago when I ran the same query, lots of older bugs showed up, but now I cannot see the really old ones.

I am not trying to undertake a vendetta on MySQL, I just believe that the Wiki article should have some criticism on MySQL in order to be more neutral. My problem was that I didn't spend enough time documenting my claims and finding references (I assumed others would contribute to the criticism part as well) before writing in into the article. So obviously I stepped on someones toes.--Hulagutten (talk) 18:37, 25 August 2008 (UTC)[reply]

Your search is for active bugs, those that have pending work. A bug is no longer active once it has been fixed. So the bugs vanishing is a good thing.
The Federated storage engine isn't turned on by default any more in MySQL 6.0 so it seems that MySQL agrees that it needs more work to be a really high performance engine. You might try a second copy of MySQL on the same server that replicates from the remote server. Then you can load from that copy without having to use the internet.
The text "An example is a bug with status critical existing since 2003" isn't accurate. Its Severity (not its status) was originally rated critical because if it happens it can be annoying (you might have to edit the text version of a binary log to use it as part of restoring a backup) but it's Status is "in progress" and it seems to be something that'll be fixed in 6.0. To have that problem in the first place you have to drop a table while some other transaction is actively using it. That's a crazy thing to be doing; you'd want to drop when the table isn't in use. Nice to fix it but I have difficulty thinking that a problem that requires you to be crazy to experience it is a critical one.
I suppose it's worth updating the status of the three bugs that MySQL thought were critical when I did that search back in August. Bug 21476 was fixed in version 6.10 for the only platform that was still affected, HP-UX. Bug 28756 is not fixed; looks as though it's not annoying MySQL's developers, who are the only people who see it, much. According to the comments on the patch review, bug 31435 was really fixed back in November 2007 and all that's left is to do is remove a redundant error message. Not really a lot there to support a claim that bugs that MySQL really thinks are critical are left for years.
For a more balanced view of MySQL reliability you might take a look at You don't build server software with an MTBF from software crashes measured in centuries (yes, that is what I get now) by being lucky, written by the guy who looks after the MySQL servers that are used in Google's AdWords system. That might be a nice quote to add some balance to the bugs paragraph. Jamesday (talk) 07:21, 5 March 2009 (UTC)[reply]
Articles do not just add "criticism" in order to be "neutral". If criticism has been featured in reliable, secondary sources then it can be added, inoorporated appropriately into the rest of the prose. Otherwise, it should not be. Bug lists are original research, and are unsuitable. Chris Cunningham (not at work) - talk 10:33, 5 March 2009 (UTC)[reply]
If you are up for the task of making a comment next to all features that are affected by the 55 unfixed critical bugs stated by the creator of MySQL (Michael "Monty" Widenus) (see http://planet.mysql.com/entry/?id=16232), then you are welcome to remove the critisism section. In addition, one of the initial sentences of the article should state that MySQL has many unfixed critical bugs, which might crash the database from time to time, leading to dataloss and/or downtime.--hulagutten (talk) 21:23, 9 June 2009 (UTC)[reply]
(copied from user talk:Hulagutten#Removal of cleanup tags:
As has been repeatedly pointed out to you, that MySQL has open critical bugs (incidentally, "critical" is just a triage level; Firefox has open critical-level bugs, as do almost all free software projects) does not in itself require us to do anything to warn readers, nor is it in itself a point of criticism. The only time we can record criticism is where a reliable secondary source is doing the criticising. You have repeatedly been asked to provide such sources and the only thing you've come up with is primary sources which explain the bugs themselves (i.e. bug tracker items) or rants on forums and blogs. This has predictably failed to sway consensus that segregating negative points from the rest of the article is a bad idea. Should you have no argument based on an understanding of our policies on original research and synthesis of argument to counter the consensus that a segregated section for negative material is a bad idea, the cleanup tag shall be re-added. Chris Cunningham (not at work) - talk 23:00, 9 June 2009 (UTC)[reply]
Please read http://planet.mysql.com/entry/?id=16232. The author is Michael "Monty" Widenus, the creator of MySQL. Please tell me that he has no authority to criticize MySQL and that it is not a secondary source. —Preceding unsigned comment added by Hulagutten (talk • contribs) 20:32, 10 June 2009 (UTC)[reply]
That's a blog post expressing concern that the release process for 5.1 was flawed. That, not the bugs therein, is the overarching theme of the post. As the author is directly associated with MySQL, it is a primary source. Using that blog post to criticise MySQL for having "critical bugs" is at best a misreading and at worst deliberate twisting of words. I'm inclined to think that the latter is more likely given your previous statements. Chris Cunningham (not at work) - talk 09:13, 11 June 2009 (UTC)[reply]
The article states that the product is flawed due to a flawed release process. These things are strongly related. If you release too early the product will have critical errors. Michael Widenus is an insider who critizises his own organization and his own product. You cannot find a more reliable source than that. If this is not good enough, please stop harassing those that try to improve this article by referencing credible sources and go get your damn secondary sources yourself. —Preceding unsigned comment added by Hulagutten (talk • contribs) 12:53, 11 June 2009 (UTC)[reply]
Again, it is the release process for a particular cycle which is being criticised in that blog post and not the product itself. I'm restoring the tag, as it is not the lack of secondary sources which is being pointed out but that the section is being used as a deliberate effort to draw negative attention on the subject by an editor who has repeatedly stated that his aim on this article is to highlight the problems he had with it personally. Chris Cunningham (not at work) - talk 13:48, 19 June 2009 (UTC)[reply]

Creators/Developers

This article does not even mention who created MySQL, or who the main developers have been. —Centrx→talk • 18:07, 16 December 2008 (UTC)[reply]

Fair enough. If I had created it, I would be ashamed. 81.208.7.130 (talk)

Popularity

The article used to say that the popularity of MySQL is "is closely tied to the popularity of PHP and Ruby on Rails". The PHP part is fine, but to say that the popularity of MySQL is tied to Ruby on Rails is absurd. MySQL was a major player long before RoR appeared and today RoR accounts for only a tiny portion of MySQL-based websites. So I deleted |Ruby on Rails" from the sentence. --Daniel Carrera 15 January 2009 —Preceding undated comment was added at 11:56, 15 January 2009 (UTC).[reply]

Ownership/Copyright

Two statements in the lead caught my eye:

  • "...MySQL is owned... and sponsored by a single for-profit firm..." - if the source code is under the GPL, what exactly does the firm 'own'?
  • "...now a subsidiary of Sun Microsystems,[4] which holds the copyright to most of the codebase." - again if the source code is under GPL, to what is Sun claiming 'copyright'? (more precisely, to what is the article claiming that Sun is claiming copyright?)

Cander0000 (talk) 02:55, 16 July 2009 (UTC)[reply]

They own the copyright for all code, and they license this code under the terms of the GPL. This means that they can, if the want, relicense future versions of the code any way they want. This is also the reason why they can have it under dual licenses. (Released code cannot be relicensed though, i.e. they cannot "unGPL" existing versions) --Isaksavo (talk) 11:19, 21 August 2009 (UTC)[reply]
Correct Dontdeletecontent (talk) 03:03, 12 January 2010 (UTC)[reply]

Wikipedia

The biggest installation of database doesn't mention, strange... —Preceding unsigned comment added by 62.219.193.152 (talk) 15:26, 31 August 2009 (UTC)[reply]

Google

"It is also used in very high-scale World Wide Web products including Google and Facebook." No source for that? It's fairly common knowledge that Google primarily (and almost exclusively) uses their own Bigtable instead of MySQL. —Preceding unsigned comment added by 208.72.137.116 (talk) 12:58, 3 September 2009 (UTC)[reply]

At least they used to use MySQL, is there any source that says that Google is NOT using MySQL any more? It rather seems like they use Bigtable for certain, specific services like youtube and google maps etc. I am no expert but it would be great to have a source (either way) to verify / falsify this claim. Thanks --hroest 11:49, 16 October 2009 (UTC)[reply]
Google uses MySQL for some subsystems, and has contributed patches to the MySQL source. There was a talk by Google people about that at the MySQL Conf and Expo in April 2009, see Availability and Scalability Patches from Google -- Isotopp (talk) 10:42, 18 January 2010 (UTC)[reply]

Can Oracle Kill MySQL?

Everyone I know who is watching the EU vs. Oracle battle over the future of MySQL wants to know the answer to this question: Can Oracle Kill MySQL? This is the most relevant question the Wikipedia article can address.

Oracle's stated objectives mean nothing. We want to know if the terms of the licensing enable fully functional forks of the MySQL code to evolve, or if Oracle controls enough of the components of MySQL that it could effectively shut it down if it wanted to do so.

When I google news stories, I get conflicting reports:

  • The Register paraphrases Florian Mueller as saying Oracle would hold the brand and the databases assets, and it would take somebody else years before any fork could reach the same kind of technical maturity and level of acceptance as MySQL.
  • CNET Business Tech, on the other hand, contends that Amazon's RDS and Drizzle are viable MySQL forks that could compete with Oracle.

The MySQL article here on Wikipedia talks about Oracle having bought up storage engines used by MySQL since 2005. It also talks about MySQL developing Falcon, its own storage engine, for future releases. Is this key? If Oracle kills MySQL's storage engines, would it put MySQL years behind?

What is the EU's primary concern?

  • Oracle's physical ability to control the storage devices?
  • Oracle's ability to effectively shut down future forks via licensing, or
  • Oracle's ability to use the courts as a club against anyone trying to grow a MySQL fork to something that could compete with Oracle's larger operations?

Can anyone answer these questions or provide insight toward the goal of finding answers?

Given that the EU allows an Oracle + MySQL merger to operate within its jurisdiction, is there any way possible for Oracle to effectively kill or significantly hamper future MySQL development?

My query is for the purpose of proposing a direction for future development of unfettered projects like Wikipedia built on unfettered database technology like MySQL. You have my gratitude for any insight you can provide. --MyPerson (talk) 15:15, 14 November 2009 (UTC)[reply]




IMO this discusssion lacks all the neutrality that is so well looked after with all the posts that critize MySQL. One should keep in mind that Oracle is actively developing/marketing all the other database products they have bought in, so the idea that Oracle will "kill" Oracle is at least biased. More so, at least _some_ consideration could be given to the fact that Oracle has a lot more experience with databases, both in terms of performance and stability than MySQL has, and this could mean that MySQL could benefit a lot. I know some people will disagree, ask for sources and so on, honestly I think they should come up with some by themselves. List some large databases that actually run on MySQL (>64cores, >512GB Ram). It's just inpolite that all "good" features of MySQL are published without much questioning, like i.e. reviewing the opinions of people that were unhappy with MySQL or prove a lot. —Preceding unsigned comment added by 82.135.62.109 (talk) 23:19, 21 January 2010 (UTC)[reply]

Forks in Response to the Oracle takeover

The Drizzle project is not a response to the Oracle takeover. It started in 2008 during the MySQL Conference. See History, bottom of the page, for reference. This is way before the merger announcement. MariaDB also existed before the merger announcement, the WP article on MariaDB mentions 2009-01-22 as the inital release date, whereas the Oracle-Sun merger event dates to 2009-04-20. Hence referring to MariaDB and Drizzle as 'forks in response to the Oracle takeover' is clearly wrong. -- Isotopp (talk) 11:06, 18 January 2010 (UTC)[reply]

I have edited that section to note that the forks were pre-oracle acquisition. Awfief (talk) 05:00, 18 February 2010 (UTC)[reply]

MySQL Frontends

No much mention of MySQL Frontends? apart from phpMyAdmin in one of the paras there doesn't seem to be any more info. I want to expand the article and add a section on Frontends / GUI tools, or should there be a separate article for this, like MySQL Frontend? -- Tom Jenkins (reply) 06:55, 26 January 2010 (UTC)[reply]

Started off with a section for this: MySQL#Management_and_Graphical_Frontends. That describes the major frontends and has to be expanded a lot more, but covers the issue fine for now. -- Tom Jenkins (reply) 08:20, 26 January 2010 (UTC)[reply]
Looks good to me, if there is even more material on this, one could make it its own article. This would also remove the simple listing of products from the main article which I am not so happy with. Greetings --hroest 16:20, 11 February 2010 (UTC)[reply]
That's great, thanks for your feedback. The other commercial MySQL frontends could be described, but they still seem similar enough to be only listed generally. I've edited the section to read more as an article, and the list is similar to the list of platforms just above the GUI section. Would that do fine for now?
I like the idea of describing a few freely available frontends in the main MySQL article since it makes a big difference to every MySQL engineering team, including design, development, server administration and maintenance. -- Tom Jenkins (reply) 01:40, 12 February 2010 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:MySQL&oldid=344761067"