Thread: Oracle, MySQL, and PostgreSQL feature comparison - Part 2
Sean Hull over at Database Journal has posted Part 2 of his database comparison.
Here are links to both parts:
Part 1 - http://www.databasejournal.com/features/oracle/article.php/3692566
Part 2 - http://www.databasejournal.com/features/oracle/article.php/3703376
I’d be interested to get the community’s take on the portrayal of Postgres.
Derek
Derek M. Rodner
Director, Product Strategy
EnterpriseDB Corporation
732.331.1333 office
484.252.1943 cell
www.enterprisedb.com
On Thu, 11 Oct 2007 13:45:41 -0400 "Derek Rodner" <derek.rodner@enterprisedb.com> wrote: > Sean Hull over at Database Journal has posted Part 2 of his database > comparison. > > > > Here are links to both parts: > > Part 1 - > http://www.databasejournal.com/features/oracle/article.php/3692566 > Sounds like an Oracle guy... ;).. I notice he talks a whole lot about Oracle stored procedures but doesn't even note any specific differences. MySQL for example, "barely" supports stored procedures. Nor does he mention the high extensibility of PostgreSQL stored procedures. > Part 2 - > http://www.databasejournal.com/features/oracle/article.php/3703376 > Here he talks about our index support and apparently just skimmed our docs without actually reading them. He is missing discussion on GIN, the fact that you can have custom index types (if you really wanted), he speaks about rtree which we actually don't support, it has been pushed into GIST and he completely forgoes mention of ltree. He doesn't actually talk about Transaction support at all. Joshua D. Drake > > > I'd be interested to get the community's take on the portrayal of > Postgres. > > > > Derek > > > > Derek M. Rodner > > Director, Product Strategy > > EnterpriseDB Corporation > > 732.331.1333 office > > 484.252.1943 cell > > www.enterprisedb.com > > > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/
Attachment
On 10/11/07, Derek Rodner <derek.rodner@enterprisedb.com> wrote: > Sean Hull over at Database Journal has posted Part 2 of his database > comparison. > ... > I'd be interested to get the community's take on the portrayal of Postgres. Both articles are fairly uninformed when it comes to all three databases. Under Stored Procedures, it doesn't mention that MySQL doesn't support dynamic SQL within them. Triggers says all systems them support them, but doesn't differentiate statement-level and row-level triggers (which MySQL doesn't support). Similarly, multiple Oracle and Postgres claims are wrong. Under Indexing, it doesn't mention that you can write your own index implementations in Oracle. Likewise, it states that functional indexes are slow? Under Data Types, it doesn't mention that Oracle supports native float and double (but gives MySQL and Postgres props for it). Likewise, it says Postgres supports 4GB text... nope. Under Transaction Support, it says, "Oracle's own performance views in its data dictionary are not transactional. The reason? Performance of the overall system would be abysmal if they tried that." Yeah, that's because they are *dynamic* views... and they represent runtime data, not stored data; a completely invalid comparison to MyISAM. Sadly, the author of this article seemingly meets the Jack of all trades, master of none criteria. It would've been more helpful for this dude to at least read the Postgres manual :( -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com Edison, NJ 08837 | http://www.enterprisedb.com/
On Thu, 2007-10-11 at 13:45 -0400, Derek Rodner wrote: > Sean Hull over at Database Journal has posted Part 2 of his database > comparison. > > > > Here are links to both parts: > > Part 1 - > http://www.databasejournal.com/features/oracle/article.php/3692566 > > Part 2 - > http://www.databasejournal.com/features/oracle/article.php/3703376 > > One thing that stood out to me was: "Auditing Oracle allows you to enable auditing to a table, or a file via the audit trail facility. Once enabled, you can audit insert, update, or delete on a specific table, for instance, or logins, or even all access by a particular user. There are quite a few options, and it's easy to enable. Postgresql too has this functionality and it seems to be as flexible and configurable as Oracle's. ..." What functionality is he referring to? There are some projects on pgfoundry, but I don't think of the auditing capabilities of postgresql as either complete or easy. Regards, Jeff Davis
Hello, Am 11.10.2007 um 19:45 schrieb Derek Rodner: > Part 1 - http://www.databasejournal.com/features/oracle/article.php/ > 3692566 > > Part 2 - http://www.databasejournal.com/features/oracle/article.php/ > 3703376 I guess it does not either hurt nor help anybody. The author takes his projects as a measure but does not reveal them. Under datatypes he misses spatial data which might be not interesting to many but is really important to those who deal with that and that might be the case with many other features I dont know about. After all, I would not spent time on this irrelevant piece of writing. Bye, Christian
On 10/11/07, Jeff Davis <pgsql@j-davis.com> wrote: > Postgresql too has this functionality and it seems to be as flexible and > configurable as Oracle's. Not exactly. Oracle auditing uses autonomous transactions and actually logs attempts to change data as well as changes themselves whereas Postgres would only log to a table on commit. In Postgres, you have to specifically write a trigger which simulates an autonomous transaction using dblink. -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com Edison, NJ 08837 | http://www.enterprisedb.com/
Derek Rodner wrote: > > Sean Hull over at Database Journal has posted Part 2 of his database > comparison. > > > > Here are links to both parts: > > Part 1 - > http://www.databasejournal.com/features/oracle/article.php/3692566 > > Part 2 - > http://www.databasejournal.com/features/oracle/article.php/3703376 > 1) The article suggests that PostgreSQL does not have a cost-based planner. We do (why vacuum analyze is important). 2) No real discusion of differences in stored procedures. In general, I haven't found anything (including multi-set returning functions) you can't do with PostgreSQL stored procedures that can be done on other RDBMS's, and lots of things that can be done much easier in PostgreSQL. 3) If he really wants to show that Oracle is needed in some areas, discussing parallelism in query execution would have been a good way to go. 4) The discussion of the transaction complaints as relate to MySQL completely miss the point. It is not hte case that non-transactional table types are completely useless, but rather that they can be created by accident, silently, when a transactional table type is requested. 5) MySQL has a very different approach to security than does PostgreSQL and Oracle. These are lumped together as a similarity when they really should be treated as a set of profound differences. Best Wishes, Chris Travers
On Thu, 2007-10-11 at 14:53 -0400, Jonah H. Harris wrote:
> On 10/11/07, Jeff Davis <pgsql@j-davis.com> wrote:
> > Postgresql too has this functionality and it seems to be as flexible and
> > configurable as Oracle's.
>
> Not exactly. Oracle auditing uses autonomous transactions and
> actually logs attempts to change data as well as changes themselves
> whereas Postgres would only log to a table on commit. In Postgres,
> you have to specifically write a trigger which simulates an autonomous
> transaction using dblink.
>
Very true. Also, I find it awkward and difficult to do things like:
* audit data being _read_
* if using logging options to audit, it's almost impossible to separate
the audit trails from other log entries
* if auditing using a mechanism other than the postgres log, you can't
record statements, e.g. "DROP TABLE" or "ALTER USER ... PASSWORD ...".
I would like postgres to have a really good auditing system. For me,
it's one of the most important features that postgresql doesn't already
have.
Regards,
Jeff Davis
On 10/11/07, Jeff Davis <pgsql@j-davis.com> wrote: > I would like postgres to have a really good auditing system. For me, > it's one of the most important features that postgresql doesn't already > have. Agreed. -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com Edison, NJ 08837 | http://www.enterprisedb.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > Part 1 - > http://www.databasejournal.com/features/oracle/article.php/3692566 > > Part 2 - > http://www.databasejournal.com/features/oracle/article.php/3703376 > > I'd be interested to get the community's take on the portrayal > of Postgres. Wow. I thought that it couldn't get worse than Part 1. I was wrong. Unlike part 1, which is full of vague statements and offers no real content, part 2 is full of misinformation about all three database systems, and simply adds more confusion rather than helping anyone learn any actual feature comparisons. Amazing that anyone would publish something like that. I would think an editor at Database Journal who was even vaguely familiar with any of the three systems would have intervened. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200710111529 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFHDnoCvJuQZxSWSsgRA5i3AKDd0Nuy6FBxmcuVdyrRqT7F3PIaSACg/U/A I0wu3B1NlcYi9iAwiT/8aR4= =Cibp -----END PGP SIGNATURE-----
On Thu, 2007-10-11 at 15:26 -0400, Jonah H. Harris wrote:
> On 10/11/07, Jeff Davis <pgsql@j-davis.com> wrote:
> > I would like postgres to have a really good auditing system. For me,
> > it's one of the most important features that postgresql doesn't already
> > have.
>
> Agreed.
>
My ideas on the subject are fairly vague.
Do you have a link to a well-thought-out design for database auditing,
that PostgreSQL could use as a model for implementation? The list
archives are fairly sparse on the subject.
I might have time to do some work on this.
Regards,
Jeff Davis