uwe@xxxxxxxxx ("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. :-)
--
(reverse (concatenate 'string "gro.gultn" "@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/oses.html
Rules of the Evil Overlord #200. "During times of peace, my Legions of
Terror will not be permitted to lie around drinking mead and eating
roast boar. Instead they will be required to obey my dietician and my
aerobics instructor." <http://www.eviloverlord.com/>
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
