Re: [GENERAL] Is my MySQL Gaining ?

On Dec 29, 2003, at 12:15, Tony wrote:

> I already had in the first post I replied to,  but at the risk of
> sounding redundant, I'll say it again.
>
> Views:  When I came to PG I didn't know what they were, saw no point
> to them (still don't) why do you need a function to provide details of
> a query when a more complicated query gives the same data?  Are they
> designed for people who don't like to type long queries?

This is a standard database concept. You can do lots of things with
Views. For example, you can create a subview of a table that only
reveals a few columns and provide access to that view to a specific
group of people who can't see the whole table. You can also use them
as an abstraction layer for applications (i.e. we have a DB guy who
makes minor schema changes regularly and maintains the actual queries
our application uses without us necessarily having to know).

> Stored Procedures: Sounds good in principle, but in what ways can I
> benefit most (I understand this now) at the time of moving to PG, I
> couldn't see the difference between writing my code in an a Stored
> Proc or an API.

This is a standard database concept. They're useful for triggers
among other things. We don't use them a lot in our application
anymore, but they can be useful if there's a lot of complicated DB
interaction required for a specific thing to occur when it doesn't
require a great deal of input.

> Triggers: make perfect sense now, but didn't used to when I didn't
> know what they were.

Right, a standard database concept.

> This isn't definitive list but more of a flavour of the obstacles I
> hit when I first met PG.  If I hadn't persevered (and many may not)
> I'd have ended up with a PG server full of DBs designed and built as
> if they were on a MySQL server.
>
> Yes, the topics are covered fleetingly in the tutorial, but do such
> important topics only warrant 3 pages of text between the lot of
> them?  It's great that the subjects are present, but it seems to be in
> more of a kind of "Whilst We're on the Subject of Databases" kind of
> passing comment.
>
> Maybe I'm asking for the Moon on a Stick, but it didn't feel like I
> was :)

The problem you're describing isn't ``how can we provide documentation
that helps people understand postgres better,'' but ``how can we
provide documentation to teach people database concepts.''

It might be nice to provide a really nice SQL and RDBMS concept
reference, but it would be beyond the scope of product documentation
(somewhat).

Perhaps another documentation set for unteaching mySQL might be nice
as well. They're taking care of some of that themselves (by
implementing a lot of the things they used to say were unimportant
crutches for lazy programmers), but a lot of it still resonates. I get
annoyed every time I read someone suggesting that transactions aren't
required for most applications, or that subqueries are for lazy people
who can't do loops in code or whatever.

--
SPY My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin(at)spy(dot)net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________