Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: John-Paul Stewart Newsgroups: comp.databases.postgresql Subject: Re: Table with a variable number of elements in a column Date: Sat, 27 Apr 2019 17:10:16 -0400 Lines: 24 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net mycx1X5RFdeeZrZNh8AYGgwBD3h/edOCWNgn/xOZduvlDKFPCF Cancel-Lock: sha1:fa5P5ygt9QT8PutOo/tmow0aRv4= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: Content-Language: en-CA Xref: csiph.com comp.databases.postgresql:866 On 2019-04-27 4:29 p.m., Bill Gunshannon wrote: > On 4/27/19 4:02 PM, John-Paul Stewart wrote: >> On 2019-04-27 3:48 p.m., Bill Gunshannon wrote: >>> >>> But if I understand this correctly I would need a separate table for >>> every album resulting in, potentially, thousands of tables. (OK, in >>> my case hundreds but others may like this idea, too, when I finish >>> the whole project.) >> >> No, it's only one "tracks" table.  That's why there's an album id column >> in it:  so that each track is associated with one album.  There'd be >> (album 1, track 1), (album 1, track 2), (album 2, track 1), and so >> on....  Each (album, track) tuple would have to be unique.  But you'd >> keep all the tracks for all the albums in one table. > > I got that now. > But I guess I am still stuck with how I define how many tracks columns > there has to be for each album.  I think I have been away from this for > too long.  I am missing something that is probably both simple and very > apparent. By using a tracks table, it's no longer a question of "how many tracks columns" but "how many tracks rows" instead. And the answer is "however many you populate with the same album id". That's the beauty of it.