Re: Oracle buys Innobase

Chris Browne wrote:
> uwe@oss4u.com ("Uwe C. Schroeder") writes:
>
>>On Saturday 08 October 2005 21:07, Chris Browne wrote:
>>
>>> 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++...
>>
>>WOW - careful now. I'm german - but then, there's a reason why I
>>immigrated to the US :-)
>
>
> I'm 1/4 German, and a couple brothers married German girls, so I'm not
> trying to be mean, by any stretch.
>
> The bad Procrustean part is the "8 character mainframe" aspect, as it
> takes things that might have been mnemonic, at least to those knowing
> German, and distills things down in size so as to lose even that.
>
> It truly *was* Germans developing on MVS (or TSO or OS/360 or such)...
>
>
>>>     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 :-).
>>
>>SAPdb (aka Adabas D) is something I worked with quite a while ago. And you're
>>right, the naming schemes and restrictions, as well as severe
>>incompatibilities with the SQL standard where one of my major reasons to drop
>>that database in favor of Informix (at that time) and PostgreSQL later on.
>>It was kind of tough to generate explanatory table names with those kind of
>>limitations. Nonetheless back then (maybe around 1993) Adabas D was a quite
>>powerful and considerably cheap alternative to anything serious at the market
>>- and it was easy to sell to customers (back in germany) just because this
>>was THE database powering SAP R/3.
>
>
> And SAP R/3 has its own "8 character mainframe limits," often
> involving somewhat Germanic things, abbreviated :-).
>
>
>>But you may be right - considering what the codebase of SAPdb must
>>look like it's probably unlikely MySQL AB can make any considerable
>>improvements in the time available.
>
>
> When Slashdot sorts of people propose "Oh, that can just be another
> storage engine!", well, I'll believe it if I see someone implement the
> refactoring.
>
> In one of the recent discussions, someone proposed the thought of
> MySQL AB adopting the PostgreSQL storage engine as Yet Another One Of
> Their Engines.  Hands up, anyone that thinks that's likely tomorrow
> :-).
>
> What would seem interesting to me would be the idea of building a
> PostgreSQL front end for "Tutorial D" as an alternative to SQL.  I
> don't imagine that will be happening tomorrow, either.  :-)

But much more interesting to consider, indeed.