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?
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.
I'm definitely gonna check 'em out now.
What is it? Honestly, is it like MySQL? Can I shoot my MySQL db through it easily?
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.
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*
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...
Have a Happy.
Why are most SAP R/3 installations using oracle as a database if SAP-DB is on par with Oracle??
Makes no sense at all. SAP DB is GPL, Oracle costs shitloads, so there must be a good reason why 99% of all R/3 installations use Oracle.
Big boss man: So, what database technology will be using?
Plebian: SAP-DB.
BB Man: What is that, I've never heard of it. Why would we use that ratehr than the industry standard, Oracle?
Plebian: Er, I've heard that you can get a free CD-ROM of it.
BB Man: Free CD-ROM? WOW - our business is saved!!!
There are plenty of databases out there.
it's the lack of Slashdot articles.
See ya!
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.
.sig
As much as everyone maligns M$, nobody ever puts in MS SQL in the conversation. (We're a DB2 shop not M$)
beware of the trolls
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?
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
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.
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.
Because it doesn't support views/inner queries/real big joins ... ? That's more of an embedded db...
There are a few reasons
1. It is relatively unknown
2. Look at the home page for the database - look at the top of the page, see the ad for SAP? I think things like that are a major factor for why no one uses it. From the appearances (IHMO) the sites gives the impression that SAP opened up the database so they could say "we are an open source company" and jump on that bandwagon.
Has anyone else noticed the mysterious blacked out sections on the SAP-DB history page? Creepy.
that SAP DB isn't supported out of the box by Java, Perl, or PHP, etc. but one quick glance shows they support Perl through DBD::ODBC, have an ODBC driver suitable for PHP, and supply a JDBC driver for Java programs.
so now i'm wondering what the catch is. too big? bloated? slow?
well, the minimum requirements on Linux 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.
MORTAR COMBAT!
Simple... never heard of it before or if I did the letters SAP just obfuscated anything that might have come afterwords with another assumption...
That's what a strong trademark gives you: recognition! But it also comes with a price, assumptions...
I recently tried quite a few databases to get a free one with full JDBC and Unicode support. Let's just say that even with first installing Cygwin PostgreSQL was a lot easier to get running on Windows, let alone on Unix. FireBird idem.
I don't see SAPdb overcoming this hurddle on the entry level easily. On the top level, it is probably issues like the (lack of a) reputation.
thanks for the hint, ill give it a try.
... 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.
the Windows download is in TGZ format. how many Windows applications come packaged in TGZ? how many come in ZIP, or even more likely, self-extracting EXE?
you'd think they'd get a clue about this, when they have to warn on their own website: Check whether your browser changes the package extension from tgz to tar during the download. If so, rename the package to tgz before installing it.
MORTAR COMBAT!
This whole topic of SAP-DB sucks a lot,
but only your finding of blacked-out DB name part
is just great enough to awake myself, thanks!
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.
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.
I thought sap was like b2b or something like that, inventent during the .com boom to get peoples attention.
I didnt realise it was more than just talk and there was actual code.
What is SAP and what does it have to do with a database ?
Maybe you should change the name to b2b-sap-db.com
I never heard of it before now.
Screw Micro$oft.
For me, the lack of debian packages (and, indirectly, the fact that it doesn't use "normal" paths and autoconf/automake) is a major reason why I haven't tried it out. For example, look at this message about using sapdb on a debian system.
-- Free speech is only free if your time is worth nothing.
>>inner queries
Last time I looked MySQL did not support inner queries either.
I have no idea what you mean by "real big joins". What limition on Hypersonic's join capability are you trying to describe?
And even though Hypersonic can be used for embedded it is not limited to that. It can run as a standalone server.
I imagine that if your big boss man has never heard of SAP, better start looking for another company. SAP produce ERP software (Enterprise Resource Planning). This kind of software manages just about every aspect of a business, including billing, orders, inventory, salaries, etc etc... In short, almost every company worth anything uses it (I believe the count was something like 97 out of Fortune 100) and installation costs run up to tens of millions of your favourite currency. SAP also happens to be one of the biggest software companies in the world.
You can use their software with another database (usually Oracle or DB2) running on a separate server, which many businesses do, in order to consolidate all their database tasks together. You can also use SAP-DB, SAP's own SQL database with decades of testing behind it. It just happens that SAP AG released it under the GPL about a year or so ago. Don't underestimate it.
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
It's not in Debian.
(You asked, I answered.)
For me the reason is because it _IS_ licensed under the GPL.
I'll take PostreSQL any day, thank god for that license.
I just looked at the most recent docs for hypersonic. It appears it can to inner queries.
Its partly about trust. The most important feature of all databases is their replication and clustering support. Thats it.
Businesses will only trust something that has been around a while and that they no can failover and be brought back online. Thats the reason that Oracle, Sybase, MS SQL, and DB2 are so popular. No one in the business world would think of using Mysql or something like SAP DP unless they were truly desperate.
i run a FreeBSD shop. i check out FreshPorts.org and there is nothing about SAP-DB to be found. there is MySQL and PostgreSQL a-plenty, though.
freshmeat.net has TWO projects listed: SAP Database and SAP DB. both link back to sapdb.org.
MORTAR COMBAT!
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%.
"Draco dormiens nunquam titillandus."
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
http://www.tripuls.de/deut/zg/prod/datenb1.htm
I think that this is what you wanted.
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?
It's "Industry Standard". /. about a MySQl update feature. People didn't give a shit.
I mentioned Firebird the other day when a guy asked
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.
We suffer more in our imagination than in reality. - Seneca
First you say
how many come in ZIP, or even more likely, self-extracting EXE?
Which would imply that you expect the download to be a ZIP file. Then you say
but i know that *i* for one do not have winzip installed
If you don't have WinZIP installed, how were you expecting to unzip the download if it was a ZIP file? Magic?
You don't know what you want; you're complaining about a complete non-issue.
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
is the lack of dbas in these shops. their datamodels are probably pathetic. offering nothing more than kludge.
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
Of course, having Mandrake package it probably took all the fun away, but it was no harder than Windows' ODBC manager to set up, and you get a good deal more control over the process if you want it.
Got time? Spend some of it coding or testing
Does anyone have any benchmarks that compare SAP DB to other DBs?
How easy is it to repair an SAP DB?
Because I've never bleepin' heard of it, that's why.
So, I have this Linux box back from when I was teaching a fair amount of Perl DBI, that runs an Oracle instance, MySQL, PostgreSQL, and Sybase (all at once). Next in line was a DB2 RPM. I never even installed that one.
-joseph
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
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
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.
There are several other good databases around. InterBase looks pretty excellent.
I'd be interested in RainingData (<span face=poker>now there's a truly inspired name change</span>) nee Pick GPLing their MultiValue database. Overall, a pig to use and maintain compared with something like PostgreSQL, but it still does some neat tricks and has a reasonable community around it.
Got time? Spend some of it coding or testing
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 or visit his site. Or read Oracle documentation (search the page for "Data Concurrency and Consistency").
I personally use Firebird, the easiest and most stable RDBMS I've ever used.
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
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.
Got time? Spend some of it coding or testing
leonbrooks,
do you have any link to "postgresql doing replication"?
The only stuff I know about is some beta software.
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.
Got time? Spend some of it coding or testing
pg doesnt do replication, it's bs
check the TODO, the replication function is on the first line, I think.
subscribe to the [pg-replication] ML, and you'll see it's in a near-alpha state...
IWARS.
People, in general, disappoint me. Politicians even more so.
It can be actually set up to run as non root with an own user.
I believe the SAPDB RPMs shipped with SuSE distribution
do this for example.
You must be smoking crack. MS SQL was the biggest pain in my ass ever. Apparrently your apps have no need of being reliable. Actually, I can't really think of many apps that were easier to set up than MySQL. SHit, it was harder to set up apache the first time than it was to set up MySQL.
SuSE ships it with its distribution, so you can easily
install it.
The build process is highly non trivial and probably
would need significant work to work with BSD ports.
Until recently it also depended on binary only build software
(I think that is fixed now) and included one binary only object file containing the password algorithm (may be fixed now too or could be at least easily replaced if you wanted)
I'm switching to Oracle for the simple fact it can do everything I need and more. Great Drivers, great database, great expense. Sometimes you do get what you pay for (unless your California).
The sap db has JDBC 2.0 drivers. Which is better than the 1.0 drivers for MySQL.
Currently, it is certainly true that there is little support, community or sample solutions around.
I guess the larger complexity of SAPDB will not make it as popular as mysql, and probably there are simply more uses for a small database than for a database that scales well.
One driving force for applications that I could foresee is people interfacing with SAPDB based SAP installations. However, the question is whether these efforts are more commercial (closed-shop) or open, dependend on this we may see many sample solutions or not.
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.
For starters, one big issue that's stopping me from using SAP is that it doesn't run on IRIX! All my database servers are SGIs, how could I possibly hope to leverage all this powerful hardware I have when the software won't run on it?!?
PostgreSQL or BUST, that's my story and I'm sticking to it!!!
Bzzt.. wrong!
I work for a Fortune 100 corporation and we use a server room full of Oracle boxes. We dont use Oracle merely because our CIO likes it (we've had more than a few, BTW).
We use Oracle for one reason: support
When our Financials or Manufacturing group calls us screaming about why something is not working, we try to fix it, then we call Oracle and scream at them - then they fix it, period.
Open source, easy to install, CIO likes it - all BS reasons. We need to keep our books in order and our product going out the door no matter what - thats why we use Oracle.
Moderators need an additional choice: "Karma Whore" for people who cut-and-paste articles as their comments!
It always seems great when the userbase is small. Hardly any bugs, great support. Give them a userbase the size of MySQL and see how it looks.
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."
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.
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.
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."
If you're not part of the solution, you're part of the precipitate.
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. Elegance speaks for itself.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I will answer this as a MySql user. I evaluated both MySql and PostGRESql for myself. I might have also added SAP DB to my list if I had ever heard of it. I had heard of SAP but not SAP DB and I would never have guessed to look to SAP for a free product. I will be looking at it now however.
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)
g 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).
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/messa
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.
Bugs Bunny was right.
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
I tried to set up SAPDB recently, following the installation instructions to the letter. I never got it to work. I never got any peer support either on the mailing list (and I'm not the only one). Deinstalling has been even less successful than the installation was.
So at the very least, they've not made it easy to kick the tires with SAPDB.
And I agree with the other poster - the db that I keep expecting to make bigger waves is Firebird?Interbase.
I tried installing a binary of it on Solaris 2.8 and it bombed severely. It just won't run. Then I read their web page and it turns out that "they have only tested it on Solaris 2.7". I should have read their web page more carefully to begin with. I realize that Solaris is not a free OS, but please, if you release a DB that you claim is "enterprise ready" it needs to work on all *nix platforms.
After this incident my opinion of SAP-DB went straight downhill. Good *nix DB should be portable and if it's not portable then it's not good.
Has anyone used it? Is it any good?
It looks a bit unfinished to me, but the modularisation ideas are pretty neat.
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)
And MS-SQL usually returns the same result set for a given query. True, it sometimes leaves out a few rows, but cut it some slack - we all make mistakes.
I'm a leaf on the wind. Watch how I soar.
Being an AC, I have serious doubts about what you are trying to say.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
ya dumb SAP.......
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.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
The Stonecutters!
Rats cry when i tell them about my day - Dilbert
Bzzt! wrong again... clients don't use oracle for their support (that's what trained dba's are for), or their db. They use them for their apps.
Oracle isn't about db's, only partially about support (to sell you more apps), and most definitely 95% about their application solutions.
Oracle could switch over to postgres is they wished and except for PR issues, it wouldn't significally change their ability to supply solutions to companies that need them.
It's just that for 99.9% of companies out there the apps are just way overkill... must people can get by with postgres or mysql with custom written stuff or downloaded stuff and do just fine. Of course give the open source community a few more years and there will be off the shelf apps that will rivel those of Oracle, I'd be willing to bet.
Toddlers are the stormtroopers of the Lord of Entropy.
The answer to this one is simple:
... 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.
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
-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.
Re-read the name:
myyyyy SQL
It makes me feel in touch with my SQL syntax when scripting. It's my code. It's my database...
Just a love thing...
This sig can be distributed under the LGPL license
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.
One big problem with the SAP DB is that it is a flat database, not relational. Another problem it is bloated(100Meg) compared to MySQL(10Meg).
In my experience
- pulling transaction records from a remote database results in a considerably superior solution to that obtainable with any messaging middleware product
- using duplicated "hot-standby" systems is more manageable and efficient than data replication.
So please don't dismiss PostgreSQL and SAP DB on the basis of checkboxes for features you might not want to use.-- Ed Carp, N7EKG erc@pobox.com PGP KeyID: 0x0BD32C9B What I'm up to: http://intuitives.mine.nu
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!
I think MS SQL Server and MySQL are the two db which grow the fastest in the market.
MS SQL Server 2000 is now considered to be stable. It provides far more API/Tools/Utilities for developer and administrator than any other db.
Open source db need to have faster progress in order to keep up the paces. no kidding. I see many many new systems on MS SQL Server recently.
Why are people prefer MySQL/MS SQL over PostgreSQL/SAP-DB? I think it is mostly because of the ease of installation and the quality and number of administration tools.
I don't know about you, but I would so hire an electrician that only had a pair of dykes and a roll of electrical tape!
Use your imagination!
I don't think a state can become an -ism, can it? Become a Totalitarian State, sure... or maybe Authoritarian... well, if you want to be dramatic 'become a Tyranny' might be more catchy.
NOT supported features: Collations Hot stand by Failover is a good thing...
Yes, I am an agent of Satan, but my duties are largely ceremonial.
That's not a word! You should have said "derstandable"! ;-)
T
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
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
I see that the latest version of HSQL does indeed support inner queries. My initial point, however is still up for debate. HSQL is not comparable to Postgres/Oracle/SAP DB for a variety of reasons.
.script files (I've begged for this, but have given up on ever seeing any type of encryption implemented). Other things HSQL needs: Row level locking (with regard to SELECT ... FOR UPDATE queries), left outer joins, serialization isolation level, CHECK constraint support, fixing of the general ADD COLUMN weirdness...
From the forums I see:
Since the HSQL code uses integer values to perform its seeks into the data file, theoretically you should be able to store a gig or more of data. In practice, however, it seems that all the data you load remains in memory, even when using cached tables.
Which speaks to my 'real big joins' argument. I can't be more specific, because I never bothered to find out why it didn't work, I just moved on to postgres, which did. It appears that the problem lies with the team's usage of ints to represent positional data with regard to the table data. This puts a hard limit of 2GB on the data size (for some, 2GB isn't enough I guess).
Backup support would also be nice (dump/copy/replication/etc). So would trigger support. It would also be nice if user passwords and structural information were NOT exposed by the cleartext
HSQL is great for a specific set of requirements, but it does not meet the same broad set that postgres and oracle do. This is why I don't feel that it is in the same league.
go to freshmeat.net. Search for SAP-DB: 3 project found. Search for mysql: 935 projects found.
Why reinvent a wheel that rolls just fine? Whatever the SAPdb-vs-PG-vs.-mysql arguments may or may not be, the bottom line is that most of us would have to dramatically recode, reconfigure, or recreate our lovely stable environments, with little if any actual return for the time. Face it, Open Source software is a market. There is no market demand for this.
Help, I'm being repressed!
Clients definitely use Oracle for their support, and not their applications. In all the companies I've worked for, including this one, a Fortune 100 company, Oracle is used primarily for the support. A good DBA is great, but a good DBA wouldn't necessarily help if there was a bug in the database software.
Sure open-source software might enable the developers to go in and fix the problem, but who has time to fix something like that? Everybody is usually busy enough just trying to get their project done.
Rob
NEOS
The best thing about Firebird/Interbase is that's its easy to wean an app away from MS Acciess. Here's as typical progresstion:
Access Front/Access(Jet) Backend
Access Front/Firebird with ODBC Backend
Delphi or CBuilder Front/Firebird Backend
Delphi or CBuilder Front/PostgreSQL Backend
Kylix Front/PostgreSQL Backend
App Server Running Kylix and VNC Front/PostgreSQL
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
The main reason I never used it is that I didn't know about it. That is until now of course.
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 evaluated several databases over the weekend for a project I'm working on. I needed the DB to run on linux, I needed to access it via JDBC, and it needs to support arbitrarily large BLOBs. I tried MySQL, Postgres, MS SQL, DB2 and SAPDB.
I'm sure it was just something I was doing wrong, but I was getting data corruption with MySQL on anything larger than 500k. Postgres' JDBC drivers don't stream things, they have to load the entire byte stream into memory -- so it failed utterly. It also used about 10x the memory it needed to load the file, and didn't release it even after garbage collection -- so poo on it.
I tried MS SQL, and it worked flawlessly, but like I said, I need the database to run on Linux.
I installed SAPDB on a Red Hat box, spent a few hours figuring out the management commands, and was successfully loading/retrieving binaries of up to 100MB with no problem. Very fast throughput, all things considered, and the commands aren't too difficult once you figure out what they're supposed to freaking BE. I guess it helps to have a working understanding of Oracle 7 administration, because the concepts are pretty much the same, just with different names.
So, even though I'm kind of sad that the codebase is poorly set up and it won't run on *BSD or MacOS X, I'll be using SAPDB for this project because it meets my needs quite handily.
I think that if a community could be arranged around SAPDB to clean up/standardize its codebase, it would be a Good Thing and I would like to get involved. But it's going to take somebody going through that spaghetti and figuring out what's what.
"There is no night so forlorn, no mood so bleak, that it cannot be infused with pleasure by tender meat..." - R.W. Apple
To quite honest, everything I have ever heard about SAP made me think that it was HUGELY expensive and only used by Huge Companies (HC's). I absolutely never knew its dB is free. 'Course, so is Oracle's. I doubt either company is planning out of business soon.
Even if it was good, if I am starting out on using a new kind of tool (like a DB, which a couple years ago would have been new to me) the first place I look is the /usr/ports directory in my OS. If it's not in there, well, it's probably not ready for prime time, and I take a pass. This technique may miss some nuggets from time to time, but it's worked well for me so far. In the case of SAP-DB, there is no sign of it in /usr/ports, nor is there any sign of a perl DBI module for it, so I'll just stick with MySQL and Postgresql.
There must be lots of other under-appreciated databases. I think we need a product-comparison site, similar to Linux Hosting Comparison, for more software categories.
/g
I would definitely be insterested in comparison of object and XML databases...
Sigh, I'll rephrase. For what would you be buying support, hmmm? It wouldn't be the db, because by itself it doesn't do anything. You'd be buying support for what? Let's hear it again class. Repeat after me.
"It's the apps stupid."
Support is just a necessary evil and keeps the vampires fangs well connected to fresh blood. So let's review shall we?
You don't go to oracle and say I'd like to buy support. They'd probably sell it to you, but then you'd probably the state of California. Noooo! You need to have a need for which they have a solution, an ERP for example with a bunch of addon modules. Now to get that you need two things:
a db
support
Right? But the reason you went to Oracle in the first place is because they had an app that you needed.
The db and support are just two things that make the app more attractive but they are definitely NOT why you bought from Oracle.
A crappy ERP, with a kick ass db and wiz-bang support isn't gonna cut it now is it?
Toddlers are the stormtroopers of the Lord of Entropy.
You left out that the prisoners are slaves, working at about $.20 per hour (assuming that the pay has increased since I last checked).
Ever wonder why there were so many people in the US prisons? They weren't all people that you would have despised as neighbors. Or relatives.
I think we've pushed this "anyone can grow up to be president" thing too far.
What with all the hubbub and hype about the other OSS databases, I'd never heard of SAP before today.
Sounds like a decent product...
The price we pay for immortality... is death. Narnia The Great Fall
Although PostgreSQL is vastly superior to MySQL, it is still nowhere near being on par with Oracle. Oracle has an incredible number of features that are lacking in PostgreSQL. A few of them are:
1. Hot Backups. This does NOT just mean a "consistent snapshot" as postgres provides; it implies a backup manager that can successively apply transactions from a redo log.
2. Asynchronous replication, parallel server, and hot standbys. You claim that postgres does replication however a search for 'replication' on the PostgreSQL mirrors yields no information.
3. Object-relational database features.
4. Extremely adequate documentation spanning ~30 non-overlapping books.
5. Materialized views, transaction savepoints, warehouse queries (cube, rollup), stored procedures in java...
These are just the heavily-used enterprise features; if I listed all the obscure features of Oracle, this post would be very long.
> 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.
Oracle Standard Edition is $300 per user. Most corporations would not want to "downgrade" to save $300, since their database is usually a rather criticial part of their operation.
For a webiste, however, you would have to buy an unlimited license ($15,000). For a small website, postgres is clearly a superior choice.
Granted, I may have missed something, but if it's too difficult to find after scanning through a few search results and what appear to be relevant links from the home page, I generally go somewhere else. That kind of (missing) organization does not speak well of the product in question.
I had an argument...with the person here at the university that teaches OS design. I wonder when I'll learn --Linus
I'd say "Bzzt" but its overused at this point, eh? :-)
Sorry, but DBA's do not know how to fix the weird problems that occur in the concurrent request manager or why some workflows do not go through - Oracle encrypts their PL/SQL packages so that they cannot be modified or even viewed, and without Oracle support your Oracle Apps and DB are useless. Ask a DBA sometime.
Also, this post was regarding the database not apps - thats another ball of wax.
And since i seem to have garnered some mediocre responses (not yours), perhaps i should add to my previous post:
Why doesnt the world enbrace SAP? was the question. To which i say, "Because its impossible to singlehandedly support databases you have 10 years of training on, muchless databases that you cannot even understand due to lack of comments, documentation, substantial user community, and language (quite a few DB tables have German names as do their columns)."
Why does Oracle ownzor SAP? Because unless you're running something simple, like my PHP-MYSQL solution at home, you *NEED* professional support - Oracle has this.
Thats all i'm saying.
Just my opinion, i could be wrong.
Moderators need an additional choice: "Karma Whore" for people who cut-and-paste articles as their comments!
If there was a DBD for the Ruby DBI driver, I'd give it a go. I haven't seen a lot of comparisons between it and PostgreSQL in terms of performance or reliability.
PostgreSQL is really pretty good for the price, though, and it has been mostly dependable, quick enough, and easy to administer. They have been improving it by leaps and bounds, not tiny increments, and most of the time that is nice.
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.
please explain the phrase "highly non trivial". why not just say "difficult". or "very difficult". or "freakin' difficult". or "not easy". "highly non trivial"?!?! sheesh.
Incidentally, SAP-DB is not part of any of the major distributions as far as I can tell. If you want to popularize it, the first thing to do might be to volunteer to support it for Debian.
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
"""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"""
Not so for Python; the kinterbasdb project was revitalized in January, and is now quite stable:
http://kinterbasdb.sourceforge.net/
Erlang.org: wow
The full test goes like this:
People are asked at a bar if they prefer Ale or Beer. They are then given unmarked samples of each, and asked to determine which they like best. 75% of the people fail to identify their preferred drink.
The remaining 25% are then asked to name their favourite brand. They are then given a sample of all the brands. Of these people, 75% fail to identify their brand correctly.
It is for this reason that beer makers worldwide have found that consumers buy their beer based on image, not taste (since most of them can't tell the difference anyways).
While it is true that popular, common-denominator beers may be the exact same product, do not take it to heart, for you probably wouldn't know the difference anyways.
I worked for a while at a Global 1000 company, which was in the process of rolling out SAP for North America. Once that was completed, their plan was to roll it out worldwide.
When I arrived at the company the project was years late and about $600 million over budget. They completed North America and cancelled the global rollout. I heard at the time (1998/99 sometime) that SAP stock dropped significantly the next day.
Using any ERP will no doubt require a) figuring out how your business really works; b) changing how it works substantially. For a large business this is very painful.
I'm looking at Compiere as a possible addition to my consulting business for small/medium business. However so far it only supports Oracle, and I haven't managed to D/L the Oracle install - my satellite connection chokes on it.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
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.
This gets to the heart of DB backups. What good are they? If your business is running 24/7 and you back up once a day, you could lose a day's work/(sales/etc.)! If that's OK, then why not let the OS do a backup of your mirrored server (you do run mirrored servers, right?) -- oh, but then isn't your mirrored server your backup? See my point? I don't get DB backups; either they're easy as pie because you do constant backups, or they're worthless.
If all this should have a reason, we would be the last to know.
Excellent comment... a keeper!
www.firebirdsql.org
Okay, I confess, I'm the one who used SAP DB! :-) I was designing a university project when I happened to stumble across SAP-DB while testing out MySQL and waiting for my Oracle 9i demo disks to arrive. I have to say that I was impressed from the start - the Win32 graphical tools that came with SAP-DB were excellent, setup was so simple using them. ODBC connectivity was a synch and getting it to talk to Perl through the DBI was painless.
:P
It has a lot of competitors, but I quite enjoyed using SAP. It really came down to the great tools that were supplied with it and the fantastic PDF documentation which covered everything in great detail, oh and all the compatibility modes which made it easier for my Oracle-trained SQL hands..
OK. I haven't bothered to check kinterbasedb out (which was sort of my point) because it sounded like a KDE only package, and I need something that works for both Linux and Windows.
... any of the other packages which have more easily accessible experts and documentation. There may well be such reasons, but I still haven't seen them.
The thread, as I understood it, was about "Why is marvelous package X not being adopted?", so I tried to answer that, from my current knowledge. (Then I looked at the readily accessible current documentation and added a footnote... which did acknowledge the kinterbasedb project, and also a project for Ruby.) Your point may be a valid one if we were discussing why one should choose Python over Ruby for a database project using Interbase, but it doesn't address the question of why I should choose Interbase/Firebird rather than PostgreSql, or BerkeleyDB, or MySQL, or
I think we've pushed this "anyone can grow up to be president" thing too far.
That's why I make a distinction between 'Criminal Prisoners' and plain ol' 'Prisoners.' You and I probably disagree on what a true crime is, but we both can agree that there are a lot of people in prison who don't belong there. Most pot-heads and prostitues don't need to be in prison for example.
What bugs me is that is costs -$40,000 a year in taxpayer money to house a pedophile. We should be working that pehophile so hard that their work causes a net contribution into the tax coffers. If they refuse to work, then they should starve. Just like the rest of us.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
... don't I have any mod points left?
:)
thanks for the laugh!
The Open Source Development Lab is using SAP DB to create some Open Source database performance tests. As part of the effort, we have created some installation scripts and a test suite that you can download and run. So, if you are interested in SAP performance, or improving SAP, come check us out!d ldbt.h tml
http://www.osdl.org/projects/performance/os
The project code is on Sourceforge at:
http://sourceforge.net/projects/osdldbt
A one-tier version of the test load is also running on the OSDL's Scalable Test Platform.
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'
Since it's a quiet week here at Apple, I took half the day to evaluate the porting effort likely to be required to make SAP DB run on MacOS X.
The first, and worst, issue is that the code is not designed for portability. As with most "mature" source bases, it's scattered with #ifdef SYSTEMNAME fragments, meaning that you have to either pick a system "like" yours, or evaluate each and every one to see whether it applies to you as well.
The ROI on porting or maintaining this codebase would be small, especially given the enormous effort that would be required to bring it up on a new platform in the first place.
- 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.
SAP licensed Adabas D and evolved it into the current SAP DB. Adabas D has itself evolved and is still sold by SoftwareAG. The situation is like that of SQL Server, which was licensed by Sybase to Microsoft and has evolved under both brands since the fork.
You seem to be doing fine with PostGres.
However, if you want to use JDBC, Interbase/Firebird seems to be a better choise than PostGreSQL because JDBC access to PostGres seems to be badly made.
I tried to install SAPDB on my windows box a couple weeks ago and it was just... well... really hard. I never could find any decent documentation (pdf's are never decent IMHO), and I gave up after finding no installer or anything that seemed to resemble a registry merge file or anything stating what the default dba password is. I gave up for lack of incentive. I don't actually need it; see below.
:-)
I think the problem is that there are other well-known DBMS's out there that are just as cheap (free), open source, and have the needed features, and are also easier to install and better documented. For me it's Postgres on Linux. It does what I need and it's really easy to install and admin and quite well documented. For others it's MySQL for the same reasons I'm sure. Then there's T-bird, I'm sure somebody must be using it
From a development standpoint, I hear the source is a freakin mess. Maybe it's just me but that seems like the status quo for closed software. I remember Mozilla being a big stinky mess when it first popped out of Netscape too. Maybe that's part of the reason they open sourced it; couldn't afford enough programmers to maintain the spaghetti code anymore. And let's not forget how long it took to clean Mozilla up and make it viable again. Hopefully SAP won't be quite as bad.
If they can get a few developers to latch onto it and get the code cleaned up a bit, and get some better documentation, and some better install mechanisms, then I'm sure it could have a chance.
Problem is, at $.20 an hour working 24 hours a day wouldn't pay for room and board. It's not unreasonable to require that prisoners work, it is unreasonable to pay them so little. (Of course, I have no idea how much the prison system gets paid to loan out their slaves...but it wouldn't matter.)
Prisoners aren't in a free market labor situation, so they have bargaining power. This guarantees an unfair situation, unless great care is taken to ensure otherwise (as clearly is not the case).
I feel that prisoners should be paid the prevailing wage for equivaltent work in the surrounding communities. And that after they have earned their wages, an amount up to, say, 80% might be deducted to cover the expenses for food and shelter. Then another 10% could be deducted for restitution (which would decrease their debt remaining at the end of their sentence). And the remainder would be left so that they would have some incentive besides being slapped around by the guards to do the work. And, to repeat myself, that they should never be paid less than the prevailing wage for equivalent work in the community where they were apprehended. And that there should be independant ombundsmen, partially paid for by local labor unions, to ensure this.
I think we've pushed this "anyone can grow up to be president" thing too far.
When i tried to install SAP-DB (over a year ago, when it was first released), i got it installed, i think i had it running, but damnned if i could figure out how the hell to create a database on the thing.
So i threw it in the 'too-hard' basket, and went back to Postgres which i am quite happy with. I actually think it is still running on one of my boxes.
I'm sure progress has been made since then, but what would help out the most is a simple 'HOWTO' with instructions for setting up a database, from installation to database and table creation - to administration using CLI and GUI tools - to example setup with Perl/PHP/Java for access, as well as a set of guidelines for backing up, restoring and tuning the DB.
I think its great that SAP has made this step, and I think that SAP-DB looks great on paper, but, IMHO, deploying this database is a major struggle compared with MySQL or Postgres.
I gots ta ding a ding dang my dang a long ling long
PostgreSQL will run in that smallest box and be faster, safer and easier to program. There's really no place left for MySQL other than nostalgia.
Why does Oracle ownzor SAP? Because unless you're running something simple, like my PHP-MYSQL solution at home, you *NEED* professional support - Oracle has this.
So does SAP. But if you want "professionial" support with guarenteed repsonse times etc, you have to pay for it. Same with most other free "enterprise" application.
http://techdocs.postgresql.org/techdocs/settingupr serv.php
Got time? Spend some of it coding or testing
The DB can work with the OS in the same way as it does raw partitions: this gives it reasonable abstraction but retains the performance boost of knowing stuff about the DB contents. With the DB knowing how best to treat stuff in the DB and the OS knowing how best to get stuff to and from a drive, the potential for performance gains is greater than just that of the DB knowing what the info is doing.
There are other examples to consider as well, for example, Windows apps often run twice as fast on the same machine under Win4Lin as they do natively, because Linux task switching, memory management and (yes) cacheing is streets ahead of Windows 9X. In this case, knowing how to deal with the hardware well is more important than knowing about internal structures.
Got time? Spend some of it coding or testing
To grandparent: true, my blue.
GPL means that you can allow others into your party. Putting improved MIT/BSD software out only happens if the developer is charity-minded themselves; GPL makes charity-minded behaviour mandatory. This means that you can release something with the expectation of seeing more of the improvements made by others coming home to roost, and knowing that no competitor can out-develop you.
Got time? Spend some of it coding or testing
What can I say? `Me, too?' Thanks for correcting my licencing blue.
Got time? Spend some of it coding or testing
Like, `mortgage your house so you can buy a better model of our car?' Not single-mindedly ambitious at all, are they? (-:
Talk about help from unexpected quarters!
Got time? Spend some of it coding or testing
AFAICT, PostgreSQL is still capable of doing the time warp, meaning that you can rewind a live table back to just before the DROP and recover the DROPped information.
Got time? Spend some of it coding or testing
Ask the OS how big the tapes are; in case of uncertainty, waste the last few meters of tape.
Got time? Spend some of it coding or testing
Had 'em from the start, just like the previous post stated.
Quite a few `idoits' are getting bitten after installing one of MS's development suites and getting a free cut-down version of MS-SQL-Server with (surprise) a blank admin password. Until recently, the docco for the `real' version of MS-SQL only got around to mentioning the blank password thing waaaaay down the tree.
I think their first mistake was using MS-SQL instead of PostgreSQL, but that's just zealotry, so you can discount it accordingly. (-:
Post with a handle next time, will you? It gives you more credibility, and me a name to laugh at. (O-;)
Got time? Spend some of it coding or testing
It's called RServ, and it works. Link elsewhere in this thread.
Got time? Spend some of it coding or testing
- The web-based administration tools didn't install as documented. And the documentation wasn't easy; it required editing the Windows registry! The traditional GUI tools worked okay.
- When I tried to dump a bunch of data into a test database, it didn't all get there. Turns out the database ran out of room in its "data devspace." I never worked with a database before that needed space pre-allocated for the data, and this requirement might be a problem for my clients without on-site DBAs.
- The ODBC driver had a quirk that truncated floating-point values to integers when I dumped the values from a legacy database (Paradox) into SAP DB. The dump went fine if I defined the SAP DB table structure in advance, but the automatic ODBC type conversion didn't work.
- Support is very responsive and competent, but it's only available through a mailing list, not a newsgroup, so it's harder to follow and participate in threads.
- The documentation is thorough, but the online version doesn't have an index. SAP says you can use Google to search it.
It seems like a solid, well-built product, and I think it would work well if i got to know it better, but I'll probably wait until the developers iron out some of the kinks.If you run any services without reading the documentation, well, I can do no better than to quote you:
Got time? Spend some of it coding or testing
http://web.archive.org/web/20011130142504/http://w ww.sapdb.org/history.htm
Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
...and I wonder just how unsupported it is.
Got time? Spend some of it coding or testing
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.
And Oracle is addressing the lowest common OS denominator.
Got time? Spend some of it coding or testing
...after everyone's been bitten. And even then, not the version that's included in several IDEs.
Got time? Spend some of it coding or testing
If you are only writing a diddly app then maybe it isn't. But if you are planning (hoping) for your userbase to grow it seems important to pick a solution that is scalable. There are benchmarks at sapdb.org that show tps on a quad system. They are impressive.
Seems shortsited to create a bunch of code using one db, only to have to rewrite it in another if your plan is successful.
Sounds reasonable! Too bad you're not running for office - all the reasonable people stay out of politics, it the insane ones that think it's fun. ;)
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
Internet Explorer is free with your purchase of $159.95 or more.
and only luser use MS.
There are 5 replication products listed for PostgreSQL in dmoz. At least one, pgreplicator seems mature. Has anyone used it?