MySQL versus Postgres

On Fri, Aug 6, 2010 at 04:41, John Gage <jsmgage@numericable.fr> wrote:

[...]

So, perhaps what is needed in any sort of battle with MySQL is an
introductory documentation that gives specific examples of how to achieve
"oh wow!" worthwhile results quickly with Postgres.

Bruce Momjian's book is an excellent primer:
http://www.postgresql.org/docs/books/awbook.html

--
- Rikard

2010/8/6 Rikard Bosnjakovic <rikard.bosnjakovic@gmail.com>:

On Fri, Aug 6, 2010 at 04:41, John Gage <jsmgage@numericable.fr> wrote:

[...]

So, perhaps what is needed in any sort of battle with MySQL is an
introductory documentation that gives specific examples of how to achieve
"oh wow!" worthwhile results quickly with Postgres.

Bruce Momjian's book is an excellent primer:
http://www.postgresql.org/docs/books/awbook.html

It is *very* outdated (I remember using that to get started myself,
almost 10 years ago) and a lot has been improved since then.

Ian Barwick

John Gage schrieb:

So, perhaps what is needed in any sort of battle with MySQL is an
introductory documentation that gives specific examples of how to
achieve "oh wow!" worthwhile results quickly with Postgres.

I receive my "oh wow" when i do the same things in Postgres like in
MySQL: Writting some procedures, triggers and use foreign key. The "oh
wow" was that it just *works*. After some years of using MySQL this is a
very uncommon feeling, even if you are experienced which MySQL. ;)

And after that "oh wow" you starting reading the manual.

Greetings from Germany,
Torsten

--
http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8
verschiedenen Datenbanksystemen abstrahiert,
Queries von Applikationen trennt und automatisch die Query-Ergebnisse
auswerten kann.

On 6 August 2010 16:08, Torsten Zühlsdorff <foo@meisterderspiele.de> wrote:

I receive my "oh wow" when i do the same things in Postgres like in MySQL:
Writting some procedures, triggers and use foreign key. The "oh wow" was
that it just *works*. After some years of using MySQL this is a very
uncommon feeling, even if you are experienced which MySQL. ;)

