By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,541 Members | 1,455 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,541 IT Pros & Developers. It's quick & easy.

need for concrete info

P: n/a
I've been using PG very lightly for quite awhile, (although I"ve read
through all but the programmer's manual once or twice). I loved when I
got to PG and it had Oracle like features, "A real database!". This is
after using MySQL, which I first though, "I'm programming a website off
a simple, easy to use, non msoft product, yippee!".

Well, now I am writing a proposal, which among many other points,
proposes to switch from the current hosting site of a non profit to a
slightly more expensive one running PostgreSQL, (where I have some other
projects.) I want to use as my main argument, the fact (at this time,
only from my previous usage), that MySQL really doesn't have foreign
keys or record locking, and Postgres does.

I will be trusted to say this, and I don't have to reprint the manuals
from each DB in my proposal, or maybe I will. But anyway, I'm still
correct with today's MySQL vs. PostgreSQL, right? I *really* want to use
PostgreSQL for this project and not MySQL as I want to avoid growing
pains trying to get MySQL to do the job of a bigger DB down the road.

--
"You are behaving like a man",
is an insult from some women,
a compliment from an good woman.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
On Sat, Oct 11, 2003 at 05:48:23PM -0700, Dennis Gearon wrote:
projects.) I want to use as my main argument, the fact (at this time,
only from my previous usage), that MySQL really doesn't have foreign
keys or record locking, and Postgres does.
Define "really". Certainly, for some cases, it now does.
correct with today's MySQL vs. PostgreSQL, right? I *really* want to use
PostgreSQL for this project and not MySQL as I want to avoid growing
pains trying to get MySQL to do the job of a bigger DB down the road.


Why don't you make the "growing pains" argument instead? What are
those arguments, anyway? ( I think I know, but maybe not.)

A

--
----
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
<an****@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #2

P: n/a
Quoting Dennis Gearon <ge*****@fireserve.net>:
I've been using PG very lightly for quite awhile, (although I"ve read
through all but the programmer's manual once or twice). I loved when I
got to PG and it had Oracle like features, "A real database!". This is
after using MySQL, which I first though, "I'm programming a website off
a simple, easy to use, non msoft product, yippee!".

Well, now I am writing a proposal, which among many other points,
proposes to switch from the current hosting site of a non profit to a
slightly more expensive one running PostgreSQL, (where I have some other
projects.) I want to use as my main argument, the fact (at this time,
only from my previous usage), that MySQL really doesn't have foreign
keys or record locking, and Postgres does.

I will be trusted to say this, and I don't have to reprint the manuals
from each DB in my proposal, or maybe I will. But anyway, I'm still
correct with today's MySQL vs. PostgreSQL, right? I *really* want to use
PostgreSQL for this project and not MySQL as I want to avoid growing
pains trying to get MySQL to do the job of a bigger DB down the road.

--
"You are behaving like a man",
is an insult from some women,
a compliment from an good woman.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly


Dennis,

I used to go through this a lot too especially several years ago and I have to
admit it becomes a hard sell in many cases since quite often the person signing
the check *wants* a certain afiliation- "I hear Oracle is the way to go, so we
want you to go that way". After awhile, I got tired of trying to educate
people. I simply give them my recommendation and some bullet-points about why I
think they should use this or that. Generally I'm technology neutral but
recently, I've started including verbage in my proposals mentioning what my
application environment is (Linux, Apache, PostgreSQL, etc). That was actually
done because of all problem with MS products (viruses, worms, security, etc).
In doing that, I found that folks are less likely to ask questions about the
"environment" because they're not gonna understand all the little integration
points but with a product they think they do.

Still you could ave a million reasons why
one product is better than the other that might not get the buy in. Some shirt
may say, "no, I heard SAP is working with
MySQL and SAP is a great company so can you do that?"- hopefully you're not
dealing with that type of ignorance. I'm sure you've heard some pretty idiotic
reasons people come up with to NOT use PostgreSQL too.

These threads on MySQL vs. PostgreSQL keep coming up and to me its kinda
interesting because it not even an apples to apples comparison but obviously its
relevant out there. I would take a different approach if I were asked and say
something like, "MySQL doesn't meet my company's criteria for developing
applications for reliable data storage and management". At the very least,
you'll draw and eyebrow or two and be asked to explain. Now, you can hit them
with the details. I would even preface your answers with, "Well, after looking
in MySQL, I found that it can to <whatever feature> but as PostgreSQL has had
these features a lot longer. I would not want to risk YOUR DATA to such a product."

I'm sure you get the idea. :)

Good luck!
--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #3

P: n/a
Centuries ago, Nostradamus foresaw when an****@libertyrms.info (Andrew Sullivan) would write:
On Sat, Oct 11, 2003 at 05:48:23PM -0700, Dennis Gearon wrote:
projects.) I want to use as my main argument, the fact (at this time,
only from my previous usage), that MySQL really doesn't have foreign
keys or record locking, and Postgres does.


Define "really". Certainly, for some cases, it now does.
correct with today's MySQL vs. PostgreSQL, right? I *really* want to use
PostgreSQL for this project and not MySQL as I want to avoid growing
pains trying to get MySQL to do the job of a bigger DB down the road.


Why don't you make the "growing pains" argument instead? What are
those arguments, anyway? ( I think I know, but maybe not.)


I would think that the 'non-validation of domain information' part
would be an even better argument.

It's easy to explain, which is vital.

You can give examples: "If we try to insert such-and-such data, which
happens to be wrong, MySQL will silently insert _different_ wrong
information, and not complain at all."

In contrast, they can put all sorts of extra validation tests on
domains in PostgreSQL, and it can quietly _prevent_ application bugs
from corrupting data. That doesn't mean that _every_ sort of
corruption is prevented, but there can be some meaningful ones.

