Chris Browne wrote:
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. :-)
But much more interesting to consider, indeed.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
