From: Christopher Browne <cbbrowne@acm.org>
To: pgsql-docs@postgresql.org
Subject: Re: The Tutorial(TM)
Date: Thu, 08 Jan 2004 14:15:47 -0500
Message-ID: <m3k74245gc.fsf@wolfe.cbbrowne.com> (raw)
References: <TyudnZdaUc0gMWGiXTWc-g@speakeasy.net>
<20040108075229.GE85110@nexus.ninth-circle.org>
<20040108123937.GU24788@fetter.org>
<200401081807.13777.peter_e@gmx.net>
<20040108173544.GY24788@fetter.org>
Oops! david@fetter.org (David Fetter) was seen spray-painting on a wall:
> On Thu, Jan 08, 2004 at 06:07:13PM +0100, Peter Eisentraut wrote:
>> David Fetter wrote:
>> > Expanding on that, putting FK's in "Advanced Features" gives the
>> > (IME always wrong) impression that they're optional.
>>
>> They *are* optional.
>
> I disagree.
>
>> The first chapter is about getting the data in and out. That is not
>> optional for using a database. Transactions, views, foreign keys,
>> primary keys even, and everything else that some people think is
>> essential for a "real" database are in fact optional.
>> Remember that the tutorial is intended for people starting from
>> zero.
>
> No, they're not optional. If people see how it's done right, starting
> from zero, they will not then develop bad habits that have to be
> un-learned.
>
>> Let's not overwhelm them right away.
>
> I don't think this will be overwhelming.
When some Pointy-Haired Type has some ridiculously large list of
things that they say are all "top priorities," that implies that all
are of equally _LOW_ priority.
If it's all treated as being equally important, then it is fair to say
that it's all UNIMPORTANT.
I rather like Tom Lane's suggestion that it makes sense to split into
_three_ sections:
1. Rudimentary queries, where novices figure out the basics of
SELECT, INSERT, DELETE, UPDATE. Perhaps with simple joins.
2. Intermediate queries, where more complex joins, views,
transactions, subselects, some mention of vacuum/analyze/explain
and such, are presented.
3. The "advanced" part might instead get called "Designing
Databases," and present foreign keys, stored procedures,
triggers, and such.
Foreign keys would _naturally_ flow into the section that is on
design, as they are a "design" matter.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne; rate me
http://www.ntlug.org/~cbbrowne/wp.html
All bleeding stops...eventually.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: cbbrowne@acm.org
Subject: Re: The Tutorial(TM)
In-Reply-To: <m3k74245gc.fsf@wolfe.cbbrowne.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox