[ale] WooHoo!! PostgreSQL 9.1!
Michael H. Warfield
mhw at WittsEnd.com
Sat Sep 17 18:05:28 EDT 2011
On Sat, 2011-09-17 at 13:52 -0400, Michael B. Trausch wrote:
> On Sat, 2011-09-17 at 10:23 -0400, Narahari 'n' Savitha wrote:
> > Just curious why it s the best rdbms ?
>
> There are a number of reasons. I'm just going to be touching the tip of
> the iceberg here; independent research will be of far better use to you.
>
> First, features:
>
> * Rich data types out of the box.
> * The ability to define new data types with ease.
> * The notion of database.schema.table makes compartmentalization of
> data used by a single application very simple.
> * The ability to use multiple languages for stored procedures is
> just plain awesome.
> * Only a single type of data storage, which means that it gets all
> of the attention and is optimized and better-tested than database
> engines that have multiple storage types (such as MySQL).
> * ACID compliant, through and through. There are no table types or
> associated bologna that discard data/referential integrity for
> any reason at all.
> * Security is taken seriously.
> * BSD license, which means that you can embed it in your software
> system without all the complications that the special MySQL (and
> thus derivatives) license (GPL with modifications, essentially)
> gives you. No need to consult a lawyer about getting a binary
> or proprietary license, either, because it's BSD.
> * Takes data integrity VERY seriously.
> * Takes data integrity VERY SERIOUSLY.
> * TAKES DATA INTEGRITY VERY SERIOUSLY.
> I think that's probably a good start. :-)
I'll throw in a few points here. I concur with all the points above and
include here in.
I've used MySQL (and a few other proprietary ones, I won't named, when
forced to) as well as Postgres and, now, prefer it to MySQL when
configuring any programs that support both.
Postgresql has been consistently more advanced than MySQL down through
the years and had IPv6 support years before it became available in
MySQL, A point I even zinged some MySQL people on at a show years ago.
I know most people won't consider that to be of any consequence in their
environments, it merely points out to illustrate how Postgresql has been
more "state of the art" than MySQL.
I believe, though I could be wrong, they were the first of the two to
have atomic transactions that could be rolled back, but my memory there
is very fuzzy based on a talk I heard several years ago when one did and
one didn't. Not something I've ever used.
Down through the years, Postgresql has typically been zinged as being
less scalable and poorer performance, which it well deserved many years
ago. Their focus has been on features, data integrity, and standards
implementation and not as much on higher performance. Over a number of
major revs, the performance and scalability improved steadily that I've
now heard some people say that Postgresql can pretty much stand up to
MySQL noise to noise performance wise. I have not done the comparisons
myself and I'm sure people will immediately start dragging out
benchmarks "proving" or "disproving" that statement. Bottom line is,
though, performance has NOT been a limiting factor for Postgresql for
many years, though the reputation has stuck.
So, what advantages does MySQL have over Postgresql?
I'm sure some people will argue that Oracle is superior than Postgresql
and, in certain commercial environments, they might even be right.
OpenSource counts for more than a benefit of small consequence in
amongst this crowd here.
What other candidates would you hold up for us to compare against?
MSSql? Here?
> It is also in many ways much more compliant with the SQL standard than
> MySQL is. I've never used Oracle, but I have heard people who have used
> Oracle say that PostgreSQL is much more like Oracle than it is any other
> RDBMS. Again, I can't speak to the veracity of that statement, but I
> can say this: I won't do new projects on top of MySQL if there is any
> way that I can avoid it. MySQL is a joke when it comes to database
> engines. It is sloppy, it doesn't really care about things like
> referential integrity. You can make all sorts of little tweaks and
> modifications to try to gain the integrity support that PostgreSQL gives
> you out of the box, but why bother when you can deploy a database engine
> with a relatively stock configuration that is well-to-do both in
> performance and security?
> You can also extend PostgreSQL very easily by writing modules for it;
> you can do something similar for MySQL, but you would have to
> reimplement a good chunk of what's already in PostgreSQL as modules for
> MySQL before MySQL started to look like a truly viable option.
> MySQL is more like SQLite than most people would like to think. Except
> that even SQLite has better support for data integrity in many
> situations, and they consider themselves to be not a replacement for an
> RDBMS, but a replacement for the fopen() C library call.
I don't know if I would quite go that far. That seems a little
judgemental against MySQL. I've seen a number of pages support both
(and Postgresql) but I've also seen pages support MySQL and Postgresql
and NOT SQLite. I don't know the reason for it, if it's authors
preference, experience, or lacking some feature required. I wouldn't
disparage MySQL (other than what's happened to it at the hands of
Oracle) but I now prefer Postgresql, myself. You're mileage may vary.
> --- Mike
> --
> A man who reasons deliberately, manages it better after studying Logic
> than he could before, if he is sincere about it and has common sense.
> --- Carveth Read, “Logic”
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110917/8acbc323/attachment.bin
More information about the Ale
mailing list