Re: [libreoffice-users] Re: Currently Using Spreadsheet for Personal Project - Thinking About Database

Hi Joel,


On Fri, 8 Aug 2014 12:02:55 -0700
Joel Madero <jmadero.dev@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+unsubscribe@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