On Fri, 8 Aug 2014 12:02:55 -0700
Joel Madero <email@example.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:
Harry Potter and the Sorcerer's Stone (...) SeriesName="Harry Potter"
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: firstname.lastname@example.org
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
Re: [libreoffice-users] Currently Using Spreadsheet for Personal Project - Thinking About Database · Oogie McGuire
- Re: [libreoffice-users] Currently Using Spreadsheet for Personal Project - Thinking About Database (continued)
Impressum (Legal Info)
: 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