Обсуждение: SAPDB/MaxDB
Hi, It may be a non-starter in this forum for a discussion, but I'd be curious to know what people think about SAP's former SAPDB, now MaxDB. This was SAP's first venture, I believe, into open source. What do you think about it? What do you think SAP should have done back then? What do you think SAP could or should be doing today? Could it benefit the PostgreSQL community in anyway? Thanks, Dirk ---- http://www.riehle.org
Dirk Riehle wrote: > Hi, > > It may be a non-starter in this forum for a discussion, but I'd be > curious to know what people think about SAP's former SAPDB, now MaxDB. > This was SAP's first venture, I believe, into open source. What do you > think about it? What do you think SAP should have done back then? What > do you think SAP could or should be doing today? Could it benefit the > PostgreSQL community in anyway? One major problem is that the the SAPDB code was a mixture of Pascal, Python, and C. The directories were two letters long, and the file names were numbers. You combine all that, and it is easy to see why no volunteers really got involved with the code. Also, with PostgreSQL around, it is hard to get volunteers for a new database project with similar goals. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
A long time ago, in a galaxy far, far away, dirk@riehle.org (Dirk Riehle) wrote: > It may be a non-starter in this forum for a discussion, but I'd be > curious to know what people think about SAP's former SAPDB, now > MaxDB. This was SAP's first venture, I believe, into open source. What > do you think about it? What do you think SAP should have done back > then? What do you think SAP could or should be doing today? Could it > benefit the PostgreSQL community in anyway? As Bruce pointed out, the codebase for SAP-DB (aka MaxDB, aka Adabas-D) was written in a simultaneous combination of: - mainframe acronymese - German - Pascal - C++ which, in the presence of custom build tools that were very much *not* Make/autoconf, made for an enormous "learning curve" in order to get involved with the codebase. As far as SAP AG was concerned, the point of it was NOT for them to get into OSS; it was for them to come up with a lever to beat on Oracle with. Every so often, SAP and Oracle get into fights over their relationship; SAP sells more Oracle licenses than anyone else on the planet, which makes for a love/hate relationship on both sides. On the one hand, R/3 + Oracle makes both companies a barrel of money, so they otta love one another. On the other hand, Oracle sells some ERP software, and would rather get *ALL* the licensing fees. If SAP had their own database, they could play the same game back, hence the late-90's acquisition of Adabas-D. In principle, SAP AG ought to be able to readily do ports of their software to run atop PostgreSQL (just as they do on Oracle, MS-SQL Server, Informix, Adabas-D, and DB2), as PostgreSQL has enough functionality to host something like R/3. I'd say that there's a little bit of danger in such interest; it means getting in between SAP AG and Oracle Corporation, and with the amount of competitiveness between those companies, that seems to me to be a dangerous place to be. MySQL AB tried getting into that spot, and Oracle spent last year buying storage engines out from under them. Doesn't sound like a fun place to be to me... -- (format nil "~S@~S" "cbbrowne" "gmail.com") http://cbbrowne.com/info/slony.html Signs of a Klingon Programmer - 20. "Behold, the keyboard of Kalis! The greatest Klingon code warrior that ever lived!"
Christopher Browne wrote: Chris comments are spot on. In my thesis paper [1] I came to the conclusion that in the end SAP's best move was to hand over SAP DB to MySQL AB, not because MySQL AB could magically make the database relevant in the OSS space, but because both companies then lended eachother credit .. SAP lended MySQL AB credit in the enterprise world. And MySQL AB lended some credit to SAP in the OSS world. Now that MySQL is close to SAP certification, SAP is getting where they want things to be .. they want the database market commoditized so that Oracle does not earn tons of money they can use to hit SAP in the CRM/ERP market with acquisitions. Originally SAP (who still employ 100 developers for MaxDB) and MySQL AB were planning to develop an entirely new database together. I think that one is off the table now. Finally MaxDB does offer some interesting features. The main one being that they require no maintaince at all. All reindexes and structures are immidiatly brought into optimal condition. There is nothing like OPTIMIZE TABLE or VACUUM necessary. Their point being that the database should work with a constant performance in 24/7 shops. regards, Lukas [1] http://pooteeweet.org/blog/534
*snip*
>
>
> Finally MaxDB does offer some interesting features. The main one being
> that they require no maintaince at all. All reindexes and structures
> are immidiatly brought into optimal condition. There is nothing like
> OPTIMIZE TABLE or VACUUM necessary. Their point being that the
> database should work with a constant performance in 24/7 shops.
>
> regards,
> Lukas
theoretically this is all fine but did you every try using it?
say, something which is beyond "select * from table".
it is a nightmare. the documentation sucks and whenever something goes
wrong I'd highly suggest to quickly donate to the church to make sure
that at least god considers helping you.
i also remember funny bugs such as "i cannot replay my binary backup
because of error 43412341234123123213412412542314214").
maxdb is far from good and if you ever looked at the code in there you
will soon find out that this is not what you want to use.
to me maxdb is more of a marketing name than a serious database.
best regards,
hans
--
Cybertec Geschwinde & Schönig GmbH
Schöngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at
On 1/11/07, Hans-Juergen Schoenig <postgres@cybertec.at> wrote: > theoretically this is all fine but did you every try using it? Actually, yes. > say, something which is beyond "select * from table". Most certainly. > it is a nightmare. No it's not. > the documentation sucks and whenever something goes > wrong I'd highly suggest to quickly donate to the church to make sure > that at least god considers helping you. Nope, I've always had great support from SAP with SAP DB. > i also remember funny bugs such as "i cannot replay my binary backup > because of error 43412341234123123213412412542314214"). Hmm, I can think of similar bugs in EVERY other database. > maxdb is far from good and if you ever looked at the code in there you > will soon find out that this is not what you want to use. While the code isn't laid out very nicely, it isn't that bad if you know understand the subsystems. The main PITA is the proprietary build tools/environment... I recall having major issues getting their translator to work on FreeBSD. > to me maxdb is more of a marketing name than a serious database. Disagree. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/