Now, here's the first unbiased response I've seen for SAP-DB vs. PostgreSQL.
It makes me want to consider SAP-DB, since you've benchmarked it against 150+ users. I saw a MySQL vs. PostgreSQL vs Oracle (8i or 9i, I can't remember) benchmark on the same uniprocessor equipment. It showed PostgreSQL killing MySQL and Oracle from 5 to 100 users. 0-5 had MySQL shining, while 5-100 had PostgreSQL shining. They showed nothing past 100 simultaneous.
However, I could find little beyond what you just told me. For example, what effect do SMP, memory, RAID, SCSI vs. other technologies, tuning, number of users past 100/500/1000/5000, different query complexities, and the like,have on performance for all three of these db's? What about including other DB's, such as SAP-DB, Interbase/Firebird, DB/2, Informix, and Sybase (all available for Linux, multiple Unices, and Windows?)
I certainly don't want to base my thoughts on one user's experience, but to see that in the real world, SAP-DB does indeed scale better, does picque my interest.
I do have a few questions, for anybody out there, though:
What kind of hardware?
What OS?
What were the results at different numbers of users?
I'd love to see somebody, anybody, have a free standardized benchmarking web site out there, that is unbiased and that checks multiple configs. It would be nice to do have it done "in the lab," as well as have end users use the lab's testing tools/configs and be able to submit their benchmarks, complete with memory, CPU, disk, configs, other system info, etc., as a comparison.
It could even be a site that lets users help other users to tune their OS, apps, drivers, and db's.
Did Oracle get this in 9i? I don't remember any mention of MVCC for Oracle. They use redo logs, instead of MVCC, still, don't they? I hope I'm wrong, but I don't remember Oracle having this feature.
Oracle 7.x and 8.0 certainly don't -- I've checked this out repeatedly. I haven't checked into this for 8i and 9i, though.
MVCC *is* the stuff, and I agree, It's great for scalability. I preach MVCC. PG uses it, and so does Firebird/Interbase, I think. I'm not really 100% sure about SAP-DB.
Can you show me a web site about this? (Please do not point to a Slashdot article, unless it's a headline that can be substantiated. You can't trust Slashdot reader responses, including mine.)
I'm trying to not argue, but understand the two reasons you listed.
I'm not against PostgreSQL, Interbase/Firebird, or SAP-DB, I'm just wanting to know why. (I am against MySQL in a medium to large production environment, but we'll wait until 4.1+ materializes.)
First point, "VACUUM" problem. What's wrong with a cron job to do this, nightly? Does it bog the system down too much? Is it unreliable? (I haven't noticed any problems, but my DB is small, right now.) Read about MVCC (I think it's something like multiple version concurrency....) Versioning is better than redo logs, in theory. You need to understand MVCC to understand VACUUM. You can VACUUM live, without killing the DB, and perform hot backups as well, due to MVCC.
Second point, have you tuned it, and are you using PG 7.2+? If you are using older PostgreSQL's (prior to 7.1,) then yes, this is a problem. If you haven't tuned it, there are great docs about tuning. Supposedly, PG 7.1+ is VERY fast at many simultaneous connections, although I know of no 1000+ simultaneous connection benchmarks in existence. (Do you believe benchmarks, anyway?)
If you have tried a newer PG (7.2+,) and have followed all recommendations/tuning guides and still have had these problems, I'd really like to know.
I'm open to PostgreSQL (am using it), Interbase/Firebird, and SAP-DB and want the real scoop on things.
Will PG break under big loads? If so, how big? Does PG have a 24 by 7 problem?
He's right. Just go to http://www.arrl.org/ or http://www.fcc.gov/ for more information about propagation, which is *complex.*
ARRL has plenty of information about Amateur Radio and short wave radio, in particular. Look up information about shortwave, propagation, "skip," and "DX".
During the *day* HF/short wave also propagates differently than at *night,* since the ionosphere changes shape, due to the sun: UV, solar wind, solar flares, etc.
You'll notice on HF, AM, and CB that you can bring in many stations at night that you could not during the day -- for some frequencies, but not others.
I'd be willing to bet that you are either on the other side of a mountain (or mountains) from WWV, or their antenna array is not pointed your way (up, maybe?)
That reminds me, I need to update my Tech, No Code Amateur Radio licence....
What gives? Does Slashdot want to give credit to timothy, instead of a lowly grunt, like me? I posted this yesterday (same info, same links, different -- shorter -- text, but mine was rejected).
There have been several like this, including the Simputer article I posted 2 weeks earlier than Slashdot's actual post. It, too was rejected.
I guess you had a REALLY short eval of PostgreSQL, or were using an old copy, since both observations concerning PostgreSQL are false, again, unless you're using something older than 7.1.2 or haven't tuned it according to Bruce Momjian's guide.
As of 7.1.x, backups are hot: http://www.postgresql.org/idocs/index.php?backup.h tml
Hot backups have been made possible, partly due to PG's versioning system.
As for load, once again, read some of the tuning guides, such as http://www.postgresql.org/idocs/index.php?performa nce-tips.html or http://www.postgresql.org/idocs/index.php?geqo.htm l or http://www.ca.postgresql.org/docs/momjian/hw_perfo rmance/ or http://www.argudo.org/postgresql/soft-tuning.html or many others. Any DBA work their salt is going to tune the system. Out of the box, PG is designed for small systems, so as to not kill the box.
Many different kinds of benchmarks (believe them if you want to) actually show that PG outperforms MySQL (which really bogs down under load) and Oracle 8i (up to 100 simultaneous web connections). However, tuning Oracle and PG and changing platforms, etc., is going to affect performance drastically.
(Why is Slashdot chopping up my URL's? Good thing I previewed, first....)
Re:From using MySQL/PostgreSQL and researching SAP
on
PostgreSQL vs. SAP?
·
· Score: 1
You're right. Duh.
Re:From using MySQL/PostgreSQL and researching SAP
on
PostgreSQL vs. SAP?
·
· Score: 2, Informative
I also failed to have you look at Firebird/Interbase -- I wasn't thinking. Firebird might be a PostgreSQL killer. I have actually seen a web host, or two, with Interbase/Firebird support.
Almost all of the PostgreSQL/SAPDB advantages are available to Firebird/Interbase.
My list:
PostgreSQL (for now)
SAPDB or Firebird (future growth)
MySQL 4.1+ (maybe, maybe not)
I have done less research about Firebird than SAPDB. All 4 give a great deal of choice. Firebird is based off of Interbase and has a userr community probably larger than SAPDB. SAPDB still kills Firebird/Interbase and PostgreSQL in terms of enterprise features.
Re:From using MySQL/PostgreSQL and researching SAP
on
PostgreSQL vs. SAP?
·
· Score: 1
Ok, I have a few spelling, grammar, and punctuation mistakes. I was in a hurry, so subtract that from your flame bait, please.
From using MySQL/PostgreSQL and researching SAP...
on
PostgreSQL vs. SAP?
·
· Score: 5, Informative
I'm sorry that most of the responses haven't answered your question. I'll try to partially answer it, but I bet you already know all of this. I really like PostgreSQL and use it. If I were wanting to get a really big web site together, I'd try SAPDB, or just go with either DB/2 or Oracle.
My info about SAPDB is research-based, as I did a lot of that. Please feel free to correct me, if I'm wrong, in any way. MySQL has steadily improved, so a couple of items, below may be out of date.
I see that SAPDB is really an Oracle killer. It is a true enterprise-ready DB. If you want all the features of a big DB, such as replication, partitioning, etc., use SAPDB. You can get true commercial support, etc. Read their PDF's and be impressed.
However, you might want to know why I chose PostgreSQL over MySQL and SAPDB:
1.) PostgreSQL is really ACID compliant, as is SAPDB. MySQL, on the other hand hasn't yet proved itself in this area. Give MySQL a few more months, though, and we'll see, with version 4.1.
2.) Hosting companies support MySQL really well, and PostgreSQL only partially well. I have yet to see SAPDB as a hosting offering. Oracle is rare, too, but expensive.
3.) All three are free, in both senses of the word, while DB/2, Sybase, Oracle, etc., are not. (No preference in this area.)
4.) There is an enormous userbase for MySQL, and a sizable one for PostgreSQL, so I can get help from peers 24 by 7. SAPDB, unfortunately, does not have much in this area.
5.) PostgreSQL 7.1.x+ is supposed to scale better in many ways compared to MySQL 3.xx+. Many benchmarks seem to bear out the fact that PGSQL annihilates MySQL 3.xx, after about 5-10 or so web users. PGSQL seems to beat Oracle up through and beyond 100 simultaneous web users. I cannot find any benchmark on SAP, anywhere.
6.) Installing PostgreSQL and MySQL are easy, easy, easy. It's not so easy with SAPDB. While I'm no neophyte, when you consider remote hosting issues, I hope to have a system I can quickly rebuild if hardware dies.
7.) PostgreSQL has enough enterprise-ready features for my web site. MySQL did not (and probably still does not). SAPDB is almost overkill. Views, triggers, foreign keys, constraints of various kinds, stored procedures, versioning, hot backups, etc., are all available in PostgreSQL and SAPDB. One responder indicated that programming time is more important than benchmarks -- amen, preach it, brother. Your time programming and tweaking are far more expensive than hardware and most software.
8.) After working with PostgreSQL and MySQL, I saw that care and feeding (DBA work, in particular) were very simplified, straight forward, and quick. SAPDB smacks of Oracle, in terms of tweaking, complexity, etc. (I was an Oracle DBA for two years; a RedBrick DBA; worked for Informix; and have administered MySQL, PostgreSQL, and even lowly Access.) I haven't actually tried SAPDB, because it looks like a major investment of time.
9.) Books, web sites, and other literature are readily available for MySQL and PostgreSQL. SAPDB's included documentation is most excellent, however, followed by MySQL's included docs. PostgreSQL suffers in this area -- buy the books.
10.) As I scale up, I probably will have to consider something other than PostgreSQL, like SAPDB, DB/2, or Oracle. I refuse to look at Sybase or especially it ancestor, SQL Server. On the other hand, PostgreSQL is semi-tunable and the development team plans to be adding replication, etc., in the coming months. I'll have to wait-and-see. If SAP ERP can be hosted on SAPDB, then, well, it'll scale, no question. I'd contact the author of BinaryCloud for more objective info, here. http://www.binarycloud.com/
11.) Warning, total subjectivity: something about PostgreSQL seems "clean," compared to MySQL. I can't say what it is, but there is a big lack of business-likeness to MySQL, other than what I listed above. I'm sure the same is true about SAPDB, and more so, since it's got a real business and an ERP behind it.
12.) PostgreSQL, like MySQL, has a user-friendly SQL command line, with readline support, etc. I don't know about SAPDB, but I expect it to be less so, like Oracle's SQL*Plus. Can somebody help me out, here?
In conclusion, my first choice, for now, is PostgreSQL, my second would be SAPDB, my third is actually MySQL, followed by the commercial products. Again, I've never used SAPDB, but I hope to, in the near future; it seems "too big" for my needs, now, and information, outside of sapdb.org is scarce. I hope the community really gets around it, soon, so we can have a more objective look at the product. We need support groups and books available at our local book stores.
SAPDB looks absolutely excellent, while PostgreSQL looks good. MySQL has potential to be a business/enterprise-ready product, in a couple of years. I like the fact that SAPDB uses ODBC/UDBC for its native calls, like SQL Server, Access, and DB/2. MySQL, PostgreSQL, Oracle, and the like, require drivers to translate calls back and forth, slowing things down and adding complexity, for ODBC, UDBC, and JDBC.
For PostgreSQL, I gotta say, the thing that really impressed my was versioning, which makes transaction support and hot backups easy, while keeping performance very, very high.
Try out both databases. Use PGSQL today and SAP tomorrow, as you grow into it.
Oh yeah, how do you upgrade one of these systems?
on
Clockless Computing
·
· Score: 1
If you can't tell "how fast" one of these is, how then do you upgrade?
If you had a completely clockless system running at speed "x," whatever that means, how do you upgrade the same system with chips that are capable of running at "10x" speed?
Will slower clockless chips talk to/interface with faster clockless chips? How do you avoid overruns?
How do you know "how fast" a clockless system is?
on
Clockless Computing
·
· Score: 2, Insightful
Today, we get to benchmark a system using measurements such as TpM, MIPS, FLOPS, etc. How do you quantify how fast a clockless machine is? Yes, they're supposedly faster with fewer transistors, but how do you sell a clockless computer to somebody who asks you how much faster a system is than the old one it replaces?
The Pentium IV is supposed to be partially clockless, but to the outside world, all the I/O is clocked, making it easy to benchmark. If the I/O, logic, memory, etc., were ALL clockless, how fast is the machine?
Government contracts of big systems are really picky about things like this.
I think marketing will be the most likely problem for this technology. (Interfacing to clocked equipment won't be.)
Re:The Amiga Zorro Bus was Asyncronous
on
Clockless Computing
·
· Score: 2, Insightful
Are you just talking about a passive backplane? If so, we're talking about something VERY different here. If it's a passive backplane, you're talking about power and conections, little else.
You know, if enough./'ers raise a big stink about M$ not enforcing China's "sharing," while going after all those poor inner city kid's schools who are out of license compliance.... Hmmm.
In the pursuit of creating a language holy war, I'd say to use scripting and virtual machine languages, where possible.
JSP & PHP are great for web sites. Perl & Python are great replacements for shell scripting, as well as most general-purpose stuff. LISP is great, if you're a purist. Java has its uses, to be sure.
The point of all of this is that built-in memory allocation, built-in garbage collection, and a lack of pointers is A Very Good Thing(tm). You basically don't have bounds-checking problems. In general, scripting and VM code won't break due to memory leaks and the like.
Interpreted code, in particular, is highly reliable. As an example, Perl code, if well written, which means it traps all errors, etc., is rock solid. Python, I am told, is even more solid. C, on the other hand, is highly unstable. C++ is almost as bad, and VB code on M$ boxen, breaks all the time, as well.
These days, hardware, memory, and disk are SO cheap and fast that you *should* recoup almost all program performance costs associated in interpreted/scripting/vm languages in four ways: 1) faster, easier coding; 2) easier debugging; 3) more portability; 4) more reliable software. Of course, in the case of Perl, you've got to force good style upon yourself, so items 1 and 2 may not apply, some times....
I'd also avoid stuff that puts too much faith in the stability of dynamically linkable code. DLL's and COM objects in M$ land is a huge problem. It goes without saying that Linux's.so mess isn't nearly as great as M$'s.
C, C++, etc., have their uses, to be sure. People use C where it doesn't belong. It belongs in writing operating systems, interfaces, drivers, etc., but it isn't, for most intents and purposes, a good business language. C++ is better, but Java and *modern* scripting languages are even better, most of the time.
If we're going after "The Best Tool for the Job," I see that you need to balance among several different tensions: a semi-popular language (so you can get help, when needed), one that's well-documented (good books at your local book store and many web sites that cover it, for example), is highly portable (the larger, older, more successful, and more mature a project gets, the chances it'll get ported increase), does the job with a minimum amount of effort (planning, coding, testing, debugging, and documentation all go into this), won't crash unexpectedly (like C/C++/VB/assembly), runs quickly enough (with modern hardware and preemptive multitasking/multiprocessing operating systems, this isn't a bug issue, most of the time), is easy to fix/alter (most scripting languages don't have a compile step, so the code is the executable, ergo, it's usually easier to fix), and is general purpose (not specialized).
Just as important, you need to avoid the tensions of "too many" or "too few" languages for a project. Having 1 language that tries to force the big square peg in the small round hole is just as bad as 10 languages in a small to medium-sized project. Working on a team illustrates this even more. While SQL, OS shells, XML, HTML, and JavaScript are all exceptions to the rule (they're usually the only/main way to accomplish a specific task), having one person writing in C, another in C++, one in Perl, one in Python, another in VB, and still another in Java is usually a ticket to disaster, for most projects.
My personal rule of thumb: Perl for batch processing, utilities, command-line scripts, and most data massaging; PHP for small to medium web apps; JSP for larger web apps, or those created on teams of about 4 or more people; Java for most apps, especially GUIs; C/C++/VB for really specialized stuff; and what ever else, if you've got to support old code (new code from the above list).
Slashdot Mirror
Now, here's the first unbiased response I've seen for SAP-DB vs. PostgreSQL.
,have on performance for all three of these db's? What about including other DB's, such as SAP-DB, Interbase/Firebird, DB/2, Informix, and Sybase (all available for Linux, multiple Unices, and Windows?)
It makes me want to consider SAP-DB, since you've benchmarked it against 150+ users. I saw a MySQL vs. PostgreSQL vs Oracle (8i or 9i, I can't remember) benchmark on the same uniprocessor equipment. It showed PostgreSQL killing MySQL and Oracle from 5 to 100 users. 0-5 had MySQL shining, while 5-100 had PostgreSQL shining. They showed nothing past 100 simultaneous.
However, I could find little beyond what you just told me. For example, what effect do SMP, memory, RAID, SCSI vs. other technologies, tuning, number of users past 100/500/1000/5000, different query complexities, and the like
I certainly don't want to base my thoughts on one user's experience, but to see that in the real world, SAP-DB does indeed scale better, does picque my interest.
I do have a few questions, for anybody out there, though:
What kind of hardware?
What OS?
What were the results at different numbers of users?
I'd love to see somebody, anybody, have a free standardized benchmarking web site out there, that is unbiased and that checks multiple configs. It would be nice to do have it done "in the lab," as well as have end users use the lab's testing tools/configs and be able to submit their benchmarks, complete with memory, CPU, disk, configs, other system info, etc., as a comparison.
It could even be a site that lets users help other users to tune their OS, apps, drivers, and db's.
Would anyone do this?
Did Oracle get this in 9i? I don't remember any mention of MVCC for Oracle. They use redo logs, instead of MVCC, still, don't they? I hope I'm wrong, but I don't remember Oracle having this feature.
Oracle 7.x and 8.0 certainly don't -- I've checked this out repeatedly. I haven't checked into this for 8i and 9i, though.
MVCC *is* the stuff, and I agree, It's great for scalability. I preach MVCC. PG uses it, and so does Firebird/Interbase, I think. I'm not really 100% sure about SAP-DB.
Can you show me a web site about this? (Please do not point to a Slashdot article, unless it's a headline that can be substantiated. You can't trust Slashdot reader responses, including mine.)
I'm trying to not argue, but understand the two reasons you listed.
I'm not against PostgreSQL, Interbase/Firebird, or SAP-DB, I'm just wanting to know why. (I am against MySQL in a medium to large production environment, but we'll wait until 4.1+ materializes.)
First point, "VACUUM" problem. What's wrong with a cron job to do this, nightly? Does it bog the system down too much? Is it unreliable? (I haven't noticed any problems, but my DB is small, right now.) Read about MVCC (I think it's something like multiple version concurrency....) Versioning is better than redo logs, in theory. You need to understand MVCC to understand VACUUM. You can VACUUM live, without killing the DB, and perform hot backups as well, due to MVCC.
Second point, have you tuned it, and are you using PG 7.2+? If you are using older PostgreSQL's (prior to 7.1,) then yes, this is a problem. If you haven't tuned it, there are great docs about tuning. Supposedly, PG 7.1+ is VERY fast at many simultaneous connections, although I know of no 1000+ simultaneous connection benchmarks in existence. (Do you believe benchmarks, anyway?)
If you have tried a newer PG (7.2+,) and have followed all recommendations/tuning guides and still have had these problems, I'd really like to know.
I'm open to PostgreSQL (am using it), Interbase/Firebird, and SAP-DB and want the real scoop on things.
Will PG break under big loads? If so, how big? Does PG have a 24 by 7 problem?
He's right. Just go to http://www.arrl.org/ or http://www.fcc.gov/ for more information about propagation, which is *complex.*
ARRL has plenty of information about Amateur Radio and short wave radio, in particular. Look up information about shortwave, propagation, "skip," and "DX".
During the *day* HF/short wave also propagates differently than at *night,* since the ionosphere changes shape, due to the sun: UV, solar wind, solar flares, etc.
You'll notice on HF, AM, and CB that you can bring in many stations at night that you could not during the day -- for some frequencies, but not others.
I'd be willing to bet that you are either on the other side of a mountain (or mountains) from WWV, or their antenna array is not pointed your way (up, maybe?)
That reminds me, I need to update my Tech, No Code Amateur Radio licence....
What gives? Does Slashdot want to give credit to timothy, instead of a lowly grunt, like me? I posted this yesterday (same info, same links, different -- shorter -- text, but mine was rejected).
There have been several like this, including the Simputer article I posted 2 weeks earlier than Slashdot's actual post. It, too was rejected.
What's the point of "Submit Story," then?
</rant>
Wow, I wasn't thinking. Of course, cookies are on the client.
However, there are lots of interactions between client and server that need to be saved that aren't necessarily for the DB to handle.
I also fail to see how all OS'es/hardware combinations are going to be compatible w/ this.
BTW, there are already dual voice-coil drives out there in SCSI and SSA flavors....
In other words, is it even useful?
Huh?
h tml
a nce-tips.html or http://www.postgresql.org/idocs/index.php?geqo.htm l or http://www.ca.postgresql.org/docs/momjian/hw_perfo rmance/ or http://www.argudo.org/postgresql/soft-tuning.html or many others. Any DBA work their salt is going to tune the system. Out of the box, PG is designed for small systems, so as to not kill the box.
I guess you had a REALLY short eval of PostgreSQL, or were using an old copy, since both observations concerning PostgreSQL are false, again, unless you're using something older than 7.1.2 or haven't tuned it according to Bruce Momjian's guide.
As of 7.1.x, backups are hot: http://www.postgresql.org/idocs/index.php?backup.
Hot backups have been made possible, partly due to PG's versioning system.
As for load, once again, read some of the tuning guides, such as http://www.postgresql.org/idocs/index.php?perform
Many different kinds of benchmarks (believe them if you want to) actually show that PG outperforms MySQL (which really bogs down under load) and Oracle 8i (up to 100 simultaneous web connections). However, tuning Oracle and PG and changing platforms, etc., is going to affect performance drastically.
(Why is Slashdot chopping up my URL's? Good thing I previewed, first....)
You're right. Duh.
I also failed to have you look at Firebird/Interbase -- I wasn't thinking. Firebird might be a PostgreSQL killer. I have actually seen a web host, or two, with Interbase/Firebird support.
Almost all of the PostgreSQL/SAPDB advantages are available to Firebird/Interbase.
My list:
PostgreSQL (for now)
SAPDB or Firebird (future growth)
MySQL 4.1+ (maybe, maybe not)
I have done less research about Firebird than SAPDB. All 4 give a great deal of choice. Firebird is based off of Interbase and has a userr community probably larger than SAPDB. SAPDB still kills Firebird/Interbase and PostgreSQL in terms of enterprise features.
Ok, I have a few spelling, grammar, and punctuation mistakes. I was in a hurry, so subtract that from your flame bait, please.
I'm sorry that most of the responses haven't answered your question. I'll try to partially answer it, but I bet you already know all of this. I really like PostgreSQL and use it. If I were wanting to get a really big web site together, I'd try SAPDB, or just go with either DB/2 or Oracle.
My info about SAPDB is research-based, as I did a lot of that. Please feel free to correct me, if I'm wrong, in any way. MySQL has steadily improved, so a couple of items, below may be out of date.
I see that SAPDB is really an Oracle killer. It is a true enterprise-ready DB. If you want all the features of a big DB, such as replication, partitioning, etc., use SAPDB. You can get true commercial support, etc. Read their PDF's and be impressed.
However, you might want to know why I chose PostgreSQL over MySQL and SAPDB:
1.) PostgreSQL is really ACID compliant, as is SAPDB. MySQL, on the other hand hasn't yet proved itself in this area. Give MySQL a few more months, though, and we'll see, with version 4.1.
2.) Hosting companies support MySQL really well, and PostgreSQL only partially well. I have yet to see SAPDB as a hosting offering. Oracle is rare, too, but expensive.
3.) All three are free, in both senses of the word, while DB/2, Sybase, Oracle, etc., are not. (No preference in this area.)
4.) There is an enormous userbase for MySQL, and a sizable one for PostgreSQL, so I can get help from peers 24 by 7. SAPDB, unfortunately, does not have much in this area.
5.) PostgreSQL 7.1.x+ is supposed to scale better in many ways compared to MySQL 3.xx+. Many benchmarks seem to bear out the fact that PGSQL annihilates MySQL 3.xx, after about 5-10 or so web users. PGSQL seems to beat Oracle up through and beyond 100 simultaneous web users. I cannot find any benchmark on SAP, anywhere.
6.) Installing PostgreSQL and MySQL are easy, easy, easy. It's not so easy with SAPDB. While I'm no neophyte, when you consider remote hosting issues, I hope to have a system I can quickly rebuild if hardware dies.
7.) PostgreSQL has enough enterprise-ready features for my web site. MySQL did not (and probably still does not). SAPDB is almost overkill. Views, triggers, foreign keys, constraints of various kinds, stored procedures, versioning, hot backups, etc., are all available in PostgreSQL and SAPDB. One responder indicated that programming time is more important than benchmarks -- amen, preach it, brother. Your time programming and tweaking are far more expensive than hardware and most software.
8.) After working with PostgreSQL and MySQL, I saw that care and feeding (DBA work, in particular) were very simplified, straight forward, and quick. SAPDB smacks of Oracle, in terms of tweaking, complexity, etc. (I was an Oracle DBA for two years; a RedBrick DBA; worked for Informix; and have administered MySQL, PostgreSQL, and even lowly Access.) I haven't actually tried SAPDB, because it looks like a major investment of time.
9.) Books, web sites, and other literature are readily available for MySQL and PostgreSQL. SAPDB's included documentation is most excellent, however, followed by MySQL's included docs. PostgreSQL suffers in this area -- buy the books.
10.) As I scale up, I probably will have to consider something other than PostgreSQL, like SAPDB, DB/2, or Oracle. I refuse to look at Sybase or especially it ancestor, SQL Server. On the other hand, PostgreSQL is semi-tunable and the development team plans to be adding replication, etc., in the coming months. I'll have to wait-and-see. If SAP ERP can be hosted on SAPDB, then, well, it'll scale, no question. I'd contact the author of BinaryCloud for more objective info, here. http://www.binarycloud.com/
11.) Warning, total subjectivity: something about PostgreSQL seems "clean," compared to MySQL. I can't say what it is, but there is a big lack of business-likeness to MySQL, other than what I listed above. I'm sure the same is true about SAPDB, and more so, since it's got a real business and an ERP behind it.
12.) PostgreSQL, like MySQL, has a user-friendly SQL command line, with readline support, etc. I don't know about SAPDB, but I expect it to be less so, like Oracle's SQL*Plus. Can somebody help me out, here?
In conclusion, my first choice, for now, is PostgreSQL, my second would be SAPDB, my third is actually MySQL, followed by the commercial products. Again, I've never used SAPDB, but I hope to, in the near future; it seems "too big" for my needs, now, and information, outside of sapdb.org is scarce. I hope the community really gets around it, soon, so we can have a more objective look at the product. We need support groups and books available at our local book stores.
SAPDB looks absolutely excellent, while PostgreSQL looks good. MySQL has potential to be a business/enterprise-ready product, in a couple of years. I like the fact that SAPDB uses ODBC/UDBC for its native calls, like SQL Server, Access, and DB/2. MySQL, PostgreSQL, Oracle, and the like, require drivers to translate calls back and forth, slowing things down and adding complexity, for ODBC, UDBC, and JDBC.
For PostgreSQL, I gotta say, the thing that really impressed my was versioning, which makes transaction support and hot backups easy, while keeping performance very, very high.
Try out both databases. Use PGSQL today and SAP tomorrow, as you grow into it.
If you had a completely clockless system running at speed "x," whatever that means, how do you upgrade the same system with chips that are capable of running at "10x" speed?
Will slower clockless chips talk to/interface with faster clockless chips? How do you avoid overruns?
The Pentium IV is supposed to be partially clockless, but to the outside world, all the I/O is clocked, making it easy to benchmark. If the I/O, logic, memory, etc., were ALL clockless, how fast is the machine?
Government contracts of big systems are really picky about things like this.
I think marketing will be the most likely problem for this technology. (Interfacing to clocked equipment won't be.)
Are you just talking about a passive backplane? If so, we're talking about something VERY different here. If it's a passive backplane, you're talking about power and conections, little else.
Can we benefit Really Soon(tm) from LA being integrated into PAM?
You go. Shame on ./'ers marking this as a troll. Why? Just because he gave a dissenting opinion, to another dissenting opinion?
Crazy.
You know, if enough ./'ers raise a big stink about M$ not enforcing China's "sharing," while going after all those poor inner city kid's schools who are out of license compliance.... Hmmm.
Couldn't hack it in the ring, I see....
Um. Web generation, that is.
I have to admit. I've always hated IDE's and code generation tools, until I tried out CCS 1.16 and 2.0.
Now, CCS Studio really looks like a professional environment that could probably cut your coding down to 1/5, perhaps to 1/10.
It also does some content management.
In the pursuit of creating a language holy war, I'd say to use scripting and virtual machine languages, where possible.
.so mess isn't nearly as great as M$'s.
JSP & PHP are great for web sites. Perl & Python are great replacements for shell scripting, as well as most general-purpose stuff. LISP is great, if you're a purist. Java has its uses, to be sure.
The point of all of this is that built-in memory allocation, built-in garbage collection, and a lack of pointers is A Very Good Thing(tm). You basically don't have bounds-checking problems. In general, scripting and VM code won't break due to memory leaks and the like.
Interpreted code, in particular, is highly reliable. As an example, Perl code, if well written, which means it traps all errors, etc., is rock solid. Python, I am told, is even more solid. C, on the other hand, is highly unstable. C++ is almost as bad, and VB code on M$ boxen, breaks all the time, as well.
These days, hardware, memory, and disk are SO cheap and fast that you *should* recoup almost all program performance costs associated in interpreted/scripting/vm languages in four ways: 1) faster, easier coding; 2) easier debugging; 3) more portability; 4) more reliable software. Of course, in the case of Perl, you've got to force good style upon yourself, so items 1 and 2 may not apply, some times....
I'd also avoid stuff that puts too much faith in the stability of dynamically linkable code. DLL's and COM objects in M$ land is a huge problem. It goes without saying that Linux's
C, C++, etc., have their uses, to be sure. People use C where it doesn't belong. It belongs in writing operating systems, interfaces, drivers, etc., but it isn't, for most intents and purposes, a good business language. C++ is better, but Java and *modern* scripting languages are even better, most of the time.
If we're going after "The Best Tool for the Job," I see that you need to balance among several different tensions: a semi-popular language (so you can get help, when needed), one that's well-documented (good books at your local book store and many web sites that cover it, for example), is highly portable (the larger, older, more successful, and more mature a project gets, the chances it'll get ported increase), does the job with a minimum amount of effort (planning, coding, testing, debugging, and documentation all go into this), won't crash unexpectedly (like C/C++/VB/assembly), runs quickly enough (with modern hardware and preemptive multitasking/multiprocessing operating systems, this isn't a bug issue, most of the time), is easy to fix/alter (most scripting languages don't have a compile step, so the code is the executable, ergo, it's usually easier to fix), and is general purpose (not specialized).
Just as important, you need to avoid the tensions of "too many" or "too few" languages for a project. Having 1 language that tries to force the big square peg in the small round hole is just as bad as 10 languages in a small to medium-sized project. Working on a team illustrates this even more. While SQL, OS shells, XML, HTML, and JavaScript are all exceptions to the rule (they're usually the only/main way to accomplish a specific task), having one person writing in C, another in C++, one in Perl, one in Python, another in VB, and still another in Java is usually a ticket to disaster, for most projects.
My personal rule of thumb: Perl for batch processing, utilities, command-line scripts, and most data massaging; PHP for small to medium web apps; JSP for larger web apps, or those created on teams of about 4 or more people; Java for most apps, especially GUIs; C/C++/VB for really specialized stuff; and what ever else, if you've got to support old code (new code from the above list).
While it may not be EXACTLY what you want, it may be MORE....
I'd like to know "When will Windoze be done?"
Better yet, subscribe.