uwe@oss4u.com ("Uwe C. Schroeder") writes:
> Didn't MySQL AB acquire SAPdb (which was Adabas D before)? AFAIK
> (and you're welcome to correct me since I might very well be wrong)
> SAPdb supports transactions and foreign keys. If that's the case
> MySQL AB might be in a position to offer the bells and whistles
> without InnoDB support if they work out the deficiencies of SAPdb.
They did that indeed, or at least they acquired a license to SAP-DB.
(I think SAP AG retains license as well; this is akin to the way USL
sold SysV licenses to many vendors...)
The problems with Max-DB are twofold:
1. It isn't at all compatible with the "legacy" MySQL applications.
It is essentially a database system with a similar "flavour" to
Oracle version 7. That's not much similar to MySQL 3.x or 4.x.
2. The code base was pretty old, pretty creaky, and has a *really*
heavy learning curve.
It was pretty famous as being *really* difficult to build; throw
together such things as:
- It uses a custom set of build tools that were created for a
mainframe environment and sorta hacked into Python
- Naming conventions for files, variables, and functions combine
pseudo-German with an affinity for 8 character names that are
anything but mnemonic. (Think: "Germans developing on MVS.")
- I seem to recall there being a Pascal translator to transform
some of the code into C++...
Doing substantial revisions to it seems unlikely. Doing terribly
much more than trying to keep it able to compile on a few
platforms of interest seems unlikely.
When they announced at OSCON that MySQL 5.0 would have all of the
features essential to support SAP R/3, that fit the best theories
available as to why they took on "MaxDB", namely to figure out the
minimal set of additions needed to get MySQL to be able to host R/3.
If that be the case, then Oracle just took about the minimal action
necessary to take the wind out of their sails :-).
--
"cbbrowne","@","cbbrowne.com"
http://cbbrowne.com/info/linuxdistributions.html
Atheism is a non-prophet organization.