I'm going the other way -- I first started SQL/RDBMS with PostgreSQL, and
now I'm starting to have to deal with MySQL for some things at work. I know
exactly how to do what I want in PG, but doing the same thing in MySQL is
ten times more complicated and has me pulling my hair out :(

John Gage wrote on 06.08.2010 04:41:

But most people, including myself, don't even want to know the
documentation exists (for anything). We just want to plunge in and do it.

That just doesn't work and is an attitude that won't get you far.

In order to do things properly you need to learn and understand what you are dealing with. "Plunging" into something might look easy at the start but will get you into problems later when you need to understand *why* and *how* things are working.

This is not something unique to Postgres or databases in general. It's not even unique to software.
Learn what youare doing (or dealing with) is a "strategy" that applies to everything you do.

Do take the time to read the manuals - including the MySQL manual (because just "plunging" into MySQL simply doesn't work either)
It'll make you a lot more proficient in the long run.

Regards
Thomas

On reflection, I think what is needed is a handbook that features cut
and paste code to do the things with Postgres that people do today
with MySQL.

Such a handbook, featured as the first section of the documentation,
would take readers through the steps necessary to set up an online
shopping site, for example, with Postgres. Cut and paste code is
absolutely crucial to the success of such a document.

Make it easy. Make it easy. Our road in the yellow wood has to be
the one you can go down the easiest.

John

On Aug 6, 2010, at 1:39 PM, Phillip Smith wrote:

John Gage schrieb:

On reflection, I think what is needed is a handbook that features cut
and paste code to do the things with Postgres that people do today with
MySQL.

Everyone of my trainees want such thing - for databases, for other
programming-languages etc. It's the worst thing you can give them. The<
will copy, they will paste and they will understand nothing. Learning is
the way to understanding, not copying.

Greetings,
Torsten
--
http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8
verschiedenen Datenbanksystemen abstrahiert,
Queries von Applikationen trennt und automatisch die Query-Ergebnisse
auswerten kann.

I only said this to criticize it. And I agree completely with Thomas.

John

On Aug 6, 2010, at 2:09 PM, Thomas Kellerer wrote:

If I recall correctly William Shakespeare did a ton of cutting and
pasting. And he was not alone. My Fair Lady, one of the most
successful Broadway shows ever, contains whole sections from Shaw's
play.

We learn by imitation. I am not suggesting that once you cut and
paste you call it quits, but it is the only place to begin.

John

On Aug 6, 2010, at 3:13 PM, Torsten Zühlsdorff wrote:

I would also enquire whether one thinks that the examples should be
removed from the Postgres documentation for fear that they may be cut
and pasted into an application?

John

On Aug 6, 2010, at 3:13 PM, Torsten Zühlsdorff wrote:

On Aug 6, 2010, at 6:13 AM, Torsten Zühlsdorff wrote:

John Gage schrieb:

On reflection, I think what is needed is a handbook that features
cut and paste code to do the things with Postgres that people do
today with MySQL.

Everyone of my trainees want such thing - for databases, for other
programming-languages etc. It's the worst thing you can give them.
The< will copy, they will paste and they will understand nothing.
Learning is the way to understanding, not copying.

I couldn't disagree more. Presenting working code (at least snippets)
should continue to be a fundamental part of any documentation project.

As a first-time db programmer and 'casual' user of PostgreSQL, I read
Bruce Momjian's book to get started. I rely on the example code
presented in the current documentation to learn best practices,
compare against it to troubleshoot my code when it breaks, and provide
inspiration for elegant solutions to challenges I encounter.

I would further suggest that a QuickStart guide would be an ideal
addition to the current documentation efforts. Scanning a basic soup-
to-nuts solution can often answer fundamental questions more
efficiently than full-blown documentation can, especially when the
user is not already familiar with specific terminology to search for
in the index.

Regards,
Scott

On Fri, Aug 6, 2010 at 11:02 AM, Scott Frankel <frankel@circlesfx.com> wrote:

On Aug 6, 2010, at 6:13 AM, Torsten Zühlsdorff wrote:

John Gage schrieb:

On reflection, I think what is needed is a handbook that features cut and
paste code to do the things with Postgres that people do today with MySQL.

Everyone of my trainees want such thing - for databases, for other
programming-languages etc. It's the worst thing you can give them. The< will
copy, they will paste and they will understand nothing. Learning is the way
to understanding, not copying.

I couldn't disagree more.  Presenting working code (at least snippets)
should continue to be a fundamental part of any documentation project.

I agree. It's especially useful if you're dealing with folks who
already have a clue, but may not be 100% familiar with how SQL or a
particular language. I had a Perl cookbook back in the day that was
priceless when I was switching from C to Perl. I didn't just copy and
paste, but I did certainly learn a lot looking at other people's code.

The idea being discussed here is a CookBook and it's extremely useful.
The current manual has a lot of examples, and some of them are very
much cookbook style. I'm sure we could always use more.

On Friday 06 August 2010, Scott Marlowe elucidated thus:

Everyone of my trainees want such thing - for databases, for other
programming-languages etc. It's the worst thing you can give them.
The< will copy, they will paste and they will understand nothing.
Learning is the way to understanding, not copying.

I couldn't disagree more. �Presenting working code (at least
snippets) should continue to be a fundamental part of any
documentation project.

I agree. It's especially useful if you're dealing with folks who
already have a clue, but may not be 100% familiar with how SQL or a
particular language. I had a Perl cookbook back in the day that was
priceless when I was switching from C to Perl. I didn't just copy
and paste, but I did certainly learn a lot looking at other people's
code.

I'll add in a "me too" only to say that I am someone that learns best by
example. Reading about an API or function call is great, but I'll pick
it up faster, and understand it better, if you show me an example of it
in use (preferably multiple examples).

So, a "getting started" guide and/or cookbook would be great. Another
cool idea: a MySQL -> PostgreSQL migration guide (I'm sure there's
already one out there) that would show "To do *this* MySQL function in
PostgreSQL, use this function/feature/etc." A good example is
auto_increment -> serial. A comparison/contrast of permission would be
good too. I'm sure others can think of more examples.

So, that's my 2c.

j

--
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ �ID 0x73B13B6A

john, you're running up against a culture here, and trying to answer
the question: how to make a nerd cool? answer: it can't be done.

On Fri, Aug 6, 2010 at 1:38 PM, zach cruise <zachc1980@gmail.com> wrote:

john, you're running up against a culture here, and trying to answer
the question: how to make a nerd cool? answer: it can't be done.

I'm all in favor of a nice tutorial section in the docs. But I
certainly don't want pgsql docs to mimick the mysql docs method of
using a tutorial method for most of the beginner information. It's so
dang hard to find anything I want in the mysql docs because of it.
Once you're somewhat familiar with the db, having to slog through
pages of tutorial to find the bits you want is counterproductive. The
easy-peasy entry level mentality of the mysql docs works against
experienced users.

pgsql docs, OTOH, are much easier to trawl for the info I need, using
the top down layout that's so easy to use to find what you want.

On Fri, Aug 06, 2010 at 02:09:43PM -0600, Scott Marlowe wrote:

I'm all in favor of a nice tutorial section in the docs. But I
certainly don't want pgsql docs to mimick the mysql docs method of
using a tutorial method for most of the beginner information. It's so
dang hard to find anything I want in the mysql docs because of it.
Once you're somewhat familiar with the db, having to slog through
pages of tutorial to find the bits you want is counterproductive. The
easy-peasy entry level mentality of the mysql docs works against
experienced users.

+1

I spent half an hour today trying to find the various ways MySQL has
for controlling charsets. The TOC is unusable and even using the index
it can sometimes be very frustrating to find something. Postgres has
outstanding docs right now! It would be a shame to change that.

Tutorials would be good, but in a separate section of the site.

Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth

In my fondest moments, I consider myself a nerd, and when I do I think
I am completely cool.

On Aug 6, 2010, at 9:38 PM, zach cruise wrote:

On Fri, Aug 6, 2010 at 2:15 PM, Peter Bex <Peter.Bex@xs4all.nl> wrote:

On Fri, Aug 06, 2010 at 02:09:43PM -0600, Scott Marlowe wrote:

I'm all in favor of a nice tutorial section in the docs.  But I
certainly don't want pgsql docs to mimick the mysql docs method of
using a tutorial method for most of the beginner information.  It's so
dang hard to find anything I want in the mysql docs because of it.
Once you're somewhat familiar with the db, having to slog through
pages of tutorial to find the bits you want is counterproductive.  The
easy-peasy entry level mentality of the mysql docs works against
experienced users.

+1

I spent half an hour today trying to find the various ways MySQL has
for controlling charsets.  The TOC is unusable and even using the index
it can sometimes be very frustrating to find something.  Postgres has
outstanding docs right now!  It would be a shame to change that.

For an extra added bonus, show a click-path from the front page
mysql.com to the documentation. I gave up and just entered
mysql.com/documentation which kicked off the search engine and let me
click somewhere into the 5.1 docs. Yes I know they're on
dev.mysql.com but still, it feels like a total brochure site from the
front end.

On Fri, Aug 06, 2010 at 02:25:27PM -0600, Scott Marlowe wrote:

For an extra added bonus, show a click-path from the front page
mysql.com to the documentation. I gave up and just entered
mysql.com/documentation which kicked off the search engine and let me
click somewhere into the 5.1 docs. Yes I know they're on
dev.mysql.com but still, it feels like a total brochure site from the
front end.

I know :) They actually have TWO sites: mysql.com which is indeed
a commercial outlet where they try to sell you their commercial offering
and mysql.org which is geared toward developers. The manual is "only"
three clicks away on that site.

Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth