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


Hi Joel,


On Sun, 10 Aug 2014 15:49:25 -0700
Joel Madero <jmadero.dev@gmail.com> wrote:

Gah - I just realized that I think I have to separate "date read"
from the book info. Reason being that if I read a book 2-3 times and
want to track the dates then I have to have another table. With this,
I'd do a one to many relationship between the book information and
the read date tables, yes?

Yep, sounds right.


The way I imagine it working is when I enter a book title + author,
it checks book information to see if the book is already in the
table, if it is, it just pulls up the info related to the book, and I
can mark as read, add a new date that I've read (which might or might
not be the first time I've read it), it enters the date in the date
read table, allows me to rate (or update the rating) etc...

With this, you could even do away with a read status, and just see if
there are any dates in the DateRead table for the book, but then you
wouldn't get things like "busy reading" and "must read soon", so I'd
still keep both tables. Note that this does mean you could potentially
have a book with a status of read, but no completed dates. This is
something the frontend would need to check for and not allow you to
change the status to read without adding a completed date.



Make sense?


Best,
Joel

P.S. It seems like part of db work is just figuring out personal 
preferences. Reading the emails a few times it seems like there are 
differing opinions a little about the use of tables (the # of
tables), etc...

There are of course slight differences, but there shouldn't be any
major ones, except where we have different ideas about exactly what you
want to achieve. If there are any large differences in advice, we've
probably misunderstood something :)



So my plan is sticking with the original thought - keep ranking
separate from the book information table, but splitting author,
series, etc... from book information and putting those in a different
table.

I'm still not entirely sure how you want to rank books, but yes,
keeping it as its own table seems like the right idea to me.

You could just track a single number (say from 1 to 5, or 1 to 10), for
each rank category, or a single text description for each category, and
keep that in the book table, but making it a separate table is a little
more flexible if you're going to use standardised ranks across all
books, and not an individual description for each book.


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

Context


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.