Slashdot Mirror

There are features Oracle provides that have no PostgreSQL equivalent.

• Price -- it costs a lot of money. For many governmental entities, this is a huge advantage -- as they are given a budget, and they need to spend it, otherwise their budget will get reduced -- if its an excuse to spend money, based on claims of productivity, they will often deny requests to use OSS, and mandate the use of Oracle, based on its productivity-improving and more-reliable qualities that some slick salesman persuaded them of, after taking them out for steak at a 5-star restaurant somewhere, or whatever. Also; I hear plenty of government workers saying Management has a no open source software policy; for security reasons, the more money spent on the product the better, as closed source code is deemed to be more secure... For me, and business i'm involved with, this is a huge negative for Oracle, and a reason I almost always pick Postgresql; yes, Oracle delivers more, BUT in many cases you pay Oracle for every extra cent of additional incremental value Oracle delivers over Postgres, and maybe 300% more.
• RAS features -- such as clustering Oracle RAC
• Development productivity tools such as - Pro*C
• SQL Language features where Oracle's implementation is superior -- such as BLOBs. Postgres manages these poorly, for example, you cannot reliably pg_dump blobs - if your application is BLOB happy (e.g. Sharepoint-like), then Postgres is not very suitable.
• SQL Language features that have no PostgreSQL analog -- such as CONNECT BY clauses, Java class based schema and table mappings; module languages; XML types; default value funciton parameters; organize stored procedure objects using packages; .

Um, NO. The "all application code should go through stored procedures" is recommended because you parametrize all user input, which prevents all softs of nasty sql injection attacks from little Bobby Drop Tables.

http://psoug.org/blogs/mike/2010/04/11/little-bobby-tables/

Since you're using Oracle, there some ways to prevent access to other parts of the schema and prevent run-on queries from going nuts.

Create a user for them, specifically for these ad-hoc queries. This user should have no disk quotas on any tablespace, since they're not writing any data. This user should only have the 'Create session' privilege.

Second, if your customer data is all in big_honkin_schema, create some views for them. Create the views in another schema and grant them select only.

Third, if you're REALLY worried about them "touching your precious tables"[1] then create them materialized views instead. Might have to adjust disk quotas of course.

You can also set up user profiles to limit resource consumption ( number of sessions, maximum CPU time, et. al. ).

[1] Since when did Gollum become a DBA? ;-)

Well Oracle 10g seems to be pretty good:

http://www.psoug.org/rac_on_mac.html/ rac on mac.

These guys have no mac bias, the dba who did much of this config regularly deploys very large systems for Boeing, etc.

And they find; "In the 64bit technology space no company ... not IBM with AIX, not Hewlett Packard with HP/UX, not Sun with Solaris, and not Dell with any operating system can match the Apple OSX/Darwin technology and price."

It wasn't designed as a server OS because you've seen that in a few specific instances, thread creation times are slow? Give me a fucking break.

I know a lot of folks who run some pretty high performance/high load apps on OS X. I also talked to these guys:

http://www.psoug.org/rac_on_mac.html

Who have deployed 3 Oracle 10g RAC installations on Xserve G5's. They said in their testing that 10g on a dual 2.0 G5 was about 30% faster than on a dual Xeon 2.4 on Windows. Now that's not Linux (they hadn't done the direct comparo), but that shows that it's not completely unfit for server operation.