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.
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.
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...
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!
... 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.
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.
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
Winzip will open tgz files.
I guess if you cannot figure out how to open the tgz file in Windows, it is probably better that you are not trying to install SAP. Natural selection is a wonderful thing.
For me the reason is because it _IS_ licensed under the GPL.
I'll take PostreSQL any day, thank god for that license.
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?
not to mention the cadre upon cadre of available PL/SQL programmers
When SAP/DB was Addabas it was one of the least popular commercial databases, and it run pretty counter to way everyone else it. To be honest aside for the multitude of SQL's there is Postgres and IBM -DB2, there just isn't need for an oddball database that is harder to program for than anything else.
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
while it's certainly not the reason for all installations, it's likely that a large percentage of those places already had Oracle on site and not SAP-DB. and it takes a lot of effort and several really good reasons for most companies to switch databases. few have a database for this and a different database for that and a yet still different database for something else.
It is...
1. harder to install, with a slightly strange mix of admin tools (combination of old/crufty, and new/experimental)
2. definitely trickier to manage, as you need to learn protocols for setting up, and backing up, databases and their logs, at least. This is true of other RDBMSs of course, but the trend has been toward more self-managing systems.
3. Relies of ODBC as the cli--which is actually fine (eg, compatible with PHP) but still less familiar to Unix/OSS people
4. Still undergoing stabilizing bugfix cycle, seemingly, although I haven't myself ever encountered a problem with it
5. Is, as mentioned, less tolerant of inexpert admins--and more problematic, the error codes are frequently impossible to understand
6. Really is difficult, at present, to hack. In general, the code is VERY challenging to work with (particularly the ugly, custom built build system), although it should be said that the SAP internal developers are steadily improving all aspects of the system, and a time WILL come when external developers can see rewards for their hacking efforts.
Compensating for this is the VERY skilled and responsive SAPDB development team, and a very strong feature set.
Matt
The originator of the thread should learn that technology doesn't change overnight, and certainly not without the kind of marketing budgets behind Java & C#. Change takes time.
As another answer, I'd ask what is the driving point behind SAPDB? MySQL has/had noteriety for being a very simple system; Postgres had noteriety for advanced research into ORDBMS'es as well as coming out of a university lab that produced two very successful commercial DBs in the past. What's the big focus with SAPDB? All I know so far is that it was an in-house thing that worked for SAP. No idea what that's supposed to mean to me. Maybe someone should answer that first.
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
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").
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
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
IWARS.
People, in general, disappoint me. Politicians even more so.
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.
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
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.
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)
I'm a leaf on the wind. Watch how I soar.
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
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.
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.
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.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!
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.
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
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.
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
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.
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
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.
Right, obviously. I mean, who wants to apply for a job as a "SAP programmer"? You aren't going to get the geek girls with that job title!
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.
> 3. Object-relational database features.
You're probably right on the other points, but not only does PostgreSQL have "object-relational database features", Postgres was the *first* object-relational database in the world, IIRC. And thus obviously object-relational *before Oracle* was.
I believe the modern object-relational database was invented by Stonebraker et al (at Berkeley?). Postgres was *their implementation* of an object-relational database. PostgreSQL evolved afterward from Postgres, driven mainly by Stonebraker's former students, I believe.
-- Mike Greaves
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'
Then most consumers don't drink Guinness, which is my beer of choice. I'll bet that I could identify my brand... all I'd have to do is find the one that didn't taste like sugar water with some "natural hops flavoring" added to the mix. If you're going to drink beer, drink BEER. If you're going to smoke, smoke something UNFILTERED. Hey, it's all bad for you so you may as well enjoy it. I feel sorry for guys drinking Miller Lite because real beer might make them fat.
- 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.
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.
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.
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
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
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
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
As of Postgres v6.2, time travel is no longer supported.
...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
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.