KPW.....collection.......question

[rah68]

When I add a book that i have finished to my "read books" collection, it stays in my list of books AND in the collection. So.....I tried "remove book from device" from the main list......and it deletes BOTH the main list one and the one in the "read books" folder. Anyone else have this problem ??

My solution atm is to go ahead and delete it.......If i need it, it is in Calibre anyway

[ixtab]

Originally Posted by rah68

When I add a book that i have finished to my "read books" collection, it stays in my list of books AND in the collection. So.....I tried "remove book from device" from the main list......and it deletes BOTH the main list one and the one in the "read books" folder. Anyone else have this problem ??

My solution atm is to go ahead and delete it.......If i need it, it is in Calibre anyway

Collections are not what you probably think they are. They are not folders, but only "tags" added to a book. A book can be in multiple collections at the same time, and unless you order the items on your device "by collection", books will appear both on the home screen, and in all the collections they have been "filed into"/tagged with.

[rah68]

Excuse me but that's illogical.....( to quote Mr Spock )

A......it does it in my Kindle fire
B it does it in my Kindle keyboard
It does NOT do it in Paperwhite :-(

why bother making a collection at all if the book is to remain on the home screen.....the idea there was to unclutter the list on the home screen yet, still have the book on the device

[knc1]

Originally Posted by rah68

Excuse me but that's illogical.....( to quote Mr Spock )

Depends on which way your ears point.

This system allows a book to be included in multiple collections -
By author
By publisher
By genre
By publication date
By title
By <whatever floats your boat>

[HarryT]

Originally Posted by rah68

Excuse me but that's illogical.....( to quote Mr Spock )

A......it does it in my Kindle fire
B it does it in my Kindle keyboard
It does NOT do it in Paperwhite :-(

why bother making a collection at all if the book is to remain on the home screen.....the idea there was to unclutter the list on the home screen yet, still have the book on the device

You won't see the book on your home screen if you switch to "Collection" sort mode. That view will show you only collections, plus books which aren't in any collection.

But the important thing to stress is that a collection is not a folder, but a tag. A lot of people misunderstand this, and it's a very important distinction. It's the fact that it is a tag which allows the same book to appear in multiple collections, while at the same time only having a single copy of it on the device.

[rah68]

Originally Posted by HarryT

You won't see the book on your home screen if you switch to "Collection" sort mode. That view will show you only collections, plus books which aren't in any collection.

Ahhh I see now ( said the blind man headed for the cliff)

thats much more betterer

[ixtab]

Originally Posted by HarryT

You won't see the book on your home screen if you switch to "Collection" sort mode. That view will show you only collections, plus books which aren't in any collection.

But the important thing to stress is that a collection is not a folder, but a tag. A lot of people misunderstand this, and it's a very important distinction. It's the fact that it is a tag which allows the same book to appear in multiple collections, while at the same time only having a single copy of it on the device.

Thanks, Harry, for explaining this again in an easy-to-understand way

For the technically inclined: Think of the book <-> collection relation as an n:m relation in a database. And - guess what - that's exactly what it (logically) is in the underlying SQLite database. Except that the people who implemented it might want to revisit their cs1xx course material (Introduction to Databases), because they must have been in a coma during the normalization part of the lecture. The database actually does it in the worst possible way for an n:m relation, namely using NF² at both ends of the relation.

[HarryT]

Originally Posted by ixtab

For the technically inclined: Think of the book <-> collection relation as an n:m relation in a database. And - guess what - that's exactly what it (logically) is in the underlying SQLite database. Except that the people who implemented it might want to revisit their cs1xx course material (Introduction to Databases), because they must have been in a coma during the normalization part of the lecture. The database actually does it in the worst possible way for an n:m relation, namely using NF² at both ends of the relation.

Probably more robust, though, than using the technically "better" solution of a link table. Link tables are prone to getting broken if things go awry. Performance is probably also better, because you can do queries without (or with fewer) table joins. A lot of my "day job" work is with databases, and we often end up with a certain degree of denormalisation for both the reasons I've mentioned.

[ixtab]

Originally Posted by HarryT

Probably more robust, though, than using the technically "better" solution of a link table. Link tables are prone to getting broken if things go awry.

???

That's what databases are there for: they can maintain referential integrity by themselves. SQLite supports all of that - why not use it?

[HarryT]

Originally Posted by ixtab

???

That's what databases are there for: they can maintain referential integrity by themselves. SQLite supports all of that - why not use it?

Have you ever dared to venture into the Kobo forum? The Kobo stores ALL its library information in a database, and the number of times it breaks, resulting in the need to reload all books, is alarming.

[ixtab]

Originally Posted by HarryT

Have you ever dared to venture into the Kobo forum? The Kobo stores ALL its library information in a database, and the number of times it breaks, resulting in the need to reload all books, is alarming.

Nope, I haven't been there - I don't own a Kobo.
But I do have a degree in Computer Science, with a specialization in databases... and I definitely know that if you use a DBS correctly, it will save you from all sorts of trouble (and effort!), instead of causing it.

[ixtab]

Originally Posted by HarryT

Performance is probably also better, because you can do queries without (or with fewer) table joins. A lot of my "day job" work is with databases, and we often end up with a certain degree of denormalisation for both the reasons I've mentioned.

Sorry, I only read this part of your reply now.

Yes, that's a valid point, and denormalization does make sense at times. But just before we start, how many Terabytes of data does an e-reader hold, and how many thousands of concurrent transactions does it have to process per second? Are we talking about hundreds of table joins, where each table could contain millions of records?

...

Of course, the following are all unsubstantiated claims - nobody except Amazon knows what exactly is happening in their code after all. I'm just sticking with how Amazon organized their database schema - we're talking about 0 joins (as opposed to 2), followed by JSON parsing and (in most of the cases) at least one additional DB query to "simulate" the join - because the data has to be retrieved anyway, and I actually doubt that they do all of the retrieval in one go; I rather think that it will be n additional queries.

Essentially, I strongly suppose that they "reimplemented" the join in client code. So also in terms of performance, I'd bet that a proper database schema would outperform the current one - even for the extremely small database that a Kindle holds. Plus, it could also provide referential integrity at no cost.

Another unsubstantiated claim: if the Kobo really has that many problems with its database, then I assume that it's for the exact same reason. A database system can do so much more than just "put things in there and get them out of there", but one actually has to understand at least a little bit of the theory to use it efficiently. Seriously, the DB schema that Amazon uses is pretty much what any 16-year old would intuitively come up with. They're essentially not using ANY of the benefits that a DBMS really offers - they could have just used plain files instead*.

(*) Yes, the collections actually were plain files before the K5. So they just seem to have ported that "to a database". But why build an entire new API around it, if they don't use the benefits of the DB? Just because "management asked that the collections must be stored in databases now"? What's the point?

[twobob]

future proofing?

Oh and the kobo does it you know! So it must be good...

sqlcipher also springs to mind but meh. cmon. really? Nah... surely not.

For my part I appreciate the schema, possessing the skills of the average 16 year old it suits me perfectly... Thank you that decision maker!