From rudi@oasis.net.au Tue Jun 24 05:19:28 2003 X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.193]) by svr1.postgresql.org (Postfix) with ESMTP id 40BB630F8A8 for ; Tue, 24 Jun 2003 05:19:28 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (svr1.postgresql.org [64.117.224.193]) (amavisd-new, port 10024) with ESMTP id 20371-10 for ; Tue, 24 Jun 2003 02:19:17 -0300 (ADT) Received: from water.oasis.net.au (water.oasis.net.au [210.8.139.2]) by svr1.postgresql.org (Postfix) with ESMTP id 8E80730F88D for ; Tue, 24 Jun 2003 02:19:16 -0300 (ADT) Received: from oasis.net.au (guardian [210.8.139.5]) by water.oasis.net.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id PAA24969 for ; Tue, 24 Jun 2003 15:35:36 +1000 X-Authentication-Warning: water.oasis.net.au: Host guardian [210.8.139.5] claimed to be oasis.net.au Message-ID: <3EF7DF74.40700@oasis.net.au> Date: Tue, 24 Jun 2003 15:19:48 +1000 From: Rudi Starcevic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-sql@postgresql.org Subject: Database design - AGAIN Content-Type: multipart/alternative; boundary="------------030307000701020308000904" X-Spam-Status: No, hits=2.2 tagged_above=0.0 required=5.0 tests=HTML_10_20, HTML_MESSAGE, UPPERCASE_25_50, USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG, X_AUTH_WARNING X-Spam-Level: ** X-Archive-Number: 200306/278 X-Sequence-Number: 14036 This is a multi-part message in MIME format. --------------030307000701020308000904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Sorry - I make some typo's - here is the question again. I have a Spread Sheet which I need to make a searchable directory out of. I'm in two minds on a couple things so I thought I'd ask. I"m not sure whether to have on larger table or 2 smaller one with a join table. This is a trimmed down version of the data. The directory is of Camping grounds/parks. Here is a sample of the fields: Park Name Info Kiosk infokiosk tent caravan toilets wheelchair water shower telephone One large table may look like: CREATE TABLE grounds ( id serial PRIMARY KEY, parkname varchar(120), infokiosk bool NOT NULL, tent bool NOT NULL, caravan bool NOT NULL, toilets bool NOT NULL, wheelchair bool NOT NULL, water bool NOT NULL, shower bool NOT NULL, telephone bool NOT NULL ); Two smaller tables with a join table may look like: CREATE TABLE grounds ( gid serial PRIMARY KEY, parkname varchar(120) ); CREATE TABLE features ( fid serial PRIMARY KEY, feature varchar NOT NULL ); INSERT INTO features ( feature ) VALUES ( 'infokiosk' ); INSERT INTO features ( feature ) VALUES ( ' tent' ); INSERT INTO features ( feature ) VALUES ( ' caravan' ); INSERT INTO features ( feature ) VALUES ( ' toilets' ); INSERT INTO features ( feature ) VALUES ( ' wheelchair' ); INSERT INTO features ( feature ) VALUES ( ' water' ); INSERT INTO features ( feature ) VALUES ( ' shower' ); INSERT INTO features ( feature ) VALUES ( ' telephone' ); ); -- join table CREATE TABLE grounds_features ( gid int4 REFERENCES grounds ON UPDATE CASCADE ON DELETE CASCADE NOT NULL, fid int4 REFERENCES features ON UPDATE CASCADE ON DELETE CASCADE NOT NULL ); For this task, a searchable directory, which design would be better. In know the second is more flexible as new features can be added but I have very limited time and I think the one larger table design would be quicker to build. The front end will be either ColdFusion or PHP - I haven't decided yet. Thank you kindly Best regards Rudi. --------------030307000701020308000904 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi,

Sorry - I make some typo's - here is the question again.

I have a Spread Sheet which I need to make a searchable directory out of.
I'm in two minds on a couple things so I thought I'd ask.

I"m not sure whether to have on larger table or 2 smaller one with a join table.
This is a trimmed down version of the data.
The directory is of Camping grounds/parks.

Here is a sample of the fields:
Park Name
Info Kiosk
infokiosk
tent
caravan
toilets
wheelchair
water
shower
telephone

One large table may look like:

CREATE TABLE grounds
(
id serial PRIMARY KEY,
parkname varchar(120),
infokiosk bool NOT NULL,
tent bool NOT NULL,
caravan bool NOT NULL,
toilets bool NOT NULL,
wheelchair bool NOT NULL,
water bool NOT NULL,
shower bool NOT NULL,
telephone bool NOT NULL
);

Two smaller tables with a join table may look like:

