> > >There is a section about making 3 tables with SQLite3; books, authors and > book_authors. The last table is described as > >'book_authors' is a many-to-many join table between books & authors' > > > >My query is: Is this the "best practise" or an over-simplification for us > newbies? Would you normally create a table for >joins to show many to many > relationships? I would have though that you could use SQL statements to > retreive that rather >than create a table of it. > > > To answer your question, yes, you need a join table. Each record in it > expresses a relationship between a record in table A and a record in table > B. > > I'd recommend working through an SQL book that explains SQL concepts in > more > detail as that really is a prerequisite for using a database or DBIC > effectively. > E.g. http://tinyurl.com/ywdxfu > > I am unsettled by this. I went and re-read chapter 4 of the book I do have (learning MYSQL) on database design and modelling. I still can't see the value in creating a separate table for a join.
If you have a 1:N table of authors and a table of books with the author ID as a foreign key, surely that all you need to create any join you might want. I know sqlite3 doesn't understand foreign keys but DBIC can create them for you. Isn't that where the relationship is established? Sorry to drone on but if I am told that this is standard practise, I can see a proliferation of tables being created for every relationship that might exist in the application I am trying to create. Thoughts? Dp.
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
