Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

Hi Joel,

On Fri, 8 Aug 2014 12:02:55 -0700
Joel Madero <> 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


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.