Slashdot Mirror
SAP and MySQL Join Forces
An anonymous reader writes "Heise Online is reporting that SAP and MySQL are going to cooperate (German article, you may want to use Google's translation). Short summary: MySQL and SAP are going to develop a new database server. 'The primary responsibility for the development and product management is with MySQL' says SAP spokesperson Karl-Heinz Hess. Until the new database is released, SAP will continue to develop its own free database system SAP DB, however it will now use the MySQL brand name." On a related note, IBM is introducing a low-end version of DB2.
A lot of code "mergers" tend to be announced, but nothing ever comes of it. The idea of a merged feature set sounds promising, but it is often difficult to merge the underlying code, which can be severely different even for features present in both code bases.
Additionally, for open-source or largely community developed projects, it's easy for the leaders to announce a merger or roadplan, but a whole 'nother game when it comes to getting the volunteer coders to actually do it; switching codebases or doing the grunt work of merges isn't the kind of this most hackers find sexy or appealing.
Point being, how much of this merger is something that's actually going to happen, how much is just a transfer of resources (versus merging of code), and so on?
...use SAP's db at their corporate site? If Microsoft still does, I can't imagine that this would help the relationship.
Isn't SAP the database formerly known as [Adabas]?
Kind of; IIRC, it is a fork of Adabas.
What exactly is MySQL contributing to this?
My guess is that the new database will be much easier to set up and manage than SAPDB in its current form. Have you ever tried installing it from source? Saying that it is nearly impossible to get it to compile is an understatement. Setting up a MySQL database is absolutely trivial by comparison, which is (IMHO) the primary reason for its popularity. I'd love to use SAPDB, but I don't have time to deal with the frustration that its installation involves; any improvement in that area would be a welcome change.
In Soviet Russia, Jesus asks: "What Would You Do?"
AFAIK It's a business package, although to describe it as "a business package" doesn't really do it justice. It's really something more akin to a business platform. It has a whole bunch of components for things that many businesses need, like purchasing, that sort of thing. It's also very programmable. My wife used to raise purchase orders on it. Is this a good thing? You betcha. MySQL is a good database, and this should help it grow - business perception will grow that this is a serious product.
This may be a low-cost gamble, considering SAP-DB is technically quite good but not very popular. MySQL still lacks a lot technically, but it sure has a big hacker following. SAP no doubt wants a piece of the enterprise DB pie and maybe they see Linux and Apache's success and think, "hell it costs peanuts to support the MySQL team and even though it's a long shot there's a slim chance we could start another revolution." Obviously this is pure conjecture but not an unreasonable explanation for what several people seem to be calling a strange move.
Plus, if you've got anything with "SAP" on your CV/resume, you can get a higher-paid job.
One of my colleagues has this theory that packages with (very) high entry costs - such as SAP - attract higher pay for experience than those with low/zero entry cost - such as most open source stuff and MySQL, which anyone and their dog can download for free & run on a $100 Linux box.
It's true that you can make good money doing something like SAP, but you sort of have to sell your soul to it. I did it for about a year and a half, I was very good at it, etc, etc, but it was really boring. Right now I would like a job in anything, even something boring :). But since I have been out of the market for a while, I am unlikely to be able to get an SAP job. They want to know what the latest implementation job you were on was, stuff like that. They will ask for experience with a specific version, for example.
So basically, if you want to work in it, you have to keep working in it. That is somewhat true in other fields, but I think stuff like SAP is exceptional that way--very closed. Hard to get into, and hard to get back into if you've been out.
Mind you this is not because you can't just jump in and pick right back up--you can. but there's a whole mentality surrounding all the work that says "sorry, you can't come back in". So something along those lines.
Liberty uber alles.
References to Non-Free Software and Documentation
A GNU program should not recommend use of any non-free program. We can't stop some people from writing proprietary programs, or stop other people from using them, but we can and should refuse to advertise them to new potential customers. Proprietary software is a social and ethical problem, and the point of GNU is to solve that problem.
The GNU definition of free software is found in http://www.gnu.org/philosophy/free-sw.html, with a list of important licenses and whether they qualify as free in http://www.gnu.org/licenses/license-list.html. The terms "free" and "non-free", used in this document, refer to that definition. If it is not clear whether a license qualifies as free under this definition, please ask the GNU Project by writing to licensing@gnu.org. We will answer, and if the license is an important one, we will add it to the list.
When a non-free program or system is well known, you can mention it in passing--that is harmless, since users who might want to use it probably already know about it. For instance, it is fine to explain how to build your package on top of some widely used non-free operating system, or how to use it together with some widely used non-free program.
However, you should give only the necessary information to help those who already use the non-free program to use your program with it--don't give, or refer to, any further information about the proprietary program, and don't imply that the proprietary program enhances your program, or that its existence is in any way a good thing. The goal should be that people already using the proprietary program will get the advice they need about how to use your free program with it, while people who don't already use the proprietary program will not see anything to lead them to take an interest in it.
If a non-free program or system is obscure in your program's domain, your program should not mention or support it at all, since doing so would tend to popularize the non-free program more than it popularizes your program. (You cannot hope to find many additional users among the users of Foobar if the users of Foobar are few.)
Sometimes a program is free software in itself but depends on a non-free platform in order to run. For instance, many Java programs depend on Sun's Java implementation, and won't run on the GNU Java Compiler (which does not yet have all the features) or won't run with the GNU Java libraries. To recommend that program is inherently to recommend the non-free platform as well; if you should not do the latter, then don't do the former.
A GNU package should not refer the user to any non-free documentation for free software. Free documentation that can be included in free operating systems is essential for completing the GNU system, or any free operating system, so it is a major focus of the GNU Project; to recommend use of documentation that we are not allowed to use in GNU would weaken the impetus for the community to produce documentation that we can include. So GNU packages should never recommend non-free documentation.
By contrast, it is ok to refer to journal articles and textbooks in the comments of a program for explanation of how it functions, even though they be non-free. This is because we don't include such things in the GNU system even if we are allowed to--they are outside the scope of an operating system project.
Referring to a web site that describes or recommends a non-free program is in effect promoting that software, so please do not make links (or mention by name) web sites that contain such material. This policy is relevant particulary for the web pages for a GNU package.
Following links from nearly any web site can lead to non-free software; this is an inescapable aspect of the nature of the web, and in itself is no objection to linking to a site. As long as the site does not itself recommend a non-free program, there is no need be concerned about the sites it links to for other r
funny thing is, they FUD the GPL on their own site, basically saying that if you write a commercial app that uses MySQL you HAVE to buy the commercial version.
The statement that you bump into the most:
You need to purchase commercial non-GPL MySQL licenses:
* If you distribute MySQL Software with your non open source software,
* If you want warranty from MySQL AB for the MySQL software,
* If you want to support MySQL development.
is both reasonable and accurate. Are you talking about some other statement on the site?
right, mysql is going to kick some ass thru this partnership.
Do you have any idea how much a typical SAP implementation costs? I'd bet the median price is $10 million dollars. In an implementation of that size you could probably trim 1% by shifting from DB2 to mysql. Nobody worth their salt would recommend such a rediculous move.
By the time they get SAP running reliably on mysql it will be four years down the road and the product will be completely reengineered.
In the meanwhile, I suppose there's some marketing benefit to being able to say "we'll be good enough to run financials off - some day".
There should be different classes of DBs for different purposes. You have Sleepy Cat's BerkelyDB which, from a RDBMS standpoint, is incredibly crippled, yet is uber-fast, requires little resources, and is iron-clad.
You have MySQL which is like BerkeleyDB but with more sugar, with a network-centric view, and meta-data. But it does not skimp on speed for features or safety.
I don't know if Microsoft Access is in the first class or second, I'd have to say first.
Then you have the true RDBMS, MSSQL, Oracle, DB2, and Postgres.
There is another class, object oriented databases (Versant, Intersystems Cache, ozone).
MySQL should revel in the fact that it is NOT a true RDBMS and often that isn't needed for many applications that are forced onto RDBMSs unnecessarily. A partner ship with SAP will not help, and I think it may raise the bar of expectations to high for MySQL. I just hope it's as fast and easy to deploy in the end.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Where are my mod points when I need them... seriously. I am sick of hearing people say that RDBMSs are crap or whatever because they can't deal with the fact that DOING HARD STUFF IS HARD.
In the development of a transactional processing system, once the volume of data becomes large and the needs for data integrity and manageability becomes overwhelming... you had soooo better be using a relational database. Object databases just aren't suited for the kind of work that is really important to the majority of applications (unless, at least, the object database is really just an access layer on top of a relational database).
:Wq
Not an editor command: Wq
But these issues aren't relevant to this thread.
The discussion is not about the "huge, complex application," R/3, it is about the database.
And in the context of R/3, the database is essentially an embedded component, a tiny part of the overall system, and one that isn't used with immense sophistication. Most big R/3 installs use Oracle, but, for the most part, not in a terribly sophisticated way. There is little if any use of "advanced stuff" like foreign keys, triggers, or stored procedures; the DBMS is used as a "data store," and isn't expected to be terribly smart.
There lies an interesting connection; that description historically describes MySQL fairly well, as a relatively unsophisticated data store. Make MySQL more robust and it might well make a nice "cheap" data store for R/3 . (Mind you, commercial licenses for MySQL cost hundreds of dollars more, per CPU, than, say, PostgreSQL...)
But the "resume connection" certainly doesn't appear to be the point...
If you're not part of the solution, you're part of the precipitate.