CREATE TABLE grounds
(
gid serial PRIMARY KEY,
parkname varchar(120)
);

CREATE TABLE features
(
fid serial PRIMARY KEY,
feature varchar NOT NULL
);
INSERT INTO features ( feature ) VALUES ( 'infokiosk' );
INSERT INTO features ( feature ) VALUES ( ' tent' );
INSERT INTO features ( feature ) VALUES ( ' caravan' );
INSERT INTO features ( feature ) VALUES ( ' toilets' );
INSERT INTO features ( feature ) VALUES ( ' wheelchair' );
INSERT INTO features ( feature ) VALUES ( ' water' );
INSERT INTO features ( feature ) VALUES ( ' shower' );
INSERT INTO features ( feature ) VALUES ( ' telephone' );
);

-- join table
CREATE TABLE grounds_features
(
gid int4 REFERENCES grounds ON UPDATE CASCADE ON DELETE CASCADE NOT NULL,
fid int4 REFERENCES features ON UPDATE CASCADE ON DELETE CASCADE NOT NULL
);

For this task, a searchable directory, which design would be better.
In know the second is more flexible as new features can be added but I have very limited time and
I think the one larger table design would be quicker to build.

The front end will be either ColdFusion or PHP - I haven't decided yet.

Thank you kindly

Best regards
Rudi.








