Krow alerted me that MySQL has been bought by Sun. Right now there is only a brief announcement but it discusses what the acquisition will mean for the core developers, community etc.
One can only hope that they will be using this to replace the database that comes in Open Office.
Seconded, thoroughly - in addition I would like some decent gui tools for
single-user data-storage requirements; it's annoying that any pc user who
wants to maintain a list of (contacts/friends/must-see-movies/must-read-books/etc)
puts everything into a spreadsheet.
Seconded, thoroughly - in addition I would like some decent gui tools for single-user data-storage requirements; it's annoying that any pc user who wants to maintain a list of (contacts/friends/must-see-movies/must-read-books/etc) puts everything into a spreadsheet.
Notepad is a great storage system. In fact, I have at least ten "New Text Document.txt", "New Text Document (2).txt" files on my desktop right now. One of them has my address book in it.... let's see... is it (6)? Nope, that's my checking account register. Hmm.... could've sworn that was my address book.... shit, I'm overdrawn by $50!
(Laugh, it's not that far from the truth.... got a similar situation with text files in my ~ on my Linux box.... who needs meaningful filenames and directories when you have grep?)
Who needs meaningful filenames and directories when you have grep?
Actually, he has a point.
One of the best features, to my taste, of gmail is that I can quickly find an email with a specific content regardless of the subject. Same thing with files if they are full content indexed.
And that is the way that humans naturally work: "I know what I am looking for, I just don't know where I put it (nor I care where it was)". The folders and file names paradigm is an emulation of the paper archival model. Classes are tough on how to create a mantain one (bookeeping, library, secretaries).
You see, this "order" force us to keep to pieces of information in our head: What is it and where is it. And to use one to get the other.
Of course anyone can create a simple filing system, but it requires some level of self disipline to keep it.
Actually there is stil an immense use for Excel in data processing. As a mathematician, I find Excel excellent for very-short-term data analysis projects. If you need to put the data in a database... you can always dump the whole spreadsheet.
Excel generates graphs very quickly, has quite a powerful set of numerical analysis functions and just works.
Databases aren't the answer when you want fast results.
A few thoughts about spreadsheets as databases and the like...
The original marketing of Lotus 123 stressed its use as a database. 123 stood for 1=spreadsheet, 2=database. and 3=word processor. Excel still has 13 choices on its |Data menu. Lotus was a bloody awful word processor. Copy Con was better.
Back in the early DOS days, I used to use a flat file database called Professional File a lot. dBaseIII was overkill for what I needed.
In the later Dos days I was using Quattro Pro a lot for my spreadsheet work. I also used it for inventory lists, but hardware limitations, both RAM and drive storage were a problem when spreadsheet databases got over 200 records. Paradox worked better both for loading in memory and for much smaller file size than Quattro Pro for the same number of records.
In spite of its many faults, I use Access for mail merge data rather than the @#$%ing awful thing in Word.
I use Access for a database more than I use Excel, but sometimes Excel is simpler.
I would love to see a single-user desktop database program with modest relational capabilities, intuitive query and report functions, and decent ability to import and export data.
The problem, from an IT department standpoint, is that such "lists" always seem to grow in their requirements. We had one department that starting keeping a "list" of incoming data for people applying for land zoning exemptions. All these were handled by a single person and she just needed to keep track of them so the spreadsheet works fine right?
Now, fast forward a year. People from 3 other departments need access to an always updated copy of this list. One of them is off-site on a different network. Some people aren't supposed to see parts of the list. Others can see all of the list but they are only supposed to be able to change parts of it.
Now, as you can see, what this has evolved into is essentially a multi-user database app. A very basic one, but still more than a spreadsheet can handle (because a spreadsheet is meant for calculating, not data storage). If they had just come to us in the beginning we could have gotten something working setup from the start, rather than having to worry about going back and recreating it and importing data.
That's my problem with the whole "a spreadsheet is fine" outlook. You can hammer in a nail with a crescent wrench too, but if you do so with a hammer sitting right there in the toolbox I'm gonna consider you an idiot:).
This is why IT departments need some improvement. Most are made up of hardware people who have a few programmers as friends and by and large are reactive rather than proactive in the way they deal with growth. The worst are the massively corporate entities who assume that the way to deal with any issue is to micromanage everything. I'm not blaming the people in IT for this so much as the people who create and staff IT departments.
How do you deal with the growth of an application such that it no longer is able to serve the audience that it now has effectively? Well, if this were hardware, you'd replace it. And the same approach needs to be taken with software. But that takes people to understand the application, and others to do the time consuming work of migrating people and data over to the new application.
There's nothing wrong with using a spreadsheet to manage an address book to start with. As more people start to use the same source, however, IT departments need to be willing to (and CTO's willing to allow them to) recommend changes, including providing the resources to move the data to a more efficient, more effective, platform. As of right now though, most IT departments don't even have the appropriate people to do that.
Spoken like someone who doesn't work in IT. I get request the day stuff is suppose to start with the users IDEA of what should work. Not requirements or information and what needs to be done then I get weeks of little issues tiring to make this Square Peg fit into a round whole until I figure out what is going on and replace it with something that works. The problem is IT is the last step in the process not the 1st step and that will always cause issues. Sometime we just can't do what the user thinks is simple. Just this week I had a issue with someone deciding that email made a good real time alert system from an external customer. Problem email isn't real time and/or reliable. So every hick up in email is an issue. If IT was consult we could have either a)set the expection or b)developed sometime that was real time and reliable they could use.
Actually, from my experience as a programmer I'd much rather have someone come with a spreadsheet he worked with for a year, and very specific requirements such as "we want some people to be able to see these fields, some people to be able to edit these columns" and so... than to have someone with a vague notion of what he needs and then turning that into a relational database.
Even if spreadsheets seem awful, a year's user experience with a fast prototyping tool (i.e. the spreadsheet) is priceless.
You can hammer in a nail with a crescent wrench too, but if you do so with a hammer sitting right there in the toolbox I'm gonna consider you an idiot.
Well, as long as we are on the subject, how about the overuse of SQL databases for non-relational information? MySQL is no beast, but in my company, there is a SQL Server on almost every box and many of them are storing stuff that is non-relational and could be accessed more quickly in a direct access file.
by Anonymous Coward
on Wednesday January 16 2008, @09:20AM (#22065994)
One can only hope that they will be using this to replace the database that comes in Open Office.
Wouldn't SQLite [sqlite.org] be a better choice for that? MySQL is a bit to heavy for use in an office application. SQLite was designed to be embedded into applications, is quite powerful, fast, and released in the public domain [sqlite.org].
One can only hope that they will be using this to replace the database that comes in Open Office.
You can already use MySQL as the database engine for Open Office.
The development environment in OOo (Base) is a database client, not a database engine. Base does bundle the HSQLDB database engine, but even that is just XML tables, and shouldn't be used for anything serious.
As far as the quality of Base, yep it's rough, but it's also brand new for OOo v2. It's being actively developed, and there are plans [openoffice.org]to use it to allow users to share data from several FOSS packages within the suite.
* Btw, I know you were just trolling, but I thought this was worth an answer, since desktop databases are a badly misunderstood class of software.
Here's one that I've noticed, and which other database professionals I've talked to have corroborated. Access, when executing a query against an outside database, sometimes confuses an unique constraint as a candidate primary key. This seems like a teeny little quibble, but it has really bad consequences.
Consider the columns (a,b) and the value (a = X, b is null). If (a,b) is part of the primary key, the value (X,NULL) cannot occur in a table. But the idea of "uniqueness" is not as well defined in relational theory. Can the values (X,NULL) occur if (a,b) is constrained to be unique? Well, probably. Can it occur more than once? Now that turns out to be a very interesting question.
Let's consider a single column (s), where s is defined to be unique, but is allowed to be null. (s) cannot be part of the primary key of course, but can null occur more than once in the table? The answer is, yes, for both practical and theoretical reasons. The practical reason is that this turns out to be a quite useful behavior. Suppose s represents a social security number on a person record. In some cases that person has declined to provide is SSN, in which case we must put a null in that column. So two or more people can provide null for their social security number, thus many rows can have null there; but if two people provide the SAME SSN, that's an error.
The theoretical justification for nulls behavior in unique constraints comes from that fact that the expression (null == null) should evaluate to false. The expression (s = null) is ALWAYS false, even if the column s happens to contain null. That is because null as a value has special meanings; it can mean "doesn't apply" or "don't know". If s is the SSN, and record a and record b both have null in them, then how do we interpret the expression (a.s = b.s)? If it means do the records for a and b have the same value in column s, you'd want it to be true. If it means does person a have the same ssn as person b, you'd want it to be an error. If it means is person a known to have the same ssn as person b, you'd want the answer to be no. Each of these interpretations has its justifications, but the last one is the one that is ultimately the most practical. If we want to test whether a column is null, we must use the "is" operator, not the equality operator.
So, the apparently minor distinction between key candidacy and uniqueness is quite large if any of the columns involved are allowed to contain nulls.
Now, for the practical consequences of getting this wrong. If you use Access' GUI tools to build queries against tables in an external database, Access when running that query does not allow the external database to optimize the query. You need to do a pass through for that. Instead, Access attempts to optimize the query itself, particularly I/O over the database link, which is presumably expensive.
So lets say table p is people and table r is region, and both tables are held on an Oracle database. I want to do a query which joins person to region to make a table of names and the regions they live in. Now it happens that Alice (person #25) and Bob (person #82) live in the same region, "North". The query correctly spits out ("Alice","North"), then continues on to Bob's record. Now it turns out that both Alice and Bob have refused to supply the SSN, so they both have null in column s.
What happens next is pretty mysterious, but I think we can infer two things. First, Access gets the issue of (null = null) wrong; at least some parts of Access do some of the time. Second, Access may be attempting to reduce external I/O, but it somehow tracks by what it thinks is the primary key. Whatever the cause, one often gets the sequence:
("Alice","North") ("Alice","North")
instead of:
("Alice","North") ("Bob","North")
which would be the correct one.
Oops.
I'd give you more information on reproducing this, but I don't use Access much. Like I said, I have talked to other da
mysql license is real mess, it can be interpreted in so many ways.
Mod parent insightful, please!
I recall reading that MySQL AB really didn't stand a chance to force the GPL (and therefore, move to their proprietary license) on programs that connected to the database because that was "dynamically linking". Dude, WTF? Using protocols to communicate to a program or service is NOT linking! I got so angry when I read the news on the License change, that I wanted to tag the story "greedybastards". But if MySQL AB told the truth, then nobody would buy their ultra-expensive license.
On the other hand, Sun and their promotion of Open Office (and open formats) is a proper example of Free software.
Let's hope things change for the good (for example, re-releasing the MySQL client software to LGPL or GPL+linking exception).
Using protocols to communicate to a program or service is NOT linking!
I understand where you're coming from, which is why I moved to Postgres for all my new applications last year. However, as it stands now, I think MySQL is within their rights to use the GPL for the client. As far as I know, there is no way to communicate with a MySQL server without linking to their client library (i.e., libmysqlclient.a). At one time there was an attempt to maintain a fork of the old LGPL MySQL 3, but it never took off. Now, merely linking to the client library doesn't automatically create a derived worked (see Linus's explanation [lkml.org]), however, in the absence of some other compatible library you could have linked with instead, it's pretty much impossible to say your linked program is independent of MySQL. And since independence is a requirement to have a non-derived work (i.e. the ability for a program to live a separate life, do something useful without the linked library), the program ends up being derived from the MySQL client, and has to abide by the GPL.
There is still plenty of argument around this topic, but again, it can be avoided by using Postgres, which IMHO is a better database anyway.
But I think most people thought Sun might push PostgreSQL [sun.com] which is a nice database. Not sure why Sun would purchase MySQL, seems like an expensive PR move. I for one have seen Sun's product support deteriorate over the years, and hope they keep support for MySQL independent of the main line support. Or maybe this plays into Oracle as Oracle had or has an alliance with Sun. Is this alliance strained?
by Anonymous Coward
on Wednesday January 16 2008, @08:12AM (#22065406)
I hear they paid an astronomical amount for MySQL. In fairness though, the code is stellar. The developers must be beaming with pride. If I were a shareholder, it would certainly brighten up my day.
"As part of the transaction, Sun will pay approximately $800 million in cash in exchange for all MySQL stock and assume approximately $200 million in options."
For sure, The big guys (IBM, Sun, Oracle, Microsoft) are starting to look the same, with only Microsoft not playing with Open Source something. Could be interesting days ahead, it really looks like business models are starting to reshape themselves as they try to squeeze more dollars out of each account and/or IBM/Sun/Oracle eyeing over how much profit they could squeeze out of the demise of Microsoft's market share in the business sector.
Perhaps Sun will be playing around with open sourcing some more of their hardware as a pseudo way of moving away from hardware, without actually losing all their hardware aquisitions.
But it is interesting to see how open source as a business model is evolving by allowing competitors to leverage off each other and still compete. Maybe what we are looking at is the "horizontalisation" of the market, I note that with speculation about an open sourcing of DB2 and Oracle databases, Microsoft's position in the market looks more and more isolated every day.
Right now Sun supports PostgreSQL on Solaris (http://www.sun.com/software/products/postgresql/index.jsp) and Oracle is one of the main applications used in Solaris.
I think this is a move to sell support to their customers, like asking: "Do you need an Oracle Database?" - If the answer is "YES", then we will sell you our servers and OS support - If the answer is "NO", then we will sell you our servers and OS support AND MySQL / PostgreSQL support
I have worked at a lot of big banks. Open Source has been slowly finding its way in, but it is incredibly difficult to deploy an open source database like MySQL or Postgres. The banks says they want safety and security - and you answer that your database isn't enterprise critical so why pay for Oracle? Management then says, ah well, how about MS SQL Server....
As a long term PostgreSQL proponent, I'm not sure this is good news or bad. Many of the software stacks in open source, regrettably, use only MySQL. This makes it hard for PostgreSQL at times, but it puts the "owners" of MySQL in an excellent position to help some projects while ignoring others.
Sun owns Java. Sun will soon own MySQL. If you have a Tomcat/J2EE environment running open source, you will soon be having to deal with a single vendor with control over your environment, because most systems only give lip service to PostgreSQL but fully support MySQL. Expect the support bills to go up.
On to RedHat and IBM, I think it is time for them to start funding the PostgreSQL project for real. Setup a more corporate entity to guide it and REALLY compensate the guys like Tom, Bruce, et. al. for so much hard work, which IMHO is above and beyond a standard pay check.
There are many of us who have been working on MySQL for many years (my efforts with MySQL begin a decade ago). None of us are willing to move away from our open source roots. I've seen nothing that makes me think that Sun had any interest in doing anything foolish. They understand the value of MySQL being open source.
This means that now more people may prefer to use MySQL rather than Oracle with Java, as they will see it as the most "compatible" database to be used within Java.
It's a bit odd considering how much effort Sun put in to pushing PostgreSQL on Solaris in the last year or so. I wonder what their goal in this acquisition is.
but what good are they if you are bound and 'forced' to work until 9pm each nite? or made to feel guilty if you DON'T stay for dinner and work a few hours after that.
all for the SAME PAY.
yes, its a slave life. you'll understand that when you get older (no insult intended; I didn't realize this until I hit over 40, myself.)
the benefits are only there on the surface.
but what good are they if you are bound and 'forced' to work until 9pm each nite? or made to feel guilty if you DON'T stay for dinner and work a few hours after that.
all for the SAME PAY.
yes, its a slave life.
We added triggers, stored procedures, and views in 5.0. Today there are publicly several transactional engines (supported by companies like Oracle, IBM, Solid, and yes ourselves). There are many other non-public transactional engines.
I wonder (Score:5, Interesting)
Re:I wonder (Score:5, Interesting)
Homo homini lupus
Parent
Re:I wonder (Score:5, Funny)
Parent
Re:I wonder (Score:5, Funny)
Notepad is a great storage system. In fact, I have at least ten "New Text Document.txt", "New Text Document (2).txt" files on my desktop right now. One of them has my address book in it.... let's see... is it (6)? Nope, that's my checking account register. Hmm.... could've sworn that was my address book.... shit, I'm overdrawn by $50!
(Laugh, it's not that far from the truth.... got a similar situation with text files in my ~ on my Linux box.... who needs meaningful filenames and directories when you have grep?)
Parent
Re:I wonder (Score:5, Insightful)
Parent
Re:I wonder (Score:5, Insightful)
Who needs meaningful filenames and directories when you have grep?
Actually, he has a point.
One of the best features, to my taste, of gmail is that I can quickly find an email with a specific content regardless of the subject. Same thing with files if they are full content indexed.
And that is the way that humans naturally work: "I know what I am looking for, I just don't know where I put it (nor I care where it was)". The folders and file names paradigm is an emulation of the paper archival model. Classes are tough on how to create a mantain one (bookeeping, library, secretaries).
You see, this "order" force us to keep to pieces of information in our head: What is it and where is it. And to use one to get the other.
Of course anyone can create a simple filing system, but it requires some level of self disipline to keep it.
And is not intuitive.
I know what I want... just fetch it!
Parent
Re:I wonder (Score:5, Informative)
Parent
But you can email a copy to coworkers (Score:5, Funny)
Sheesh, doesn't EVERYONE do it this way?
Parent
Re:I wonder (Score:5, Insightful)
Excel generates graphs very quickly, has quite a powerful set of numerical analysis functions and just works.
Databases aren't the answer when you want fast results.
Parent
Spreadsheet/Database (Score:5, Interesting)
Parent
Re:I wonder (Score:5, Interesting)
Now, fast forward a year. People from 3 other departments need access to an always updated copy of this list. One of them is off-site on a different network. Some people aren't supposed to see parts of the list. Others can see all of the list but they are only supposed to be able to change parts of it.
Now, as you can see, what this has evolved into is essentially a multi-user database app. A very basic one, but still more than a spreadsheet can handle (because a spreadsheet is meant for calculating, not data storage). If they had just come to us in the beginning we could have gotten something working setup from the start, rather than having to worry about going back and recreating it and importing data.
That's my problem with the whole "a spreadsheet is fine" outlook. You can hammer in a nail with a crescent wrench too, but if you do so with a hammer sitting right there in the toolbox I'm gonna consider you an idiot
Parent
Re:I wonder (Score:5, Insightful)
This is why IT departments need some improvement. Most are made up of hardware people who have a few programmers as friends and by and large are reactive rather than proactive in the way they deal with growth. The worst are the massively corporate entities who assume that the way to deal with any issue is to micromanage everything. I'm not blaming the people in IT for this so much as the people who create and staff IT departments.
How do you deal with the growth of an application such that it no longer is able to serve the audience that it now has effectively? Well, if this were hardware, you'd replace it. And the same approach needs to be taken with software. But that takes people to understand the application, and others to do the time consuming work of migrating people and data over to the new application.
There's nothing wrong with using a spreadsheet to manage an address book to start with. As more people start to use the same source, however, IT departments need to be willing to (and CTO's willing to allow them to) recommend changes, including providing the resources to move the data to a more efficient, more effective, platform. As of right now though, most IT departments don't even have the appropriate people to do that.
Parent
Re:I wonder (Score:5, Insightful)
Parent
Re:I wonder (Score:5, Insightful)
Parent
Re:I wonder (Score:5, Interesting)
Well, as long as we are on the subject, how about the overuse of SQL databases for non-relational information? MySQL is no beast, but in my company, there is a SQL Server on almost every box and many of them are storing stuff that is non-relational and could be accessed more quickly in a direct access file.
Parent
Re:I wonder (Score:5, Funny)
One can only hope that they will be using this to replace the database that comes in Open Office.
I figured MS was paying them to include the current one to make Access look good by comparison.
Parent
Re:I wonder (Score:5, Informative)
Parent
Re:I wonder (Score:5, Informative)
You can already use MySQL as the database engine for Open Office.
The development environment in OOo (Base) is a database client, not a database engine. Base does bundle the HSQLDB database engine, but even that is just XML tables, and shouldn't be used for anything serious.
As far as the quality of Base, yep it's rough, but it's also brand new for OOo v2. It's being actively developed, and there are plans [openoffice.org]to use it to allow users to share data from several FOSS packages within the suite.
* Btw, I know you were just trolling, but I thought this was worth an answer, since desktop databases are a badly misunderstood class of software.
Parent
Sure. (Score:5, Interesting)
Consider the columns (a,b) and the value (a = X, b is null). If (a,b) is part of the primary key, the value (X,NULL) cannot occur in a table. But the idea of "uniqueness" is not as well defined in relational theory. Can the values (X,NULL) occur if (a,b) is constrained to be unique? Well, probably. Can it occur more than once? Now that turns out to be a very interesting question.
Let's consider a single column (s), where s is defined to be unique, but is allowed to be null. (s) cannot be part of the primary key of course, but can null occur more than once in the table? The answer is, yes, for both practical and theoretical reasons. The practical reason is that this turns out to be a quite useful behavior. Suppose s represents a social security number on a person record. In some cases that person has declined to provide is SSN, in which case we must put a null in that column. So two or more people can provide null for their social security number, thus many rows can have null there; but if two people provide the SAME SSN, that's an error.
The theoretical justification for nulls behavior in unique constraints comes from that fact that the expression (null == null) should evaluate to false. The expression (s = null) is ALWAYS false, even if the column s happens to contain null. That is because null as a value has special meanings; it can mean "doesn't apply" or "don't know". If s is the SSN, and record a and record b both have null in them, then how do we interpret the expression (a.s = b.s)? If it means do the records for a and b have the same value in column s, you'd want it to be true. If it means does person a have the same ssn as person b, you'd want it to be an error. If it means is person a known to have the same ssn as person b, you'd want the answer to be no. Each of these interpretations has its justifications, but the last one is the one that is ultimately the most practical. If we want to test whether a column is null, we must use the "is" operator, not the equality operator.
So, the apparently minor distinction between key candidacy and uniqueness is quite large if any of the columns involved are allowed to contain nulls.
Now, for the practical consequences of getting this wrong. If you use Access' GUI tools to build queries against tables in an external database, Access when running that query does not allow the external database to optimize the query. You need to do a pass through for that. Instead, Access attempts to optimize the query itself, particularly I/O over the database link, which is presumably expensive.
So lets say table p is people and table r is region, and both tables are held on an Oracle database. I want to do a query which joins person to region to make a table of names and the regions they live in. Now it happens that Alice (person #25) and Bob (person #82) live in the same region, "North". The query correctly spits out ("Alice","North"), then continues on to Bob's record. Now it turns out that both Alice and Bob have refused to supply the SSN, so they both have null in column s.
What happens next is pretty mysterious, but I think we can infer two things. First, Access gets the issue of (null = null) wrong; at least some parts of Access do some of the time. Second, Access may be attempting to reduce external I/O, but it somehow tracks by what it thinks is the primary key. Whatever the cause, one often gets the sequence:
("Alice","North")
("Alice","North")
instead of:
("Alice","North")
("Bob","North")
which would be the correct one.
Oops.
I'd give you more information on reproducing this, but I don't use Access much. Like I said, I have talked to other da
Parent
Licenses (Score:5, Interesting)
Re:Licenses (Score:5, Funny)
Parent
Re:Licenses (Score:5, Insightful)
Parent
Re:Licenses (Score:5, Interesting)
Mod parent insightful, please!
I recall reading that MySQL AB really didn't stand a chance to force the GPL (and therefore, move to their proprietary license) on programs that connected to the database because that was "dynamically linking". Dude, WTF? Using protocols to communicate to a program or service is NOT linking! I got so angry when I read the news on the License change, that I wanted to tag the story "greedybastards".
But if MySQL AB told the truth, then nobody would buy their ultra-expensive license.
On the other hand, Sun and their promotion of Open Office (and open formats) is a proper example of Free software.
Let's hope things change for the good (for example, re-releasing the MySQL client software to LGPL or GPL+linking exception).
Parent
Re:Licenses (Score:5, Informative)
I understand where you're coming from, which is why I moved to Postgres for all my new applications last year. However, as it stands now, I think MySQL is within their rights to use the GPL for the client. As far as I know, there is no way to communicate with a MySQL server without linking to their client library (i.e., libmysqlclient.a). At one time there was an attempt to maintain a fork of the old LGPL MySQL 3, but it never took off. Now, merely linking to the client library doesn't automatically create a derived worked (see Linus's explanation [lkml.org]), however, in the absence of some other compatible library you could have linked with instead, it's pretty much impossible to say your linked program is independent of MySQL. And since independence is a requirement to have a non-derived work (i.e. the ability for a program to live a separate life, do something useful without the linked library), the program ends up being derived from the MySQL client, and has to abide by the GPL.
There is still plenty of argument around this topic, but again, it can be avoided by using Postgres, which IMHO is a better database anyway.
Parent
Not a rash move (Score:5, Informative)
http://www.news.com/2100-7344_3-5562799.html [news.com]
Re:Not a rash move (Score:5, Interesting)
But I think most people thought Sun might push PostgreSQL [sun.com] which is a nice database. Not sure why Sun would purchase MySQL, seems like an expensive PR move. I for one have seen Sun's product support deteriorate over the years, and hope they keep support for MySQL independent of the main line support. Or maybe this plays into Oracle as Oracle had or has an alliance with Sun. Is this alliance strained?
Parent
Wow! (Score:4, Funny)
I hear they paid an astronomical amount for MySQL. In fairness though, the code is stellar. The developers must be beaming with pride. If I were a shareholder, it would certainly brighten up my day.
PS: Sorry.
Here is the PR (Score:5, Informative)
"As part of the transaction, Sun will pay approximately $800 million in cash in exchange for all MySQL stock and assume approximately $200 million in options."
Re:Here is the PR (Score:5, Interesting)
Parent
Re:Here is the PR (Score:5, Interesting)
Perhaps Sun will be playing around with open sourcing some more of their hardware as a pseudo way of moving away from hardware, without actually losing all their hardware aquisitions.
But it is interesting to see how open source as a business model is evolving by allowing competitors to leverage off each other and still compete. Maybe what we are looking at is the "horizontalisation" of the market, I note that with speculation about an open sourcing of DB2 and Oracle databases, Microsoft's position in the market looks more and more isolated every day.
Parent
Yes! (Score:4, Funny)
Only one question (Score:4, Insightful)
Not that I distrust Sun's motives when it comes to free software. I mean they did a stellar job on OpenOffice.org, didn't they?
Why did they buy it? (Score:5, Funny)
What happens now with Oracle and PostgtreSQL? (Score:5, Interesting)
I think this is a move to sell support to their customers, like asking: "Do you need an Oracle Database?"
- If the answer is "YES", then we will sell you our servers and OS support
- If the answer is "NO", then we will sell you our servers and OS support AND MySQL / PostgreSQL support
There is a very good entry on a Sun blog about the cost of propietary databases and the "commodization" of this market:
http://blogs.sun.com/jkshah/entry/cost_of_proprietary_database [sun.com]
So why would SUN buy MYSQL - discussion! (Score:5, Interesting)
I thought SUN was currently bundling postgresql guess that wasn't good enough...
So up for discussion why buy mysql?
* Well you can't buy postgresql.....(Who to buy?)
* Wanting to hurt redhat
* You get ownership of the code (Since mysql has)
The "hurting redhat" is more for journalists "lets find a conflict thinking"
What else are the reasons?
Jonathan Schwartz's Blog (Score:5, Informative)
http://blogs.sun.com/jonathan/ [sun.com]
It would make MySQL easier to deploy... (Score:5, Insightful)
Dificult to say... (Score:5, Interesting)
Sun owns Java. Sun will soon own MySQL. If you have a Tomcat/J2EE environment running open source, you will soon be having to deal with a single vendor with control over your environment, because most systems only give lip service to PostgreSQL but fully support MySQL. Expect the support bills to go up.
On to RedHat and IBM, I think it is time for them to start funding the PostgreSQL project for real. Setup a more corporate entity to guide it and REALLY compensate the guys like Tom, Bruce, et. al. for so much hard work, which IMHO is above and beyond a standard pay check.
Re:Dificult to say... (Score:5, Informative)
-Brian
Parent
Oracle in Java (Score:5, Interesting)
Great news (Score:5, Funny)
Re:Sun? (Score:5, Interesting)
Parent
Re:Sun? (Score:5, Insightful)
Google just makes beta applications.
Regards,
Parent
Re:Sun? (Score:5, Funny)
Parent
Re:Sun? (Score:5, Funny)
And I even baked them a cake shaped like the internet!
Parent
Re:Yes they all work like slaves (Score:5, Insightful)
but what good are they if you are bound and 'forced' to work until 9pm each nite? or made to feel guilty if you DON'T stay for dinner and work a few hours after that.
all for the SAME PAY.
yes, its a slave life. you'll understand that when you get older (no insult intended; I didn't realize this until I hit over 40, myself.)
Parent
Re:Yes they all work like slaves (Score:5, Insightful)
Parent
Re:Great news (Score:5, Informative)
Parent
Re:Rewrite in Java (Score:5, Informative)
Sun already has an embeddable db engine written in Java called Derby [apache.org]. It has pretty impressive features and performance [apache.org].
Parent
Re:Im a sun employee (Score:5, Informative)
We added triggers, stored procedures, and views in 5.0. Today there are publicly several transactional engines (supported by companies like Oracle, IBM, Solid, and yes ourselves). There are many other non-public transactional engines.
Cheers,
-Brian
Parent