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?'"
If it's so great, why does SAP normally sit atop a different database, like Oracle or DB2?
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
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
Being GPL is not nearly as nice as being BSD. That's a big advantage of PostgreSQL (but not MySQL). In other words, if you want to sell an application which includes an embedded DB, then GPL is no good.
As far as I know, PostgreSQL is the only truly free database (in this licensing sense).
But I could be wrong -- I'm standing by to be corrected...
the statement about sap-db being on a par with oracle has forked this conversation off into a million "how can it be on a par with oracle" comments. not the question...
one fine example of this was the boss conversation thread (this one).
the point was, its an open source database, why aren't people using it INSTEAD OF PG/MYSQL.
i tend to agree with the complexity side of things as about 3 years ago i tried getting it up and running - without much success. although, friends of mine who know pretty much nothing about unix are running a web solution on apache jakarta (jsp+servlets) using SAPDB as the databaase which they installed from RPMs. they sing its praises all day long.
maybe its the communities fear of a traditionally large $$ corporation giving away its technology?
while it's certainly not the reason for all installations, it's likely that a large percentage of those places already had Oracle on site and not SAP-DB. and it takes a lot of effort and several really good reasons for most companies to switch databases. few have a database for this and a different database for that and a yet still different database for something else.
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.
Not sure what business a database has driving a tape deck directly anyway; one would hope that as far as possible the DB would let the OS figure such nightmares out. That's what OSes are for, although Oracle certainly seems to have forgotten that.
PostgreSQL does transactions, hot backups etc, would you consider switching to it?
Got time? Spend some of it coding or testing
We have been using SAP-DB on our production servers for almost a year now and I can absolutely recommend it if you are looking for a serious database.
We previously used Postgres for a long time but had two problems with it at that time:
- Postgres required daily database reorganizing (VACUUM) which was a problem in a 24/7 availability scenario
- Postgres didn't scale well beyond a few hundred concurrent database connections on SMP systems
This caused us to look for an alternative. After extensive testing with SAP-DB we decided to start using it on our production systems.
On our production systems we use both Red Hat Linux 7.2 and Solaris 8. On both setups SAP-DB has been rock-solid.
Some of our systems usually have 1000+ concurrent database connections, with all of those doing inserts and updates all the time. SAP-DB has shown that it is able to handle this kind of load without any performance or availability problems and without requiring any database maintenance.
If you are looking for a reliable enterprise scale GPL database, look no further: you'll love SAP-DB.
Main drawbacks for being a succesfull OSS project:
- source code structure takes getting used to
- database setup is quite straightforward, but documentation on getting it to work over ODBC etc. could be better, so new users would have an easier start
Last but not least, online support by the developers from SAP AG is excellent.
Jeroen Boomgaardt
Having used SAP DB as well, I have to agree. IT IS SO DAMM COMPLICATED. Makes Oracle look user friendly. I do agree SAP DB is better and has many "professional" features.
However, since it is damm hard to use and build I do not play around with it. As an example look how easy it is to build MySQL, Apache and PHP. DEAD SIMPLE. And look what are the biggest tools LAMP (Linux, Apache, MySQL and PHP) or WAMP (Windows, Apache, MySQL and PHP).
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
Both the DBM server and the Replication Manager server must run as user root. The files instdbmsrv and instlserver set the appropriate permissions every time these programs are built.
Seems like as good a reason as any not to use it. What daemons run as root any more? Especially ones that move large amounts of data around like RDBMS's.
We use Postgres or BerkeleyDB.
-- Azaroth
PostgreSQL does replication. PostgreSQL thrashes Oracle performance-wise in many situations. PostgreSQL costs just a little less than Oracle to buy and house. PostgreSQL was one of the first kids on the GPL block. The conclusion about a niche for SAB seems pretty much inevitable.
If PostgreSQL could magically don an Oracular CIO-level reputation, the bottom half - or more - of the Oracle market would evapourate in a few short years.
Got time? Spend some of it coding or testing
Heaven forbid you actually have to learn something about a database before you install and use it. Why, just about anyone could set one up if you didn't need to know anything.
And that is exactly why MS is around. Any moron (nothing personal mind you, just a generality) can set up a MS SQL database engine. Or for that matter, DNS, mail, etc.
Why should you need to know the things Oracle (or Postgress or MySql) asks you to? Because you need to know what the f*ck you are doing if you are going to manage any database that is important. How many disks should you use? Which data sets go on which disk? How about indexes? What ports should I use and why should I not use the defaults? Where are the default passwords? Why should my commit files be on different disks from my data and indexes?? Why do I need more than one copy of the parameter or control file?
If someone doesn't know the answer to the above questions, then they have no business calling themselves a DBA, or installing a real database that someone else uses or depends on.
Or, in other words, just because you can start a car doesn't mean you get to drive on the freeway.....you have to learn how to use it without killing anyone first.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
I'm a leaf on the wind. Watch how I soar.
i looked into sapdb over a year ago. it was hard to install. it lacked good perl support. those are both pretty huge issues.
i do find free software db's amusing though. they tend to be easier to install and manage then the closed source alternatives.
US Citizen living abroad? Register to vote!
SAP DB is a code fork of ADABAS-D, a database developed by "Software AG" in Germany. Initially, Software AG was meant to develop the database and SAP would sell it together with R/[2|3]. But ADABAS aka. SAP DB was buggy and unsuitable for larger installations.
...
;-)
Soon, the Internet came and everybody at SAP started loving Java. But the JDBC driver of ADABAS was (and still is) a big mess. The developers at SAP had spent their time fixing Software AG's bugs. Now, they had a stable database but no connection to their new applications
Incidentally, it was fashionable at that time to "give something away for free" if you were a big IT company so SAP decided to open-source SAP DB because it was no threat to their business and they had failed to replace Oracle etc. anyway.
SAP DB is a very good RDBMS and SAP is supporting it. But it just came too late to replace Oracle et.al. at SAP's customers and it came too late to compete against MySQL and Postgres on the "open source market".
However, since it's almost identical to earlier ADABAS-D versions, it's very popular among ADABAS users since Software AG changed their licensing policy for ADABAS-D
Rapunzel
Duh. Make sure it runs everywhere, and make sure you let everyone know you're going to be around for a while.
Personally, it's no good to me if it has no Pascal, Python or PHP (PPP) support under _both_ Win32 and *nix, or if I can't guarantee it'll be updated in a timely fashion (bug fixes, compatibility tweaks for new OS revisions, etc) after I go to significant trouble to install it.
Opportunity knocks. Karma hunts you down.
I've been the DBA for a company using SAP-DB as a bundled DB for the past 4 months. Let me outline the major reasons I'll avoid it in the future.
One, in the first week I was there my machine crashed. When it came back up the SAP database was corrupted. The PostgreSQL database running on the same box came back up fine. Not my idea of how a database should work.
Two, the command line sucks. This is a real problem for administrators and developers trying to understand how their queries are going to run. Every SQL query you want to run has to be prefaced with sql_execute and there's no multi-line buffer support. Putting a semi-colon on the end of your query (which is standard practice in Oracle or PG) causes a syntax error. Frustrating as hell.
Three, programmability is pathetic. No before triggers, only after triggers. No docs whatsoever on the procedural language extentions that would mirror PL/SQL or PL/pgSQL for example. Actually, they're there, but buried in the Reference Manual along with all the other SQL commands so you have a hell of a time getting your head into it. Some might say putting logic in the database is a design flaw. I have two words for you: "Oracle Financials". Billions in revenue from an application written almost entirely in stored procs. Encapsulation is a joke if you think it means putting logic in your Java. It's only going to protect data shared across applications properly when it's inside the DB in the form of rules, triggers, constraints, etc. First time someone calls up DBVisualizer or something and screws your data you'll understand. Scalability can come from distributed database instances just as easily as it comes from bloated application servers.
Four, no support now, nor any planned for making external calls ala Oracle or PostgreSQL so you can have triggers/procedures call programs outside the database etc. Think about all the noise about Message-Oriented-Middleware and then imagine that your database triggers could simply call external procs. Now put a trigger on your shipment table so that any time a shipment is updated it calls an external proc to email the parties involved in the shipment a status update. Saves a hell of a lot of code to encapsulate that at the DB since you *know* it can't be called unless the data was successfully updated. But you'll never be able to do it in SAPDB. Both Oracle and PostgreSQL support this today.
Five, creation, management, and maintenance are 10x what they are for PostgreSQL. You have to spend a lot of time trying to figure out what parameters to use for your database creation. Then you have to spend a lot of time watching over devspace allocations or you'll wake up to find the database hung cause you had somebody fill up the logspace. Same problem can happen on PG if you fill up the disk, but you probably already have sysad jobs checking for that in a production environment anyway.
Six, support is available if you think waiting for the folks in Germany to wake up and respond to your email is "timely". I don't. Meanwhile the PostgreSQL development team never seems to sleep. Those guys are always online, and always ready to respond to well stated questions.
In summary, I recently had to propose a database to one of my clients moving a 24x7 shop off of Oracle8i. I said PostgreSQL because it a) didn't corrupt data, b) had serious docs and 5 separate books out (of which you have to purchase at least two to get full coverage but at least they exist), c) had tools that were easily accessible and UNIX-friendly, d) was a breeze to administer, and e) had an active developer community that was 100x the size of the SAP community in case we needed help.
Why not SAPDB? More accurate to ask Why In Hell?
ss
MySQL may be "free" but it can become very costly if you have to engineer around limitations or its non-ANSI SQL compliance. The lack of subselects, unions, ACID compliant transactions, etc ad nauseum could be hugely significant. The same is true for many other open source databases, SAPDB included. Do your applications need a HIGHLY scalable concurrent multi-user OLTP database engine that is always on 24X365.25 (24X7) and does your database have proven, easy, and dependable backup and recovery capabilities? Will your apps ever grow and need a database engine that is robust enough to support this? If you're paying engineer/administrator salaries to work around these limitations of open source databases then it doesn't take too long to eat up and surpass the license costs of a commercial database. Too many people are making database decisions based on very simplistic and shallow criteria such as, "How much does it cost?" and they're only thinking in simplistic terms of cash outlay. The real cost includes learning curves for your developers and how much work is needed to work around the limitations. If your solution isn't scalable then you will have higher hardware costs. Are there standard DBA practices which you can depend on or do you have to figure it our yourself and hope you didn't miss anything? Can you risk data loss? Can you risk down time? Some people conclude that MySQL is fast but they only look at it from a single query perspective which is pretty stupid if you need concurrent multi-user OLTP access where MySQL can actually turn out to be pretty slow. The "benchmarks" provided by MySQLAB are shallow and poorly reflect on their sense of what is important. InnoDB can provide some solution but what if you can't take the database down but need to because that's the only way to add storage? SAPDB may handle some of these things better but if it's new, poorly documented, and its future is still uncertain is it worth the risk? If you have to spend time futzing with this stuff then that detracts from your focus on your own software/service/business solution. I guess some folks like to futz instead of focusing on the business at hand. Some folks think they can do anything and everything and would rather re-invent the wheel via an open source database engine than pay for perfectly good database software and focus attention on the business solution. It's kind of a perverse "not engineered here" mentality. If you standardize on a database with significant limitations then you are starting out by saying, "I will never need scalable, fault tolerant 24X7 access with a guarantee of no data loss. I have no ambition for the business and I don't want to be prepared for successful growth. My web service could never become an amazon.com or I don't care about this stuff because I'm willing to risk everything on the notion that I can do it all myself with free stuff I download off the net." There's a "nerd think" which says it's more fun and technically respectful to futz with open source stuff than it is to focus on a business solution.
All this having been said, it is quite possible to have a very good business solution which is built on top of an open source database engine but you had better know good and well what you're getting into and know what the limitations and challenges are BEFORE you get started. This in itself could become a major "research project." What's "tried and true" may not work for you. Looking for a "free" open source database engine? "Buyer beware." "You get what you pay for..." one way or another.
Re-moderate at "Off Topic," perhaps?
We are talking about SAP-DB, not SAP, the ERP....
Why, then, did this "America - The Republic that voted to become a Totalitarianism. [sic]" post earn a "Score:4, Interesting?"
SAP-DB and SAP are two totally different topics.
Oracle has offered me free apps as an incentive to use their database over a competitors so I don't think you are correct in saying they are all about their applications. But I guess that really depends on who you talk to inside the company. A database person will have a different opinion over an applications person.
You are right about their products being overkill for most companies out there. I've called Oracle knowing exactly what license I need. Before my conversation is over they've always tried to change my requirements and sell me more than I need. They've even suggested I change my server platform to Linux so I can free up some money for buying their additional stuff. If this continues to be their practice, other solutions, maybe even open source might be an alternative for me in the future. But I can see where companies can get tricked into getting more than they need and end up with overkill for a simple solution.
'Same speed C but faster'
- The build system is so unusual, i.e. completely 'off the wall', that without investing an inordinate amount of time I could not get SAP-DB to even build. "./configure && make; su -c 'make install';" it isn't! For this dedicated OSS devotee, that was a big black cloud forming on the horizon.
- I then installed off the provided CDs via the binary route, it's difficult to believe this, especially as I have been around these dumputer things for 30 years, but I could not find out in a reasonably simple or easy way how to start the daemon! By contrast, PostgreSQL tells you exactly what incantation to offer up at the end of the build process. Big black cloud overhead!
- It needs a minimum of 128Mb. At the the time I did not have sufficient memory on the evaluation machine.
- The web page with the technical information is ( was? ) completely cuckoo when viewed with Netscape 4.x or Mozilla. It's as slow as a wet week, and the information to read is stuck down in the corner in a truly miniscule font size. I'm being drenched in a black cloud rainstorm.
After all that I said to myself, "Umm... I think I'll carry on with PostgreSQL for the time being". Unfortunately for SAP AG time is still being.I have since got a more powerful machine with enough memory to at least try it out. When I've got a spare moment, I'll have another look at it. Spare moments are not exactly thick on the ground right now, so goodness only knows when that will happen.
This is because certain names in the page were censored by a particuarly wacked out legal action. This is SAP's way of getting the information across while complying with the decision, and letting you know that they've been censored to boot.