Thread: The Tutorial(TM)
Kind people, I was looking over the Tutorial section, and noticed that Foreign Keys is in the "Advanced" section. I believe this is a mistake, and would like to patch up the difference. What files are involved in the source tree apart from doc/src/sgml/query.sgml and doc/src/sgml/query.sgml ? TIA :) Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 cell: +1 415 235 3778 Power over a man's subsistence is power over his will. Alexander Hamilton
David Fetter wrote: > Kind people, > > I was looking over the Tutorial section, and noticed that Foreign Keys > is in the "Advanced" section. I believe this is a mistake, and would > like to patch up the difference. What files are involved in the > source tree apart from doc/src/sgml/query.sgml and > doc/src/sgml/query.sgml ? > > TIA :) I think you just move the section and submit a patch. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Wed, Jan 07, 2004 at 09:13:47PM -0500, Bruce Momjian wrote: > David Fetter wrote: > > Kind people, > > > > I was looking over the Tutorial section, and noticed that Foreign > > Keys is in the "Advanced" section. I believe this is a mistake, > > and would like to patch up the difference. What files are > > involved in the source tree apart from doc/src/sgml/query.sgml and > > doc/src/sgml/query.sgml ? > > > > TIA :) > > I think you just move the section and submit a patch. Patching... BTW, src/tutorial/basics.source and src/tutorial/advanced.source also need patching for this. BTW2, as this is a pretty extensive rewrite, I'll put up a web page that shows how the patch would work :) Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 cell: +1 415 235 3778
David Fetter wrote: > I was looking over the Tutorial section, and noticed that Foreign > Keys is in the "Advanced" section. I believe this is a mistake, Why?
-On [20040108 07:32], Peter Eisentraut (peter_e@gmx.net) wrote: >Why? Because foreign keys are part of database design 101? -- Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ It does not require many words to speak the truth...
On Thu, Jan 08, 2004 at 08:52:29AM +0100, Jeroen Ruigrok/asmodai wrote: > -On [20040108 07:32], Peter Eisentraut (peter_e@gmx.net) wrote: > >Why? > Because foreign keys are part of database design 101? Yes. Expanding on that, putting FK's in "Advanced Features" gives the (IME always wrong) impression that they're optional. Chris Browne, could you give me a pointer to your patch so we don't step on each other's feet? Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 cell: +1 415 235 3778
Jeroen Ruigrok/asmodai wrote: > Because foreign keys are part of database design 101? Indeed, but the subject matter of chapter 2 of the tutorial is more like introduction to databases 099. Others may rightfully claim that transactions and views are also elementary parts of database application designs, but then there wouldn't be any advanced subjects left. I feel that there is a very useful dividing line between chapters 2 and 3: chapter 2 is about getting the data in and out, to give beginners a feeling that the database system is working, chapter 3 is about refining the data structures for higher convenience, maintainability, and integrity -- "design".
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. 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. Let's not overwhelm them right away.
On Thu, 2004-01-08 at 12:07, 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. > > 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. Let's not > overwhelm them right away. Perhaps it's simply the wrong title. "Design" in place of "Advanced Features" They're not advanced database features, but they aren't required learning until you're designing the environment rather than simply using the environment.
Peter Eisentraut wrote:
Foreign keys IMHO should be in a small chapter "About database design" or "Making sure your data is valid"
or something.
Triggers, rules, name spaces...Jeroen Ruigrok/asmodai wrote:Because foreign keys are part of database design 101?Indeed, but the subject matter of chapter 2 of the tutorial is more like introduction to databases 099. Others may rightfully claim that transactions and views are also elementary parts of database application designs, but then there wouldn't be any advanced subjects left.
Foreign keys IMHO should be in a small chapter "About database design" or "Making sure your data is valid"
or something.
I feel that there is a very useful dividing line between chapters 2 and 3: chapter 2 is about getting the data in and out, to give beginners a feeling that the database system is working, chapter 3 is about refining the data structures for higher convenience, maintainability, and integrity -- "design". ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
-- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
Peter Eisentraut <peter_e@gmx.net> writes:
> I feel that there is a very useful dividing line between chapters 2 and
> 3: chapter 2 is about getting the data in and out, to give beginners a
> feeling that the database system is working, chapter 3 is about
> refining the data structures for higher convenience, maintainability,
> and integrity -- "design".
Perhaps a reasonable compromise would be to divide the material into 3
chapters instead of 2 --- beginner, intermediate, advanced. Looking
at the existing TOC:
2. The SQL Language
2.1. Introduction
2.2. Concepts
2.3. Creating a New Table
2.4. Populating a Table With Rows
2.5. Querying a Table
2.6. Joins Between Tables
2.7. Aggregate Functions
2.8. Updates
2.9. Deletions
3. Advanced Features
3.1. Introduction
3.2. Views
3.3. Foreign Keys
3.4. Transactions
3.5. Inheritance
3.6. Conclusion
I'd be inclined to put aggregates, transactions, foreign keys, and views
into the "intermediate" category, leaving only inheritance as
"advanced". (Or maybe we should just drop inheritance from the tutorial.)
You could possibly even argue that joins are intermediate instead of
basic, although that's stretching it a bit.
I agree with Peter's point that the first thing to teach is how to get
data in and out.
regards, tom lane
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. Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 cell: +1 415 235 3778
Christopher Browne <cbbrowne@acm.org> wrote: > 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. Good point. How about this, then? For the table create scripts at the beginning, I'll put in FK's with a pointer to the DB design section, and just go with 'em from there. That way, people get used to seeing and doing things the right way, even if they don't understand them right off the bat. > 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. Excellent :) Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 cell: +1 415 235 3778 Liberty is inseparable from social justice, and those who dissociate them, sacrificing the first with the purpose of attaining the second more quickly, are the true barbarians of our time. Mario Vargas Llosa
Clinging to sanity, david@fetter.org (David Fetter) mumbled into her beard:
> Chris Browne, could you give me a pointer to your patch so we don't
> step on each other's feet?
It was posted on the patches list on 2003-12-29...
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://cbbrowne.com/info/languages.html
It's always darkest just before it gets pitch black.
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.
In an attempt to throw the authorities off his trail, pgman@candle.pha.pa.us (Bruce Momjian) transmitted:
> David Fetter wrote:
>> Kind people,
>>
>> I was looking over the Tutorial section, and noticed that Foreign Keys
>> is in the "Advanced" section. I believe this is a mistake, and would
>> like to patch up the difference. What files are involved in the
>> source tree apart from doc/src/sgml/query.sgml and
>> doc/src/sgml/query.sgml ?
>>
>> TIA :)
>
> I think you just move the section and submit a patch.
I submitted a patch on the "advanced" section to the patches list a
bit over a week ago; haven't seen anything flow through yet...
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://cbbrowne.com/info/sap.html
Rules of the Evil Overlord #35. "I will not grow a goatee. In the old
days they made you look diabolic. Now they just make you look like a
disaffected member of Generation X." <http://www.eviloverlord.com/>
On Thursday 08 January 2004 22:44, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > I feel that there is a very useful dividing line between chapters 2 and > > 3: chapter 2 is about getting the data in and out, to give beginners a > > feeling that the database system is working, chapter 3 is about > > refining the data structures for higher convenience, maintainability, > > and integrity -- "design". > > Perhaps a reasonable compromise would be to divide the material into 3 > chapters instead of 2 --- beginner, intermediate, advanced. Looking > at the existing TOC: Rather than putting a rating on a section, I would say let's leave the normal and advanced section as it is and add another section which illustrates "applying" postgresql/RDBMS to solve real problem. e.g. illustrate how do you normalize and maintain foreign keys to integrity. Then add cascade clause. Then views for denormalizing it. If we illustrate a real world situation, it will be easy to grasp even if it spans multiple concepts. And at the end of it cross reference to details pages at the end of each illustration. That way it will be bit more handholding rather than trying to gulp various theoretical pieces. > 2. The SQL Language > 2.1. Introduction > 2.2. Concepts > 2.3. Creating a New Table > 2.4. Populating a Table With Rows > 2.5. Querying a Table > 2.6. Joins Between Tables > 2.7. Aggregate Functions > 2.8. Updates > 2.9. Deletions > 3. Advanced Features > 3.1. Introduction > 3.2. Views > 3.3. Foreign Keys > 3.4. Transactions > 3.5. Inheritance > 3.6. Conclusion I am going to save that list or search later in archives...:-) Plan to work on it if I get time. Just a thought.. Shridhar
On Thu, 8 Jan 2004, David Fetter wrote: > > Christopher Browne <cbbrowne@acm.org> wrote: > > 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. > > Good point. How about this, then? For the table create scripts at > the beginning, I'll put in FK's with a pointer to the DB design > section, and just go with 'em from there. That way, people get used > to seeing and doing things the right way, even if they don't > understand them right off the bat. > > > 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. > > Excellent :) > > Cheers, > D > As a person who is not a PostgreSQL guru or a database guru, or who has worked on databases with the numbers of tables in the hundreds or thousands, but, a person with (relatively) basic database skills, and who knows of relational database design and the need for normalisation, I suggest that wariness of cross-references, etc, should exist. I suggest that Foreign Keys should be included as a subsection to creating tables, and to altering tables, which are the places, to me, in which they belong. When I create a table, or am learning to do it with PostgreSQL, having to follow cross-references, to find how to do what should be a relatively simple and elementary task, would make the process unnecessarily cumbersome, and would be a disincentive to use foreign keys. I believe that a person creating a database, and the tables, should have, at that stage, the information required for the components; primary keys, foreign keys, etc, so that the person can create the database and get it properly operational, before entering data. A proverb exists; "Do it once - do it properly", and, if a person does it properly from the start, the process is much more efficient. What is the point in using PostgreSQL to build a flat-file database, then tearing it apart, to implement elementary relational concepts like foreign keys? And, if a person has to go looking elsewhere, via cross-references, for concepts like foreign keys, they may fall by the wayside, and, may be reagarded as unimportant, as they are not included in the part for creating the tables. Thus, I suggest that the sections should be CREATE TABLE and ALTER TABLE, and they should include subsections like PRIMARY KEYS and FOREIGN KEYS, so that the person can do it properly from the start, and, not be discouraged from using foreign keys, by the use of cross-referencing. After all, you must consider the level for whom the tutorials are to be written; are they for gurus, like (some of) you, or, for basic level people, like me? -- Bret Busby Armadale West Australia .............. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 ....................................................
On Sun, 11 Jan 2004, Bret Busby wrote: > > As a person who is not a PostgreSQL guru or a database guru, or who > has worked on databases with the numbers of tables in the hundreds > or thousands, but, a person with (relatively) basic database skills, and > who knows of relational database design and the need for normalisation, > I suggest that wariness of cross-references, etc, should exist. > > I suggest that Foreign Keys should be included as a subsection to > creating tables, and to altering tables, which are the places, to me, in > which they belong. When I create a table, or am learning to do it with > PostgreSQL, having to follow cross-references, to find how to do what > should be a relatively simple and elementary task, would make the > process unnecessarily cumbersome, and would be a disincentive to use > foreign keys. > > I believe that a person creating a database, and the tables, should > have, at that stage, the information required for the components; > primary keys, foreign keys, etc, so that the person can create the > database and get it properly operational, before entering data. > > A proverb exists; "Do it once - do it properly", and, if a person does > it properly from the start, the process is much more efficient. > > What is the point in using PostgreSQL to build a flat-file database, > then tearing it apart, to implement elementary relational concepts like > foreign keys? > > And, if a person has to go looking elsewhere, via cross-references, for > concepts like foreign keys, they may fall by the wayside, and, may be > reagarded as unimportant, as they are not included in the part for > creating the tables. > > Thus, I suggest that the sections should be CREATE TABLE and ALTER > TABLE, and they should include subsections like PRIMARY KEYS and FOREIGN > KEYS, so that the person can do it properly from the start, and, not be > discouraged from using foreign keys, by the use of cross-referencing. > > After all, you must consider the level for whom the tutorials are to be > written; are they for gurus, like (some of) you, or, for basic level > people, like me? > > Oh, and, after reading subsequent messages in the thread "How to show table structure", specifically the message posted by Kumar, I also further suggest that the method of showing the table structure, be included at the end of the section CREATE TABLE, with the instruction/suggestion to use it to verify the structure of the table that has been created. Whilst (some of) you may regard that as advanced level stuff, to me, it appears to me, to be a necessary means of verifying the action(s). And, a suggestion to use the method, to verify changes, should be used at the end of the setcion ALTER TABLE, so that the developer/student/whatever can check that what the person has done, has been successful. -- Bret Busby Armadale West Australia .............. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 ....................................................
>2. The SQL Language > 2.1. Introduction > 2.2. Concepts > 2.3. Creating a New Table > 2.4. Populating a Table With Rows > 2.5. Querying a Table > 2.6. Joins Between Tables > 2.7. Aggregate Functions > 2.8. Updates > 2.9. Deletions >3. Advanced Features > 3.1. Introduction > 3.2. Views > 3.3. Foreign Keys > 3.4. Transactions > 3.5. Inheritance > 3.6. Conclusion > >I'd be inclined to put aggregates, transactions, foreign keys, and views >into the "intermediate" category, leaving only inheritance as >"advanced". (Or maybe we should just drop inheritance from the tutorial.) >You could possibly even argue that joins are intermediate instead of >basic, although that's stretching it a bit. > >I agree with Peter's point that the first thing to teach is how to get >data in and out. > > > You could add triggers, rules into advanced features... You could also break joins up so that when talking about outer, left etc... it goes into advanced but basic "join on" or natural joins are in intermediate. J > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 4: Don't 'kill -9' the postmaster > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
"tgl@sss.pgh.pa.us (Tom Lane)" wrote in comp.databases.postgresql.docs:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> I feel that there is a very useful dividing line between chapters 2 and
>> 3: chapter 2 is about getting the data in and out, to give beginners a
>> feeling that the database system is working, chapter 3 is about
>> refining the data structures for higher convenience, maintainability,
>> and integrity -- "design".
>
> Perhaps a reasonable compromise would be to divide the material into 3
> chapters instead of 2 --- beginner, intermediate, advanced. Looking
> at the existing TOC:
[sNip]
I think this is a good suggestion.
To add to this, within the actual content I think it would also be
good to reference the more advanced areas when appropriate. For example,
at the end of the "creating tables" section could be included:
See also: Views (advanced)
See also: Foreign keys (intermediate)
--
Randolf Richardson - rr@8x.ca
Vancouver, British Columbia, Canada
"We are anti-spammers. You will confirm
subscriptions. Resistance is futile."
Please do not eMail me directly when responding
to my postings in the newsgroups.