Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 8F8C92E0045 for ; Thu, 22 Nov 2007 03:44:52 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 62050-03 for ; Thu, 22 Nov 2007 03:44:40 -0400 (AST) Received: from web31815.mail.mud.yahoo.com (web31815.mail.mud.yahoo.com [68.142.206.168]) by postgresql.org (Postfix) with SMTP id 36FDC2E003E for ; Thu, 22 Nov 2007 03:44:48 -0400 (AST) Received: (qmail 21666 invoked by uid 60001); 22 Nov 2007 07:44:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=R7Ew2YwGSI2tvJikRTLy9He2uMs9bDCZKrSjvEATqNHkCyuYsOp082nft89rd9CWo2t848+ffHfPB/Hbjz1FPzwYwSBWVEtiJDrUpggPJWNGXNDr0R1y10ghQBFmYS6FUPdCzd1svvs5Xz/5RCy75H1BWTKJ0MMO9jvRkmG9ETQ=; X-YMail-OSG: ESM5eikVM1nzrNcQ5YdDQMqcrmmpITGFUidCV0hXj8ulJXoX7aqBN0bKlliAzFSCdXnKqS2tOQ-- Received: from [75.84.89.248] by web31815.mail.mud.yahoo.com via HTTP; Wed, 21 Nov 2007 23:44:47 PST X-Mailer: YahooMailWebService/0.7.158 Date: Wed, 21 Nov 2007 23:44:47 -0800 (PST) From: Richard Broersma Jr Subject: Bad Schema Design or Useful Trick? To: SQL Postgresql List Cc: General PostgreSQL List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <82640.215.qm@web31815.mail.mud.yahoo.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.211 tagged_above=0 required=5 tests=AWL=0.210, BAYES_50=0.001 X-Spam-Level: X-Archive-Number: 200711/1187 X-Sequence-Number: 124183 Below I've included sample table definitions for a vertically partitioned disjunctive table hierarchy. I wanted to point out the use of the composite primary key declaration that is applied to two columns that are clearly not a candidate key. However, using the badly defined primary key allows for referential integrity to nicely handle the de-normalization between the main table and sub tables that is inherent with this type of data model. Would using a primary key in this manner be a decision that I will regret in the long run? If so, can any explain why? The parent table is parts with the child table pumps and hardware. CREATE TABLE Parts ( part_nbr varchar( 100 ) UNIQUE NOT NULL, part_type varchar( 20 ) NOT NULL, unit_cost numeric(7,2) NOT NULL DEFAULT 0 CHECK( unit_cost >= 0 ), description text NOT NULL, CONSTRAINT parts_primary_key PRIMARY KEY ( part_nbr, part_type ), CONSTRAINT only_defined_part_types CHECK( part_type IN ( 'pump', 'bolt', 'nut'))); CREATE TABLE Pumps ( part_nbr varchar( 100 ) PRIMARY KEY, part_type varchar( 20 ) NOT NULL CHECK( part_type = 'pump' ), volumn real NOT NULL CHECK( volumn > 0 ), motorhp_size varchar( 4 ) NOT NULL REFERENCES Motortypes( motorhp_size), CONSTRAINT parts_foreign_key FOREIGN KEY ( part_nbr, part_type ) REFERENCES Parts( part_nbr, part_type) ON DELETE CASCADE ON UPDATE CASCADE); CREATE TABLE Hardware ( part_nbr varchar( 100 ) PRIMARY KEY, part_type varchar( 20 ) NOT NULL CHECK( part_type IN ( 'bolt', 'nut' ), thread_size varchar( 4 ) NOT NULL REFERENCES Threadtypes( Thread_size ), grading varchar( 4 ) NOT NULL REFERENCES Gradingtypes( grading ), CONSTRAINT parts_foreign_key FOREIGN KEY ( part_nbr, part_type ) REFERENCES Parts( part_nbr, part_type) ON DELETE CASCADE ON UPDATE CASCADE); Regards, Richard Broersma Jr.