For instance, if a particular column is required to be in lower case,
then a domain constraint to that effect means that if someone makes an
application mistake, the database will catch it. Sort of like wearing
a belt _and_ suspenders.
--
(format nil "~S@~S" "aa454" "freenet.carleton.ca")
http://www3.sympatico.ca/cbbrowne/advocacy.html
If at first you don't succeed, try duct tape. If duct tape doesn't
work, give up.
Nov 12 '05 #4

P: n/a
on 10/11/03 6:48 PM, ge*****@fireserve.net purportedly said:
Well, now I am writing a proposal, which among many other points,
proposes to switch from the current hosting site of a non profit to a
slightly more expensive one running PostgreSQL, (where I have some other
projects.) I want to use as my main argument, the fact (at this time,
only from my previous usage), that MySQL really doesn't have foreign
keys or record locking, and Postgres does.

I will be trusted to say this, and I don't have to reprint the manuals
from each DB in my proposal, or maybe I will. But anyway, I'm still
correct with today's MySQL vs. PostgreSQL, right? I *really* want to use
PostgreSQL for this project and not MySQL as I want to avoid growing
pains trying to get MySQL to do the job of a bigger DB down the road.


MySQL is closing the gap, so many of its drawbacks are no longer the case,
and you have to look a little harder for its weaknesses, but they are there.
Fortunately, MySQL spells many of them out for you:
http://www.mysql.com/documentation/m...oduction.html#
Roadmap

You will see that MySQL has planned to implement features that Postgres has
had for a long time (in development terms). In Postgres, they are tried and
true. In MySQL, it will take a while, and do you want your application to
help them beta test? You may also want to consider that their implementation
schedule may not correspond with yours.

Even if one could argue that the missing features are unnecessary for your
application, there is one huge problem (in my mind) that MySQL continues to
have, namely it does not honor NOT NULL constraints. Granted, you can
enforce this by recompiling with a specific option, but if you currently do
not have any control over the compilation or configuration of MySQL you are
stuck. Even if you can get this option, there are issues with multiple
inserts arising out of a single statement, but that would imply that their
transaction handling mechanism is not robust or it wouldn't be an issue.

I would add that I am not a MySQL basher--I have used MySQL in amhy
instances and it performs perfectly well in those cases. I simply believe
(with justification) that Postgres is a better product, especially for
larger and more complicated applications.

Best,

Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #5

P: n/a
On Sat, 2003-10-11 at 19:48, Dennis Gearon wrote:

http://www.aci-int.org/

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA

Regarding war zones: "There's nothing sacrosanct about a hotel
with a bunch of journalists in it."
Marine Lt. Gen. Bernard E. Trainor (Retired)
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #6

P: n/a
How about the inconsistency on MySQL (not only with NULL values). Try
inserting a 64 bit integer in a 32 bit field and check the result. It's not a
bug, it's "gotcha"!!

By the way, we are building an aplication with PHP and PostgreSQL, and I can
tell you that we would have had real pains if we were to use the other DB.
Mainly we are making lots of functions in plpgsql, and loading some triggers,
things very usefull, and missing in MySQL.

El Dom 12 Oct 2003 15:12, Keary Suska escribió:
on 10/11/03 6:48 PM, ge*****@fireserve.net purportedly said:
Well, now I am writing a proposal, which among many other points,
proposes to switch from the current hosting site of a non profit to a
slightly more expensive one running PostgreSQL, (where I have some other
projects.) I want to use as my main argument, the fact (at this time,
only from my previous usage), that MySQL really doesn't have foreign
keys or record locking, and Postgres does.

I will be trusted to say this, and I don't have to reprint the manuals
from each DB in my proposal, or maybe I will. But anyway, I'm still
correct with today's MySQL vs. PostgreSQL, right? I *really* want to use
PostgreSQL for this project and not MySQL as I want to avoid growing
pains trying to get MySQL to do the job of a bigger DB down the road.


MySQL is closing the gap, so many of its drawbacks are no longer the case,
and you have to look a little harder for its weaknesses, but they are
there. Fortunately, MySQL spells many of them out for you:
http://www.mysql.com/documentation/m...roduction.html
# Roadmap

You will see that MySQL has planned to implement features that Postgres has
had for a long time (in development terms). In Postgres, they are tried and
true. In MySQL, it will take a while, and do you want your application to
help them beta test? You may also want to consider that their
implementation schedule may not correspond with yours.

Even if one could argue that the missing features are unnecessary for your
application, there is one huge problem (in my mind) that MySQL continues to
have, namely it does not honor NOT NULL constraints. Granted, you can
enforce this by recompiling with a specific option, but if you currently do
not have any control over the compilation or configuration of MySQL you are
stuck. Even if you can get this option, there are issues with multiple
inserts arising out of a single statement, but that would imply that their
transaction handling mechanism is not robust or it wouldn't be an issue.

I would add that I am not a MySQL basher--I have used MySQL in amhy
instances and it performs perfectly well in those cases. I simply believe
(with justification) that Postgres is a better product, especially for
larger and more complicated applications.

Best,

Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html


--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mm******@unl.edu.ar
Programador, Administrador, DBA | Centro de Telemática
Universidad Nacional
del Litoral
-----------------------------------------------------------------
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 12 '05 #7

P: n/a
Ron Johnson wrote:
On Sat, 2003-10-11 at 19:48, Dennis Gearon wrote:

http://www.aci-int.org/

ROTFLMAO. I needed that as a gut buster - before I dig into homework!
Thanks very much!

--
"You are behaving like a man",
is an insult from some women,
a compliment from an good woman.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 12 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.