Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id E02C69FBADC for ; Fri, 15 Jun 2007 13:43:01 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 62560-04-2 for ; Fri, 15 Jun 2007 13:42:57 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from web33309.mail.mud.yahoo.com (web33309.mail.mud.yahoo.com [68.142.206.124]) by postgresql.org (Postfix) with SMTP id 42B749FB3A6 for ; Fri, 15 Jun 2007 13:42:57 -0300 (ADT) Received: (qmail 35941 invoked by uid 60001); 15 Jun 2007 16:42:56 -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:MIME-Version:Content-Type:Message-ID; b=tLSkm9h3xOnx3mexgaz3d6LIEIZtDBCVnNlIaY0W+nYQqp7eQEAP6p1JcWQST+diXEyZFCTU7A+uCMs5yRr7CFJnydglExOE3t5sff2Av2cm/vfUctYPaL7Yju7omxpAkIoBrn317BEID5s3Mc3x/xycfUQAL/OIoMohvQ5YTPo=; X-YMail-OSG: Ath7E28VM1ltH3eYX9qlydcUjeui6BZwcDwV0YGQMA.nzkTrk32YjEboi3JJKcFUsF8ws0Xh4ECTY1NbeZEKGWWzh3p0Cw2SoXI5cob7nAy7TIqzaiVpkFzNkJH7uQ-- Received: from [68.142.201.145] by web33309.mail.mud.yahoo.com via HTTP; Fri, 15 Jun 2007 09:42:56 PDT X-Mailer: YahooMailRC/651.29 YahooMailWebService/0.7.41.16 Date: Fri, 15 Jun 2007 09:42:56 -0700 (PDT) From: Subject: Re: Organization of tables To: Salman Tahir , pgsql-sql@postgresql.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Message-ID: <186195.35881.qm@web33309.mail.mud.yahoo.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=4.131 tagged_above=0 required=5 tests=BAYES_40=-0.185, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, DNS_FROM_RFC_WHOIS=1.447, NO_REAL_NAME=0.961 X-Spam-Level: **** X-Archive-Number: 200706/112 X-Sequence-Number: 28602 Hi Salman, will this achieve your needs? peptide_table primary_key name (ie, Peptide1, Peptide2) mass fragment_table primary_key name (ie, A, Q, K) link_table primary_key peptide_id fragment_id it gives you easy access to peptide mass and it allows you to link multiple fragments to individual peptides. if the peptide mass ultimately comes form the fragments, you could enter the mass value there and then have the db do a calculation to sum up the masses for a given peptide. sorry if i've misunderstood you problem. best of luck, oe1 ----- Original Message ---- From: Salman Tahir To: pgsql-sql@postgresql.org Sent: Thursday, June 14, 2007 4:21:06 AM Subject: [SQL] Organization of tables Hi, I have a question regarding the organization of a table I want to create in my database: I have the following setup: Table Fragments (simplified example): Primary key = {mass} Approach (1) fragment | mass (of fragment) | peptide ---------------+--------------------------------+-------------- A | x | Peptide1, Peptide2 Q | y | Peptide1 K | z | Peptide 2, Peptide3 The idea here is that a peptide can be composed of many fragments e.g. Peptide 2 is made up of fragments A and K; Peptide1 is made up of A and Q and so on. My idea is to create an index on the mass column and be able to retrieve all Peptides that contain a certain fragment mass e.g SELECT peptide FROM Fragments WHERE mass = x; Should give me: Peptide1, Peptide2 The alternative way I have thought of to organize this table is to have something as follows: Approach (2) Primary Key = {fragment, mass, peptide} fragment | mass (of fragment) | peptide ---------------+--------------------------------+-------------- A | x | Peptide1 A | x | Peptide2 Q | y | Peptide1 K | z | Peptide 2 K | z | Peptide 3 If I consider 2500 unique fragments then, using approach (1), table Fragments will hold 2,500 tuples. If I consider the same number of fragments then table Fragments using approach 2 holds 15,000 tuples. I have considered using approach (1) whereby I would have less tuples to search but if I wanted to access the peptides they belong to I would retrieve the list of corresponding peptides e.g the string "Peptide1, Peptide2" and process it in my program. However this seems like a hack around the way a database table should be organised. The problem increases further when I have to scale up and consider more unique fragments (>2500). Any help on how best to structure such data would be mostly appreciated. - Salman Tahir ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/