Обсуждение: need for concrete info
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.
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
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
Quoting Dennis Gearon <gearond@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 majordomo@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
on 10/11/03 6:48 PM, gearond@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/mysql/bychapter/manual_Introduction.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"
On Sat, 2003-10-11 at 19:48, Dennis Gearon wrote: http://www.aci-int.org/ -- ----------------------------------------------------------------- Ron Johnson, Jr. ron.l.johnson@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)
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, gearond@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/mysql/bychapter/manual_Introduction.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 | mmarques@unl.edu.ar Programador, Administrador, DBA | Centro de Telemática Universidad Nacional del Litoral -----------------------------------------------------------------
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.
Centuries ago, Nostradamus foresaw when andrew@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.