--------------030307000701020308000904-- From josh@agliodbs.com Tue Jun 24 15:26:58 2003 X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.193]) by svr1.postgresql.org (Postfix) with ESMTP id 1A1CD30F799 for ; Tue, 24 Jun 2003 15:26:58 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (svr1.postgresql.org [64.117.224.193]) (amavisd-new, port 10024) with ESMTP id 32786-04 for ; Tue, 24 Jun 2003 12:26:47 -0300 (ADT) Received: from davinci.ethosmedia.com (unknown [209.10.40.251]) by svr1.postgresql.org (Postfix) with ESMTP id 3C2CB30F6C0 for ; Tue, 24 Jun 2003 12:26:47 -0300 (ADT) Received: from [63.195.55.98] (HELO spooky) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.0.2) with ESMTP id 3149399; Tue, 24 Jun 2003 08:26:53 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Josh Berkus Organization: Aglio Database Solutions To: Rudi Starcevic , pgsql-sql@postgresql.org Subject: Re: Database design - AGAIN Date: Tue, 24 Jun 2003 08:25:57 -0700 User-Agent: KMail/1.4.3 References: <3EF7DF74.40700@oasis.net.au> In-Reply-To: <3EF7DF74.40700@oasis.net.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200306240825.57350.josh@agliodbs.com> X-Archive-Number: 200306/282 X-Sequence-Number: 14040 Rudi, > For this task, a searchable directory, which design would be better. > In know the second is more flexible as new features can be added but I > have very limited time and > I think the one larger table design would be quicker to build. Sounds like you already have a clear grasp of the situation. Here's one more question to ask yourself: how long will this app be around? If the answer is "no more than 3 months, probably less", do it the most expedient way. If the answer is "6 months to indefinitely", do it the normalized way -- eventually, either you or your successor will need the flexibility as the users demand new features. If you are an employee, this is a no-brainer ... it is 90% likely that even if this is a temporary measure you will still be maintaining it 2 years from now, and will thank yourself if you built it "right" in the first place. Unless, of course, you are a consultant and your client is paying you $500 flat fee, in which case do it whatever way is fastest, but make sure your client knows that they are not getting an expandable product. > The front end will be either ColdFusion or PHP - I haven't decided yet. See what I said about expediency above. My web guru, who is an expert in both PHP and Cold Fusion, would be delighted to never use Cold Fusion again. So that's one expert opinion. And don't forget the license fees. -- Josh Berkus Aglio Database Solutions San Francisco From jgardner@jonathangardner.net Tue Jun 24 15:38:23 2003 X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.193]) by svr1.postgresql.org (Postfix) with ESMTP id 8766230F963 for ; Tue, 24 Jun 2003 15:38:23 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (svr1.postgresql.org [64.117.224.193]) (amavisd-new, port 10024) with ESMTP id 32786-08 for ; Tue, 24 Jun 2003 12:38:13 -0300 (ADT) Received: from irko.smoothcorp.com (unknown [208.49.241.41]) by svr1.postgresql.org (Postfix) with ESMTP id DE7A830F958 for ; Tue, 24 Jun 2003 12:38:12 -0300 (ADT) Received: from jgardner.ifloor.com ([10.0.1.63]) by irko.smoothcorp.com with esmtp (Exim 4.12) id 19Ups2-0003tH-00; Tue, 24 Jun 2003 08:38:10 -0700 Received: from jgardner.ifloor.com (localhost.localdomain [127.0.0.1]) by jgardner.ifloor.com (8.12.8/8.12.8) with ESMTP id h5OFcBHK007376; Tue, 24 Jun 2003 08:38:11 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by jgardner.ifloor.com (8.12.8/8.12.8/Submit) id h5OFcAJQ007374; Tue, 24 Jun 2003 08:38:10 -0700 From: Jonathan Gardner To: Rudi Starcevic , pgsql-sql@postgresql.org Subject: Re: Database design - AGAIN Date: Tue, 24 Jun 2003 08:38:04 -0700 User-Agent: KMail/1.5 References: <3EF7DF74.40700@oasis.net.au> In-Reply-To: <3EF7DF74.40700@oasis.net.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200306240838.09929.jgardner@jonathangardner.net> X-SA-Exim-Rcpt-To: rudi@oasis.net.au, pgsql-sql@postgresql.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Archive-Number: 200306/283 X-Sequence-Number: 14041 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 23 June 2003 22:19, Rudi Starcevic wrote: > I"m not sure whether to have on larger table or 2 smaller one with a > join table. Theory says you are better off with the join tables. Practical reality agre= es=20 with this. It takes a bit more work to write your select statements, but th= e=20 data is better for at least these two reasons: 1) You won't have a lot of empty columns. 2) You will be able to add, rename, and remove features pretty easily. There are more reasons, but they are not immediately obvious to the untrain= ed=20 DBA. (Words like "data integrity" and "data consistency" start to mean thin= gs=20 when you become trained.) With that said, it sounds like you are really intermediate with database=20 design. If you were a beginner, and if you barely understood what a table= =20 was, (and if you were the guy who would be using it all the time,) I would= =20 probably suggest you use the former method. It will work pretty well until= =20 you want to add more features or until you start worrying about your databa= se=20 size. At that point, I would explain how and why to use joins, and how to= =20 convert your data over to the new design. - --=20 Jonathan Gardner (was jgardn@alumni.washington.edu) Live Free, Use Linux! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE++HBcWgwF3QvpWNwRAgjPAJ48syjGQahHvU4zi38WVheFbVFC5ACfQw5S 0qO67ZB2ToO4zFJKoh5GtrU=3D =3DPnFr -----END PGP SIGNATURE----- From rudi@oasis.net.au Tue Jun 24 21:59:05 2003 X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.193]) by svr1.postgresql.org (Postfix) with ESMTP id 29CBF30FA60 for ; Tue, 24 Jun 2003 21:59:05 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (svr1.postgresql.org [64.117.224.193]) (amavisd-new, port 10024) with ESMTP id 80143-07 for ; Tue, 24 Jun 2003 18:58:54 -0300 (ADT) Received: from water.oasis.net.au (water.oasis.net.au [210.8.139.2]) by svr1.postgresql.org (Postfix) with ESMTP id 3C8EF30FA43 for ; Tue, 24 Jun 2003 18:58:52 -0300 (ADT) Received: from oasis.net.au (localhost [127.0.0.1]) by water.oasis.net.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id IAA02145 for ; Wed, 25 Jun 2003 08:15:03 +1000 X-Authentication-Warning: water.oasis.net.au: Host localhost [127.0.0.1] claimed to be oasis.net.au From: "Rudi Starcevic" To: pgsql-sql@postgresql.org Subject: Re: Database design - AGAIN Date: Wed, 25 Jun 2003 08:15:03 +1000 Message-Id: <20030624221503.M77696@oasis.net.au> In-Reply-To: <200306240838.09929.jgardner@jonathangardner.net> References: <3EF7DF74.40700@oasis.net.au> <200306240838.09929.jgardner@jonathangardner.net> X-Mailer: Open WebMail X-OriginatingIP: 203.220.112.217 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Archive-Number: 200306/284 X-Sequence-Number: 14042 Josh, Jonathan .. Thanks for your replies. You mail was exactly what I was hoping for - your best practise opinion. I do have a grasp of the theory involved with SQL but your input on those 'other' constraints like time, language, longevity etc was just what I was interested in. I'll be using smaller tables with appropriate join tables and PHP. Just for interests sake I'll be using Dia to plan the schema. I prefer to use the UML drawing tools instead of the ER ones. Thank you. Best regards Rudi. > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 23 June 2003 22:19, Rudi Starcevic wrote: > > I"m not sure whether to have on larger table or 2 smaller one with a > > join table. > > Theory says you are better off with the join tables. Practical > reality agrees with this. It takes a bit more work to write your > select statements, but the data is better for at least these two reasons: > 1) You won't have a lot of empty columns. > 2) You will be able to add, rename, and remove features pretty easily. > There are more reasons, but they are not immediately obvious to the > untrained DBA. (Words like "data integrity" and "data consistency" > start to mean things when you become trained.) > > With that said, it sounds like you are really intermediate with > database design. If you were a beginner, and if you barely > understood what a table was, (and if you were the guy who would be > using it all the time,) I would probably suggest you use the former > method. It will work pretty well until you want to add more features > or until you start worrying about your database size. At that point, > I would explain how and why to use joins, and how to convert your > data over to the new design. > > - -- > Jonathan Gardner > (was jgardn@alumni.washington.edu) > Live Free, Use Linux! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > > iD8DBQE++HBcWgwF3QvpWNwRAgjPAJ48syjGQahHvU4zi38WVheFbVFC5ACfQw5S > 0qO67ZB2ToO4zFJKoh5GtrU= > =PnFr > -----END PGP SIGNATURE----- > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org From mike@nachbaur.com Tue Jun 24 23:02:49 2003 X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.193]) by svr1.postgresql.org (Postfix) with ESMTP id 6680130FA6D for ; Tue, 24 Jun 2003 23:02:49 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (svr1.postgresql.org [64.117.224.193]) (amavisd-new, port 10024) with ESMTP id 94390-03 for ; Tue, 24 Jun 2003 20:02:39 -0300 (ADT) Received: from dbdevel.sunwave.net (h64-141-16-15.sunwave.net [64.141.16.15]) by svr1.postgresql.org (Postfix) with ESMTP id A963B30F982 for ; Tue, 24 Jun 2003 20:02:38 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dbdevel.sunwave.net (Postfix) with ESMTP id 40C20178008; Tue, 24 Jun 2003 19:02:33 -0400 (EDT) From: Michael A Nachbaur To: "Rudi Starcevic" , pgsql-sql@postgresql.org Subject: Re: Database design - AGAIN Date: Tue, 24 Jun 2003 16:02:33 -0700 User-Agent: KMail/1.5 References: <3EF7DF74.40700@oasis.net.au> <200306240838.09929.jgardner@jonathangardner.net> <20030624221503.M77696@oasis.net.au> In-Reply-To: <20030624221503.M77696@oasis.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306241602.33082.mike@nachbaur.com> X-Archive-Number: 200306/285 X-Sequence-Number: 14043 On Tuesday 24 June 2003 03:15 pm, Rudi Starcevic wrote: > I'll be using smaller tables with appropriate join tables and PHP. > Just for interests sake I'll be using Dia to plan the schema. > I prefer to use the UML drawing tools instead of the ER ones. Off topic, but if you're using KDE you might want to look into Umbrello. It's a UML modelling app for KDE, and is quite good, even has the beginnings of code generation (for SQL, Perl, Java, etc). -- Michael A Nachbaur From josh@agliodbs.com Wed Jun 25 19:22:23 2003 X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.193]) by svr1.postgresql.org (Postfix) with ESMTP id 78B7030FC23 for ; Wed, 25 Jun 2003 19:22:23 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (svr1.postgresql.org [64.117.224.193]) (amavisd-new, port 10024) with ESMTP id 86773-09 for ; Wed, 25 Jun 2003 16:22:13 -0300 (ADT) Received: from davinci.ethosmedia.com (unknown [209.10.40.251]) by svr1.postgresql.org (Postfix) with ESMTP id C138D30E7E7 for ; Wed, 25 Jun 2003 16:22:12 -0300 (ADT) Received: from [63.195.55.98] (HELO spooky) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.0.2) with ESMTP id 3153464; Wed, 25 Jun 2003 12:22:24 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Josh Berkus Organization: Aglio Database Solutions To: "Rudi Starcevic" , pgsql-sql@postgresql.org Subject: Re: Database design - AGAIN Date: Wed, 25 Jun 2003 12:21:17 -0700 User-Agent: KMail/1.4.3 References: <3EF7DF74.40700@oasis.net.au> <200306240838.09929.jgardner@jonathangardner.net> <20030624221503.M77696@oasis.net.au> In-Reply-To: <20030624221503.M77696@oasis.net.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200306251221.17890.josh@agliodbs.com> X-Archive-Number: 200306/291 X-Sequence-Number: 14049 Rudi, > I'll be using smaller tables with appropriate join tables and PHP. > Just for interests sake I'll be using Dia to plan the schema. > I prefer to use the UML drawing tools instead of the ER ones. I still use a simple flowcharting program to plan my databases. Never saw the value in UML, mainly because of the confusing terminology. But if it works for you, go for it. -- Josh Berkus Aglio Database Solutions San Francisco