Forgot your password?
typodupeerror
News

What is Holding SAP-DB Back? 457

Posted by Cliff
from the yet-another-RDBMS-question dept.
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?'"
This discussion has been archived. No new comments can be posted.

What is Holding SAP-DB Back?

Comments Filter:
  • by oingoboingo (179159) on Monday August 05, 2002 @09:32AM (#4011444)
    If it's so great, why does SAP normally sit atop a different database, like Oracle or DB2?
  • Oracle (Score:2, Informative)

    by yatest5 (455123)
    It clearly is on par with Oracle

    I think you'll find one of the main strengths of Oracle is it's REPUTATION. People know they can trust it as its been around for years and 'everybody' uses it.

  • by Anonymous Coward on Monday August 05, 2002 @09:34AM (#4011458)

    sapdb 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.

    What surprises me more actually is that Interbase/Firebird is not more successfull.
    It is free and as simple to set up/use as mysql in my opinion, but avoids most of the
    mysql limitations.
    • bad source code too (Score:5, Informative)

      by Anonymous Coward on Monday August 05, 2002 @09:39AM (#4011492)

      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.
      • by Dark Fire (14267)
        I agree. The sapdb uses a non-standard build system instead of open source tools like automake, autoconf, make and/or ant. Actually, ant would be a nice build tool for sapdb. Converting to a standard build tool would really help get more open source developers interested in trying to unravel and improve the code. While the pascal/c++ mix might be strange, I think someone would hack-a-way at it (I would) anyway if the build tools had an atleast familiar feel. When I setup sapdb, it was definitely more difficult to setup than mysql. I really liked the feature set and I almost used it for a production project I am working on now. It has a lot of potential, but sap is going to need to push towards using the tools the open source community is familiar with.
      • SAPDB is not bad. The only reason we chose against it here (a fortune 100 SAP using company) is that we have DB2 EE very firmly entrenched.

        SAPDB is very easy to maintain, using the SAP tools. I had no major issues with it on our non-prod test system. Why the heck would you try to "hack" it? That's like trying to re-make SSAA or ST03 just for fun. Use it, like it, don't like it, whatever. The tools SAP provides are frequently cheaper, as nice, and as easy to maintain as third-party offerings.

        -WS

        • by Chasuk (62477)
          America - The Republic that voted to become a Totalitarianism.

          Nice .sig - I agree with the sentiment completely - except that it is grammatically incorrect.

          One can be a totalitarian - but not a totalitarianism. The fact that a "Republic" (sic) is a plurality does not change this.

          For example, consider the following conversation:

          Me: "Of what political affiliation are you?"

          Bill Clinton: "I'm a Democrat."

          Bill would not say, "I'm a Democratic," obviously. Neither would George Bush answer, "I'm a totalitarianism." Well, perhaps he would, but only because he is an idiot.

          I suggest rephrasing your .sig thusly:

          America - The republic that voted itself into totalitarianism.

          This isn't a flame or a troll, or even much of a nitpick. I just happen to agree with you, and would like to see an opinion with which I am in concurrence expressed more eloquently. :-)
      • by tommck (69750) on Monday August 05, 2002 @01:12PM (#4012878) Homepage
        has a build system that could be only described as ununderstandable

        That's not a word! You should have said "derstandable"! ;-)

        T

    • 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).
    • From the SAP db install documentation on the website:

      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

    • The documentation on how to get started on Firebird seems to assume that you are using Borland Delphi or (possibly) Borland C++. Were I only using Linux, then I would already have Postgres installed, so I'm not sure what I would gain from Firebird. When I'm on Windows, and Firebird might be an advantage, I still only have a gcc compiler (via CygWin).

      And in any case, the language that I would want to call it from would be Ruby (or possibly Python), and while there are ways already defined to call MySQL, PostGres, BerkeleyDB (SleepyCat), etc. from those languages, it appears that I would need to write an access method to Firebird by myself*, and I don't see why it would be worth the effort. I'm not saying that it wouldn't be, but the documentation seems to assume that I already know why this would be a worthwhile thing, and I don't.

      * The Ruby Interbase access method is at version 0.03 (though it is reported to be working fine). Python also has an access method for Interbase (and it says that it works with Firebird, too), but it isn't a part of the standard distribution. Still, that would probably work with few, if any, adaptations. So this isn't a major effort, but why to bother isn't clear.
    • Both SAPDB and firebird have much better documentation then either mysql or postgres too.
  • tried it .. crashed (Score:2, Interesting)

    by Anonymous Coward
    i recently installed the latest sapdb and followed the HOWTO instructions from their website. while running the db_cold command, the server crashed with sigsegv. :( i was too lazy to look for further help and/or report the bug. right now i try out firebird (interbase), which didn't crash yet *g*
  • Hmph (Score:2, Interesting)

    by ViceClown (39698)
    After checking out the SAP-DB website... now Im wondering just why more people aren't using it? Looks like it has a good feature set. Does anyone know if there are php functions for it? A quick scan of the php web site didn't turn up anything...
    • Re:Hmph (Score:3, Informative)

      by stilwebm (129567)
      The PHP comment brings up a good reason why it has not yet taken off. MySQL and other open source DBs have widespread support in applications and more importantly, developer communities. People who are comfortable developing with and even for those packages will continue to develop with and for those packages. As more community resources are available, more people will become comfortable using SAB DB.
    • by yivi (236776)
      http://www.tripuls.de/deut/zg/prod/datenb1.htm

      I think that this is what you wanted.
  • SAP-DB (Score:2, Informative)

    by Anonymous Coward
    All this talk about free database servers tends to fly in the face of mission-critical nonstop environments. Personally at our company, I have pooh-poohed the free DB's and rather pay a little more for centralized support and two good DB administrators.

    As much as everyone maligns M$, nobody ever puts in MS SQL in the conversation. (We're a DB2 shop not M$) .sig

    beware of the trolls
  • On par with Oracle? (Score:4, Informative)

    by Anonymous Coward on Monday August 05, 2002 @09:36AM (#4011478)
    Oracle does replication and hot standby. SAP-DB doesn't. These are pretty important features in the enterprise. Therefore, SAP-DB is not on a par with Oracle. What do you do if you need to work on your primary database machine and you don't have a standby?
    • I know you're responding to someone else's claim about SAP-DB being on par with Oracle, but the meaningful question is whether SAP-DB deserves more recognition as a free software database solution, isn't it? What do you do if you need to work on your primary database machine and you're running PostgreSQL? You take the machine down in a maintenance window, and if necessary, put up a secondary machine that is "manual standby."

      SAP-DB is pretty much the back end of SAP's commercial systems like SAP R/3. I'm sure there are things that Oracle does that SAP-DB doesn't (just like there are systems that actually do things Oracle doesn't, even though your Oracle sales rep won't admit it), but it's difficult to argue that the system doesn't have credibility in the enterprise.

      It also supports Microsoft's cluster server on Windows, with failover; they're working on a cross-platform solution for hot standby, according to the website. It does have a batch mode replication manager, too, at least.

      • by sql*kitten (1359) on Monday August 05, 2002 @10:52AM (#4011910)
        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.
    • by leonbrooks (8043) <SentByMSBlast-No ... .brooks.fdns.net> on Monday August 05, 2002 @10:33AM (#4011785) Homepage
      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.
      • by leandrod (17766) <{l} {at} {dutras.org}> on Monday August 05, 2002 @10:45AM (#4011854) Homepage Journal
        >
        PostgreSQL costs just a little less than Oracle to buy

        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 one of the first kids on the GPL block.

        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.

        • 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.

          What's the advantage of using a copylefted product over a MIT/BSD licensed product? There's none that I can see unless you're going to hack it, and even then, it depends on what you want to do with the end result.

      • by ClarkEvans (102211) on Monday August 05, 2002 @12:31PM (#4012569) Homepage
        PostgreSQL was one of the first kids on the GPL block.

        No, it was one of the first on the Open Source block, specifically it has a BSD license. And SAP-DB needs to beat PostgreSQL on several counts for it to be considered:

        (a) features, PostgreSQL has them in spades, (b) stability, PostgreSQL is solid, (c) licensing, you can't beat BSD, and most importantly, (d) community, PostgreSQL's user community is just a fanstatic group of fellas.
  • by marcovje (205102) on Monday August 05, 2002 @09:37AM (#4011481)

    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
  • People don't know ? (Score:2, Informative)

    by DarkDust (239124)
    Well, I just learned only a week ago that SAP released (part of) their DB as open-source. Everyone and their dog know that MySQL and Postgres are free, but I guess SAP's DB being free as well is a fact that is not well known enough.
  • by skryche (26871) on Monday August 05, 2002 @09:40AM (#4011497) Homepage
    Has anyone else noticed the mysterious blacked out sections on the SAP-DB history page [sapdb.org]? Creepy.
  • by MORTAR_COMBAT! (589963) on Monday August 05, 2002 @09:40AM (#4011498)
    that SAP DB isn't supported out of the box by Java, Perl, or PHP, etc. but one quick glance [sapdb.org] shows they support Perl through DBD::ODBC, have an ODBC driver suitable for PHP, and supply a JDBC [sapdb.org] driver for Java programs.

    so now i'm wondering what the catch is. too big? bloated? slow?

    well, the minimum requirements on Linux [sapdb.org] list a base memory footprint of 128 MB. MySQL runs on just about the smallest box you own, and most people tinkering with MySQL are on budgets of $0, meaning, no new bigger boxes for a long, long time.
  • by sys49152 (100346) on Monday August 05, 2002 @09:45AM (#4011520)
    ... and I've taken a look around for other RDBMSs. Maybe the problem is that it's flying a little under radar.

    However, I have had the same question in relation to the open source version of Borland's Interbase, the Interbase fork - Firebird, and the hsql Database Engine.

    It seems to me that the community has latched on to MySQL and PostgreSQL as -the- database solutions, and this very acceptance places them higher up the food chain. For instance, hunt around for an open source based Content Managemnet Sysytem (ala SlashCode or PostNuke), and almost invariably it has a MySQL backend.
    • Its lack of popularity is probably due to a phenomenon called "market share" where the first ones that get noticed in the market generally enjoy a dominate position with little effort. Too bad too many CS students get caught up in the "I can make a difference" funk of open source software and spend their most creative and energetic time of their careers hacking something that has only a slim chance of really becoming a big deal. Had they gotten a job, weather it be in an open source type company or even making commercial software, some people might understand this.

      It might also have something to do with the fact that SAP itself is pretty much known as a big deal to install. This might be the reason why their clients are mostly Fortune 1000 - it costs a lot to install the software after you buy it.

      • by WinterSolstice (223271) on Monday August 05, 2002 @11:15AM (#4012063)
        SAP really is not the kind of thing a smallish company would want. It's a huge, modular, proprietary, complex piece of work. It has its own language (ABAP), it has its own "OS" (Basis), and it is designed to own everything it touches. I have lived and breathed SAP at my company for over 2 years now (as a Basis admin), and I can tell you that unless you wanted a 1 stop ultra-integration system, it is not for you.

        SAP is sweet in that it is incredibly easy to control the flow of money and goods around a system, but everything requires customization. This is not OTS software. A typical install takes 2 years, and just handling an upgrade will be the hardest 4-5 days of your life. We did 3.1H to 4.6B in a 3 system (development, quality assurance, production) landscape in 2 weeks, and I think we darned near set a record.

        SAP is definately only for really large commodity driven companies. If I were the CTO of a medium size business, I would not use an ERP like SAP. I'd use something much lighter weight. Of course, if I were Amazon, Dell, Anheiser-Busch, Pepsico, etc. I would be using SAP. Nothing else comes close when you need to know what, where, when, and how much.

        -WS

        • SAP is definately only for really large commodity driven companies. If I were the CTO of a medium size business, I would not use an ERP like SAP. I'd use something much lighter weight. Of course, if I were Amazon, Dell, Anheiser-Busch, Pepsico, etc. I would be using SAP. Nothing else comes close when you need to know what, where, when, and how much.

          And of course there's always a little IBM product called AS/400...

        • 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.
  • Documentation (Score:3, Insightful)

    by Fished (574624) <[moc.liamg] [ta] [yrogihpma]> on Monday August 05, 2002 @09:48AM (#4011538)
    Where's the O'Reilly book on SAP-DB?

    It doesn't exist. The bottom line is that most websites and the like don't need all the features of Oracle. In fact, they don't even need all the features of MySQL or PostgreSQL. Most of them could probably run fine on DBASE. So, the fact that SAP-DB has sixteen billion enterprise features doesn't really make a difference. Combine this with a total lack of third-party documentation for SAP-DB, and it really makes sense to stick with the "standards."

    Incidentally, another problem is that, when I develop a web app, I know I can easily find hosting on PostgreSQL (my preferred DB). What hosting providers run SAP-DB? The bottom line is that most web apps run on hosted servers that often don't allow people to run their own DB engines, so this is a big issue.

  • by DigitalCH (582593) on Monday August 05, 2002 @09:49AM (#4011540)
    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.
    • With MS and a few others you just need the servername and dbname and it works.

      Actually, with MS you only need the servername and it's as good as 0wn3d (-: and with the advent of SQLsnake, you don't even need that :-)

      PostgreSQL is a lot more standard and complete than MySQL, outruns it in many practical situations (ie under enough load that anyone actually cares about performance) and is as easy to set up and use (if not easier) than MySQL; it also has simpler, clearer licencing. The mystery to me is why MySQL has done as well as it has in the face of all of this.

      InterBase also seems to hammer MySQL pretty much across the board, but was a late starter. I'd expect to see it do some catching up as more of the application languages abstract their DB interfaces, detaching the DB choice somewhat from application programming and so allowing the DB to be chosen on merit rather than I-was-here-first.

    • 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.
    • Your claims are bullshit. Oracle has a few more options when it comes to client server connectivity. However unless your DBA's decide to go out of their way to make things more complicated, client connectivity in Oracle is a simple matter of "servername"+"dbname".

      Oracle does get unecessarily complicated when you start attempting to implement their more interesting "enterprise" features. However, you don't seem to be aware of these on either the Oracle or Microsoft end of things.
  • Already using it (Score:2, Informative)

    by TheICEBear (536953)
    We are in the process of finishing a large J2EE project with the database end running on SAPDB and we have had no regrets. It runs along smoothly and in fact the only annoyance with it has been a crufty manager application for datamanipulation (for tests), which was remedied by using Access as an ODBC client and a little trouble with the actual creation of a database. The same database has had a 3 months run under load and with the developers hitting it with the weirdest commands and it has only needed one service restart so far. I recommend it.
  • Applications (Score:5, Insightful)

    by Captain Kirk (148843) on Monday August 05, 2002 @09:52AM (#4011554) Homepage Journal
    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
    • More and more scripting languages (PHP, PERL, Ruby, Python, TCL) are working through generalised DB interfaces; there is less and less difference (often none) between backend DB's from an application programmer's PoV.

      In some cases the backend DB needn't even be SQL (great news for tiny high-performance web apps), but where the backend DB does stick closely to SQL standards the applications produced with it are more likely to be portable and scalable.
  • Because... (Score:2, Funny)

    by Anonymous Coward
    For me the reason is because it _IS_ licensed under the GPL.

    I'll take PostreSQL any day, thank god for that license.
    • Why does that matter?

      GPL deals with modifications, not what you use the software for.

      Are you modifying Postgre for your installs? Do you give the source code to those modifications for the people you install it for? If so, then GPL isn't an issue
  • Speaking of ANY commodity:
    There will only be two or three REALLY popular entrants, the rest will be left to muck about with single digit usage.

    Without belaboring GPL v. Microsoft v. Oracle, I'd recommend you look at the Cola Wars: Coke has the margin (60%+), Followed by Pepsi (30% ish) and _everybody else_ scrounges around for the ramaining 10%.
  • by Thackeri (203958) on Monday August 05, 2002 @09:57AM (#4011581)

    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:

    1. Our clients break down into 2 camps - those who want cost-effective solutions (so we go down the open source route of Tomcat/MYSQL) and those who want brand-labelled solutions (so we use JRun/Oracle etc).
    2. We need to limit our support base. Having gained skills in maintaining MYSQL, Oracle and [shudder] MS SQL Server adding another DB to that side makes life harder for us in the short to medium term.
    3. Until this article I (and most of the developers here) hadn't heard of SAP-DB!

    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'.

    • SAP DB is also what used to be known as Atabase. SAP purchased it in typically mega-corp fashion. It's hard to make an argument for SAPDB when you already support Oracle or MS-SQL, since SAP runs just fine on both of those. The only real reason to use SAPDB is if you have heavy SAP Basis people, and only part-time DBAs. SAP on other DBs is a full time job.

      -WS

  • by Chuck Messenger (320443) on Monday August 05, 2002 @09:59AM (#4011599)
    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...
    • that's a neat trick - being able to talk out of your ass.

      listen sport, you can use gpl in embedded systems. you've heard of the tivo, right?

      there are differences between bsd and the gpl. and they have different strengths. but it would be really nice if bsd advocates would quit being such twats.
  • by mydigitalself (472203) on Monday August 05, 2002 @10:00AM (#4011605)
    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 [slashdot.org]).

    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?
  • by Qbertino (265505) on Monday August 05, 2002 @10:02AM (#4011616)
    It's "Industry Standard".
    I mentioned Firebird the other day when a guy asked /. about a MySQl update feature. People didn't give a shit.

    We use what we're used to, even if it's outdated or pointless. Other stuff is of no interest, Try telling a guy the advantages about Linux over WinXP and you'll know what I mean.
  • by Monkius (3888) on Monday August 05, 2002 @10:10AM (#4011648) Homepage
    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.

  • time (Score:5, Insightful)

    by denshi (173594) <toddg@math.utexas.edu> on Monday August 05, 2002 @10:16AM (#4011681) Homepage Journal
    Time is the thing 'holding it back'. As Paul Graham pointed out, "Inventors of wonderful new things are often surprised to discover this, but you need time to get any message through to people. ... It's not when people notice you're there that they pay attention; it's when they notice you're still there." No matter the benefits of SAPDB (which I have not used), it still has to keep hacking it while people subconciously adjust to the existense of another valid product. This inertia is everywhere, it is the normal thing to do... 3 years back, even when it was obvious that Postgres kicked MySQL's ass 6 ways from Sunday, many people kept using MySQL. It was a known quantity, and this new thing was just something with some wild claims that users didn't take time to validate. A couple years later, the LAMP crowd is/has finally moving/moved towards Postgres; it's not b/c of anything developed last year, it's just that users have realized that it's not going away. Same problem here, scaled back several years.

    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.

  • by Anonymous Coward on Monday August 05, 2002 @10:26AM (#4011732)
    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
    • I'm trying to not argue, but understand the two reasons you listed.

      I'm not against PostgreSQL, Interbase/Firebird, or SAP-DB, I'm just wanting to know why. (I am against MySQL in a medium to large production environment, but we'll wait until 4.1+ materializes.)

      First point, "VACUUM" problem. What's wrong with a cron job to do this, nightly? Does it bog the system down too much? Is it unreliable? (I haven't noticed any problems, but my DB is small, right now.) Read about MVCC (I think it's something like multiple version concurrency....) Versioning is better than redo logs, in theory. You need to understand MVCC to understand VACUUM. You can VACUUM live, without killing the DB, and perform hot backups as well, due to MVCC.

      Second point, have you tuned it, and are you using PG 7.2+? If you are using older PostgreSQL's (prior to 7.1,) then yes, this is a problem. If you haven't tuned it, there are great docs about tuning. Supposedly, PG 7.1+ is VERY fast at many simultaneous connections, although I know of no 1000+ simultaneous connection benchmarks in existence. (Do you believe benchmarks, anyway?)

      If you have tried a newer PG (7.2+,) and have followed all recommendations/tuning guides and still have had these problems, I'd really like to know.

      I'm open to PostgreSQL (am using it), Interbase/Firebird, and SAP-DB and want the real scoop on things.

      Will PG break under big loads? If so, how big? Does PG have a 24 by 7 problem?
      • by Anonymous Coward
        We used PostgreSQL up to version 7.1.2.

        I believe the issue with VACUUM has since been solved in that it no longer holds any table locks.

        Regarding scalability, we found that (again, compared to PG 7.1.2) SAP-DB scales better under high load. Of course we tried tuning both as well as we could. We measured transaction throughput and average as well as individual response times while steadily increasing the number of concurrent clients. We did this on a system with plenty of CPU power (quad Xeon). Once we pushed things to over say 150 concurrent connections, SAP-DB showed far less variation in individual response times and better scalability, beyond what PG was able to achieve.

        PostgreSQL is a very fast database and I must admit that I haven't tried 7.2. The only reason being that SAP-DB was better than we expected...

        Jeroen Boomgaardt
  • Maybe it's Pascal? (Score:3, Interesting)

    by Florian Weimer (88405) <fw@deneb.enyo.de> on Monday August 05, 2002 @10:28AM (#4011747) Homepage
    Large parts of SAPDB seem to be written in Pascal, which is processed by a transpiler to generate C code. This makes debugging complicated. In addition, the whole build environment (the transpiler, the project-specific make tool, and so on) have only been released as free software quite recently. This might explain why SAPDB doesn't attract developers from the free software community, but it doesn't explain why it doesn't take the user community by storm.

    I hope to be able to use SAPDB some day, if PostgreSQL ever breaks for us. Currently, there's nothing pushing us away from PostgreSQL and SAPDB lacks quite a few features we like in PostgreSQL (the extensible type system, which allows us to store IP addresses directly, for example). The documentation seems to unclear in quite a few areas, too. In addition, it seems that native (non-ODBC) backends are no longer supported by SAPDB.
  • by Anonymous Coward

    I can't say I've used SAP-DB. However, a quick check of its online documentation reveals that it does NOT do multiversion concurrency control. Oracle does. PostgreSQL does. I believe Interbase/Firebird does. Without it, writing a scalable application is MUCH, MUCH harder because locking keeps getting in the way. Real databases need transactions, but without MVCC, the locking to support them will seriously limit concurrency (and, hence, scalability) in a transactional environment.

    If you don't know what MVCC is, read the early chapters in Tom Kyte's book [bookpool.com] or visit his site [oracle.com]. Or read Oracle documentation [oracle.com] (search the page for "Data Concurrency and Consistency").

  • Many user of Adabas on linux, like our company, turn to SAP. As Sap-DB is a branch of the Adabas DB there is only minor need for adjustments.

    While Software AG / Adabas introduced a Licence model, making the DB five times more expensive, while offering no support and having the most flawed JDBC-Driver you can think of.

    Therefore Adabas users are the first and most likely to switch, maybe other user groups will follow.
  • Well, one thing that would stop me from using it is if there is no active development. Support seems very good but without active development eventually the system will fall behind evolving standards. For example, most enterprise DB's have some support for XML data types built into the kernal, but SAP DB doesn't, at least as far as I could find.

    Hopefully I am wrong about this, anyone out there know otherwise?
    • According to the docs PHP and Perl are supported throught ODBC, not the direct native interfaces for those languages. To make Perl work on this I would need to install the ODBC driver and compile it against the SAP libraries and then install the ODBC to DBI bridge. My company in pretty conservative, I have enough trouble getting them to let me use Perl at all, since the drivers are not supported by Oracle. I could just see my director's face if I had to outline such a procedure to him :)

      I would worry about performance and reliability with so many abstraction levels.

      One would also wonder what the support for things like BLOB columns, parameter bindings and cursors would look like using this system. Again, anyone out there have experience with this and can set me straight would be appreciated.
    • SAP is doing internal development in Berlin with a rather large team. They currently have no CVS server up since they are doing it in perforce and the sys admins are not going to open it up. There are regular snapshots (http://sapdb.2scale.net/moin.cgi/SourceUpdates) and they are looking into CVS support.
  • 'What exactly is hindering a wider acceptance of SAP-DB in Free/Open Software projects?'
    Maybe a lack of stories such as these?
  • Backup and Recovery (Score:4, Informative)

    by zsmooth (12005) on Monday August 05, 2002 @11:13AM (#4012053)
    Does SAP have anything close to Oracle's RMAN? If not, it's not on par with Oracle. It seems like most 'free' databases put backup and recovery on the back-burner and only provide some sort of database dump for backups - which is probably one of the reasons they're not more accepted in high-level professional circles.
  • by Christopher B. Brown (1267) <cbbrowne@gmail.com> on Monday August 05, 2002 @11:27AM (#4012129) Homepage
    There are several problems with where SAP-DB is now that injure its, oh, call it "usability."
    • The name is far newer than the "grand old names" of MySQL and PostgreSQL.

      Marketing is of some importance, and the "other guys" have more of it. There are no books on bookstore shelves on SAP-DB. Few web sites "Powered by SAP-DB."

    • The code base is really frightening to work with.

      It's quite a different world, with very different build tools, code documented in German, and the likes. It is not something that is easy to hack on.

    • The install is daunting.
    • There aren't colloquial packages available ubiquitously for Linux and BSD systems.

      You can get a tarball, you can get some RPMs that work in some places, but it's not nearly as available as MySQL and PostgreSQL.

    • There aren't the pile of third party packages, ready to rpm -i or apt-get install into place.

      Much of the popularity of MySQL stems from there being integrated ISP tools like CPanel that include a DB manager module specifically for MySQL. Similarly, the joint popularity of MySQL and PHP stems from the groups of developers working together closely to ensure that there is good native support for MySQL in PHP.

      In contrast, modules for integrating SAP-DB with Perl, Python, PHP, and the like require some degree of effort in "hacking it into place." It's not as simple as "apt-get install python-sapdb sapdb-dbi php-sapdb".

      And TOra doesn't include SAP-DB support.

    None of these are particularly "technical" matters indicating things that can't work.

    It's not a question of "SAP-DB not being an ACID DBMS" (as some idiot claimed in another thread).

    It's really largely a question of systemms integration, with a certain amount of "needs more marketing."

  • >
    What exactly is hindering a wider acceptance of SAP-DB

    Take a look at data types in SAPdb. While they have, for example, date and time types that Oracle lacks, they are implemented as especialization of totally unrelated character strings. This is an ugly hack.

    Now contrast that with PostgreSQL's data types [postgresql.org]. Elegance speaks for itself.

  • This is one topic I've studied a bit (I did a comparision of the OSS db's a few months back (http://mordikyn.com)

    1. Sap-DB is GPL with one restriction. If you are a current Sap Customer, forget using Sap-DB (GPL edition) the license forbids it (actually it's more complicated than that, but that's what it boils down to)

    2. Horrible install. (a pretty good story about installing SAP that I've pointed out before http://groups.yahoo.com/group/sapdb-general/messag e/909). The install instructions at sap (http://www.sapdb.org/develop/dev_linux.htm) are incorrect (and have been so for a long freakin time).

    3. No Dev enviroment. Same thing that (to a lesser degree) holds people back from some of the other OSS databases. Mysql, PGSQL, Interbase all have some sort of dev enviroment avaliable.
    And no the WebDB/WebSQL interface don't constitute a dev enviroment.

    4. Crappy (but getting much better) doc's.

    5. Lack of third party support. I think the PHP support is now sorta there (I see mentions of it, but I also see mentions of probs with it). Until it becomes as common for app support as Pgsql or MySQL..

    6. Lack of Admin tools. Gimme an admin tool as good as any of the many Mysql Interfaces, or the PGadmin tool or MMC for MSSQL.
  • Has anyone used it? Is it any good?

    It looks a bit unfinished to me, but the modularisation ideas are pretty neat.
  • Installation (Score:2, Interesting)

    by VladDrac (15111)
    I tried sap-db about a week ago. The online rpm's are hopelessly out of sync with the online documentation.

    The python that comes with the binary release doesn't even work correctly it seems.

    After an hour of adjusting paths, fixing shellscripts and figuring out what else to install I gave up - I'll just stick with Postgres.

    Also, the features aren't that impressive. I heard that the "replication manager" is just an dbdump import/export script or something like that (though I hope I'm wrong here)

  • Anything SAP scares the hell out of me. SAP is like this big creeping monster swallowing up companies. Py previous employer decided to kill all legacy apps and switch to SAP. Up front thay make it sound like the most configuable set to integrated tools imaginable. Once the suckers buy into the hype its too late to back out. You spend more and more money tring to implement an unwieldly monster that isn't nearly as configurable as advetised. Up front you will have so much money and personnel commited to the change that there is no way to back out. Next you learn you must conform your business rules to the SAP rules. Last you learn the horrible, horrible truth: SAP OWNS YOUR COMPANY BECAUSE THEY OWN ALL YOUR DATA.
  • The answer to this one is simple:

    1) SAP DB has only been Open Source for what, a year? Heck, I only heard about it 3 months ago. PostgreSQL has been Open Source for over a decade.

    2) SAP DB is a pain to set up. Frankly, I don't have an entire weekend to set up a new RDBMS just to evaluate it. (Unless, of course, I'm being paid to!)

    3) SAP DB, unlike PostgreSQL and like MySQL, has the single-company-development problem. PostgreSQL, as an OS project with 25-50 volunteer developers worldwide has survived the death of, so far, 6 companies that supported Postgres or its derivatives. Like MySQL AG, if SAP AG were to go down the tubes, development on SAP DB would halt (though it would still remain available under the GPL).

    4) Most importantly ... I am a minor player on the PostgreSQL project, and as such feel that I am well informed on PostgreSQL's bugs, limitations, development direction, and tradeoffs. As a recently opened commmercial product, SAP DB is still too "black box" for me to trust it. No doubt this will change.

    -Josh Berkus

    P.S. One volunteer suggested that we consider SAP DB support for OpenOffice.org. Sadly, we had to reject the idea because of the complexity and difficulty of administration for SAP-DB. If someone from SAP is reading this, and you disagree, please join the dev@dba.openoffice.org mailing list and make yourself heard.
  • by kevin lyda (4803) on Monday August 05, 2002 @12:45PM (#4012696) Homepage
    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.
  • by samantha (68231) on Monday August 05, 2002 @02:43PM (#4013522) Homepage
    1) Their site has a bunch of advertising hype for how wonderful the DBMS is but almost zero real content;

    2) It is from and controlled by SAP. I have worked with these people in the past and I deeply distrust their code and processes;

    3) Life is short. I have no time for YADB that has no compelling advantages that I can see;

    4) I believe in the importance of things like replication and objrect-relational features that SAP puts down as irrelevant.
  • Here's why (Score:3, Insightful)

    by chris_sawtell (10326) on Monday August 05, 2002 @05:42PM (#4014688) Journal
    In a few lines this is why I'm not into SAP DB:-
    • 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.

  • by DanielDittmar (447579) on Tuesday August 06, 2002 @06:26AM (#4016958)
    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.

Recursion is the root of computation since it trades description for time.

Working...