Slashdot Mirror
What is Holding SAP-DB Back?
Derek Neighbors queries: "The current story about MySQL 4.0 has erupted into a Postgres vs. MySQL debate. We at GNU Enterprise, who have used about all Free and Propietary databases, would like to know why exactly people arent using SAP-DB? It clearly is on par with Oracle, is GPL and frankly has an awesome support team in SAP AG. There was a PG vs SAP-DB recently. Someone else mentioned that you can get CDROMs for free. So again the question is 'What exactly is hindering a wider acceptance of SAP-DB in Free/Open Software projects?'"
Subject says it all. Probably also goes for Linux, (but the argument there would probably be more
"doesn't comes (integrated) with the distribution"
If something gets included with distributions, it spreads much faster
Another thing I forgot: sapdb is unhackable. If you ever wanted
to see what unmaintainable for normal people code looks like, go no further than to sapdb.
It is incredibly bloated and complex, very crufty internally, written in a weird pascal/C++ mix
with an SAP specific format for the files, has a build system that could be
only described as ununderstandable, no comments.
It is what you would expect from a 20+ years old codebase
I'm glad the SAP Berlin guys understand it (they seem to at least), but I see not much chance to do any changes
on your own. This makes it not very useful as a free software project.
Of course it is still nice that they offer it for free, but for all practical purposes it is like a binary only download. To be fair interbase has some of these problems too, but it has still relatively nicer source than sapdb. mysql is much better in this regard.
One thing that bothers the hell out of me is that no DB out there is easier to setup and use than MS SQL server...
In my job I have used literally every DB out there and none of them are easier to setup than Microsoft. It also the easiet to use from the application side. With oracle and other db's you need to know all kinds of listener and config info about where you dbase is. With MS and a few others you just need the servername and dbname and it works. Thats how things should be.
I am quite happy with the way MySQL is coming along.. they finally have a decent admin interface and the other feature they have needed for years... now if installation and usage were just a bit easier they could really compete.
There is a strong first mover advantage to Internet applications. For example, if you want to create a online shop, there are loads of free apps, tutorials and useful mailing lists for php/mysql. There are a lot less for php/postgresql. Almost none for php/sap-db.
Unless you are a software genius, the sensible choice is the one with most support in the community. Think perl, mysql.
This creates a network effect that your expertise gets added to the pool of knowledge and thus that pool becomes even more inviting.
Taken to the next step, you see fine languages like Python and fine databases like PostgreSQL fall behind in terms of support because their pool of expertise comes from a smaller number of users. But they do fine because there are so many developers out there who love them. These tools thrive with a a certain "less popular but more excellent" feel.
Sadly, if a third player comes along some years later, then they will have a very hard time getting a following big enough to generate the pool of expertise that leads to having lots of applications. Think Ruby, SAP-DB.
And its applications that determine popularity.
That is the short answer to the question - waht is holding SAP-DB back. Excellence isn't everything - being first on the scene gives huge advantages. And they were nowhere near first...
Patrick
1000s Warcraft Gold while you sleep
The company I work for uses alot of open source software in it's development - both in terms off server side (linux, apache, etc) and for the application side (Tomcat, JServ, etc).
We don't use SAP-DB because:
I dare say that if we had a pressing business case to learn the extra skill (i.e. we required some of it's fetures on a project that hadn't got the Oracle budget) then we'd consider it.
Then again there are other Dbs that would also cut it in that case too.
MYSQL has a big name in terms of Open Source software and that alone may prevent people from switching from it in favour of a less well known 'brand'.
Better the pride that resides in a Citizen of the world, than the pride that divides when a colourful rag is unfurled
It is...
1. harder to install, with a slightly strange mix of admin tools (combination of old/crufty, and new/experimental)
2. definitely trickier to manage, as you need to learn protocols for setting up, and backing up, databases and their logs, at least. This is true of other RDBMSs of course, but the trend has been toward more self-managing systems.
3. Relies of ODBC as the cli--which is actually fine (eg, compatible with PHP) but still less familiar to Unix/OSS people
4. Still undergoing stabilizing bugfix cycle, seemingly, although I haven't myself ever encountered a problem with it
5. Is, as mentioned, less tolerant of inexpert admins--and more problematic, the error codes are frequently impossible to understand
6. Really is difficult, at present, to hack. In general, the code is VERY challenging to work with (particularly the ugly, custom built build system), although it should be said that the SAP internal developers are steadily improving all aspects of the system, and a time WILL come when external developers can see rewards for their hacking efforts.
Compensating for this is the VERY skilled and responsive SAPDB development team, and a very strong feature set.
Matt
The originator of the thread should learn that technology doesn't change overnight, and certainly not without the kind of marketing budgets behind Java & C#. Change takes time.
As another answer, I'd ask what is the driving point behind SAPDB? MySQL has/had noteriety for being a very simple system; Postgres had noteriety for advanced research into ORDBMS'es as well as coming out of a university lab that produced two very successful commercial DBs in the past. What's the big focus with SAPDB? All I know so far is that it was an in-house thing that worked for SAP. No idea what that's supposed to mean to me. Maybe someone should answer that first.
Well, considering PostgreSQL is free, a whole lot less sorry for being picky, but it occurred to that some people might be lost in the irony.
PostgreSQL was never GPL'd. Not even copyleft, but just a plain free software license, can't remember if derived from BSD or MIT X. If one wants copyleft, SAPdb is the only choice now.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Becuase SAP DB doesn't support many of the critical features which are in the larger more respected database systems. The most important feature which is missing is transactions, ie: rollbacks, commits etc etc.
Umm, what are you talking about? Of course SAP DB (nee Adabas) has transactions; it's fully ACID, unlike, say, MySQL.
SAP DB is pretty much equivalent to Oracle 7.3.4 which is to say that it's a solid product for many real-world applications, but lacks many of the features for truly high-end deployment, like clustering, complex replication, guaranteed messaging, etc. I'd take Sapdb over MySQL any day, and probably over Postgres too. Another nice thing about SAP DB is that it can emulate Oracle's system tables, so an Oracle DBA can administer a SAP DB system very easily.
Also, SAP-DB doesn't have drivers for some of the more exotic tape systems, unlike DB2 or Oracle. The only tape system we could get working for backups with SAP-DB was an old single drive, manual loader DAT system.
Again, I'm not sure what you are talking about here. Do you mean you can't get an LSM plugin for SAP DB like you can for Oracle? Because that sort of stuff is really just fluff, you can do anything it can do with your regular storage manager (which may even be Legato) with a few simple scripts. I do agree that SAP DB's backup and recovery is primitive compared with Oracle's RMAN.
SAP-DB is pretty much the back end of SAP's commercial systems like SAP R/3.
It's a little more complex than that. SAP's R/3 product is an ERP system than competes with Oracle's ERP suite. For example, R/3 General Ledger competes with Oracle Financials. SAP were getting annoyed because every time they won a pitch against Oracle for ERP, Oracle ended up getting some money anyway, because R/3 required a database to run on, and Oracle was the most popular.
So, SAP bought ADABAS as tried to push ADABAS-D as the preferred database for R/3. That way, when they beat Oracle to win business, they would get all the business for themselves. Unfortuately, it never caught on, customers preferred Oracle, partly because it was a better product, and partly because they already had it and people who knew how to use it. So SAP were left with ADABAS-D which no-one wanted, so they renamed it to SAP DB to capitalize on their brand, and jumped on the Open Source bandwagon for some free publicity.
Theres an interesting parallel to that one. In Australia, there is the Fosters brand , which only tourists drink, as it's generally accepted to be shiet. There is also the much loved 'crown' brand.
Recently the glassie at my local bar told me that they where the same beer. I didn't believe him, so he did a test. He poured me a crownie and a fosters, and got me to blind compare them. I could not tell the difference. The moral here is that taste is *socially constructed*. That is in non sociology talk, we base our likes and perceptions on the social environment that we are exposed to. It's a wierd thing.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
Q. If it's so great, why does SAP R/3 normally sit atop a different database, like Oracle or DB2?
A. R/3 was originally written for Oracle, so this is a tradition. Up until now, SAP DB hasn't been marketed actively by SAP as not to upset it's many database selling partners. Newer applications are now developed for SAP DB first.
Q. SAP-DB is 20 years old. It has an unmaintainable code base. It is bloated and complex, very crufty internally and written in a weird pascal/C++ mix witha SAP specific format for the files and an uncomprehensible build system.
A. I prefer the word challenging. Parts of it are of course constantly rewritten, so I don't think a single part is actually 20 years old. And I object aliasing '!= make' with 'incomprehensible'. The concepts are actually pretty close to newer build systems like ant. Without it, the criticism would simply read that the make files are incomprehensible.
Q. SAP-DB needs a lot of effort to set up and create a database, sometimes even worse than the magic juju you need to go through with Oracle.
A. Not really true, especially not for a production database. But the entry level documentation could be made better by describing when and how to keep things simple.
Q. Oracle does replication and hot standby. SAP-DB doesn't. These are pretty important features in the enterprise.
A. Replication is not on our agenda (despite the oddly named Replication Manager). Hot standby is currently being implemented.
Q. Not in BSD Ports tree. Probably also goes for Linux, (but the argument there would probably be more "doesn't comes (integrated) with the distribution" If something gets included with distributions, it spreads much faster.
A. True. But our main job is to supply SAP DB for SAP customers. Anything else has to be done by others interested in SAP DB.
Q. harder to install, with a slightly strange mix of admin tools (combination of old/crufty, and new/experimental)
A. Partly a documentation problem. There isn't actually a mix of old and new admin tools. There is a command based API, which is accessible from various programming languages, and there are tools which are implemented on top of this API.
Q. definitely trickier to manage, as you need to learn protocols for setting up, and backing up, databases and their logs, at least. This is true of other RDBMSs of course, but the trend has been toward more self-managing systems.
A. SAP DB is mostly self managing. Some of the tasks were it isn't have severe performance implications (like distribution of data volumes over disks) so simply picking a default is questionable at best.
Q. Relies of ODBC as the cli--which is actually fine (eg, compatible with PHP) but still less familiar to Unix/OSS people
A. There is no standard database API for Unix. But of course anything would be better than a Microsoft API.
Q. Still undergoing stabilizing bugfix cycle, seemingly, although I haven't myself ever encountered a problem with it
A. Insert lame joke about Linux 2.4.
Q. Is, as mentioned, less tolerant of inexpert admins--and more problematic, the error codes are frequently impossible to understand
A. We should probably supply a tool which makes information about the error codes easily accessible from the command line.
Q. Really is difficult, at present, to hack. In general, the code is VERY challenging to work with (particularly the ugly, custom built build system), although it should be said that the SAP internal developers are steadily improving all aspects of the system, and a time WILL come when external developers can see rewards for their hacking efforts.
A. True. Although I still object to the notion that make was presented to mankind on the mount Sinai.
Q. Does SAP have anything close to Oracle's RMAN?
A. SAP DB logs all backups. The DBMGUI can use this log to automate tasks like 'restore from this full backup to this timestamp'. This works also with external backup tools.
Q. Sect Where's the O'Reilly book on SAP-DB?
A. It took some time for PostgreSQL to get books so I guess a SAP DB book is still a year or two away.
Q. Does it have Multi Concurrency Version Control (MVCC)?
A. It is implemented in the undocumented object database part. There are plans to make this also available to the relational database part, but a release date has not been set.
Q. Are there any Free Software success stories of projects using SAP-DB?
A. So far, SAP DB seems to appeal mostly to commercial software vendors for whom Oracle or MS licenses are too expensive/bothersome.
Q. Are there better admin tools?
A. No. Or not yet. But the administration is easily scriptable, so most common tasks can be reduced to a single command.