Hi Joel,
On Fri, 8 Aug 2014 12:02:55 -0700 Joel Madero <jmadero....@gmail.com> wrote: > > > > Yes, but what would go into the Series table? SeriesName and > > BookName are already in the BooksRead table, and the read flag just > > indicates that it is in the BooksRead table. > > > > So the Series Table would have all books in a series and this way I > could query the next book to be read in a series. So for an example: > > Book Table: > Harry Potter and the Sorcerer's Stone (...) SeriesName="Harry Potter" > > > Series Table: > Harry Potter | Harry Potter and the Sorcerer's Stone (Read) > Harry Potter | Harry Potter and the Chamber of Secrets (Unread) > Harry Potter | Harry Potter and the Prisoner of Azkaban (Unread) > .... In this case, one book would be duplicated, and duplication is usually a bad idea. It would be better to put all the books into a single Books table. > Then if I set up some kind of a report that told me the next book in > the series, when I query "Harry Potter" it would give me "Harry > Potter and the Chamber of Secrets" (and possibly list all other books > in the series that are not yet read, or list all books in the series, > highlight the ones that are unread, or some such thing) This can still be done if they are all in a Books table. > What I don't want is my main table to include both read and "want to > read" books - I like keeping the "what I've read" completely separate > as this is what I'm most interested in for tracking purposes (to meet > my goal) and what not. Well, this is a big deal in a spreadsheet, where all that data is just smooshed together and you have trouble visually separating it, but in a database this isn't actually a problem. By design, tables are meant to hold lots of data like this, and you query just the data you want at any given time. It is better to design it as one big table, and pull out only the data you want to see, than to separate it into multiple tables that hold duplicate data. With duplicate data you are not only wasting storage space (perhaps very little in this case, but in principle a bad thing), but also bringing in the possibility of that data differing in the different locations in which it is stored, and then which copy do you trust? Note that any data can be corrupted, but with multiple copies of the data in a database, differing programs or a bug in your program can cause the data to differ. Your scenario also doesn't account for non-series books that you haven't read. If that is yet a third table, then things are getting messy. So the best design is one table for books both read and unread, including series information, but if you really want to separate them out, then one table for read books, and one for unread books, both including series information, is the best way to go, I think, with the front-end transferring the books between the two tables when you've read them. Paul -- To unsubscribe e-mail to: users+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted