Even though I have access to Windows, I seldom use it. With my Sony reader filling up with books, I appreciated the possibility of organizing them into "Collections", even if it is limited to the internal memory.

You have to use the Connect software to do so, afaik. You cannot do it on the device itself, and considering the glacial speed with which Sony releases any updates, I do not expect that to change anytime soon, not anymore than the inability to use collections on the memorycard.

The software I mostly use now, libprs500, does not (yet) support collections. Does any of the other alternatives out there? What do You do if you don't use the Connect software? Just skip collections altogether and flip pages upon pages in you booklist to find a particular title ? (Sony doesn't offer search or sort either...)

I tend to not keep many books on the reader. After all I'm not likely to be reading more than a handful of books in a given period of time. Just needs a little discipline to delete stuff from the reader every time you upload new books.

That's one of the reasons that Apple makes many different sized iPods. Some people like just a hand full of songs at a time while others like their whole collection available.

I personally use collections for a number of purposes. First I have one collection that has my "to read" books. Then I have collections that have books by specific authors or series (for example). Last I use collections to group books by subject matter. There are ways around all this, for example, create a rtf file that lists all my books listed by title, author, series and subject, but it's not nearly as natural as using collections. It sure would be nice if I could create collections on my mac or for that matter, if you could put books that are in the memory chip in collections.

What you're describing is basically a, pardon my saying so, rather hackish method of cataloging your collection. The reader simply isn't meant to do that and because the connect software is so closely tied to it, it doesn't do it well either. I maintain my catalog in a database on my computer, using a frontend I wrote specifically for that purpose.

I'm sure your method is much more elegant than mine, kovidgoyal -- I just sort the files into folders by author's name (last, first) and then sub-folders for series (I pre-pend the position in the series to the title: i.e. "01 On Basilisk Station.RTF" would be in the "Honorverse" sub-folder of the "Weber, David" folder). It's kinda brute force, but it works well enough for me. :shrug:

I used to do what you describe Natch, but then I found that it doesn't scale well. I started getting impatient with the amount of time it took to find a particular book. Now my database support tags and comments and a search function, so finding all the books in honorverse is as simple as tagging them on first import and then just typing in honorverse in the search bar. And it has a rating system so I never end up re-reading books I don't like ;-)

Yup, a much more elegant solution. Does it run on windoze? :wink:

I use an Access database to catalog all my eBooks. Perhaps slightly OTT, but since I'm a bit of a database "whizz" (databases are what I spend a large part of my day dealing with at work) I find that the power and flexibility of SQL queries lets me extract all sorts of information very easily.

I tend to not keep many books on the reader. After all I'm not likely to be reading more than a handful of books in a given period of time. Just needs a little discipline to delete stuff from the reader every time you upload new books.
Because of the way the Reader's collections work, what I am doing is keeping the books loaded in the internal memory in collections and when I finish reading a book, I move it to my 2gig SD card for now. I know I have to come up with a better way to organize stuff. But for now this works.

I'm gradually coming up with an organization of all my e-books, which involves keeping a large number (280 or so) directly in the Reader's memory, but I have decided just this morning to do away with the memory card, since it does appear to use up some extra battery just being in the reader, and since I really don't need over 2500 books to choose from at any one time.

I'm thinking of creating two identical directory structures on my hard drive, one as it stands now, containing all my e-books (mostly PG e-texts) and one completely empty. I would move books gradually from the full directory structure to the reader and then once they're read, placing them into the empty one, so I can tell at a glance which books I haven't read and which ones I have.

But of course I'll have archived them all onto DVD for more permanent storage.

@Natch
Yeah its the libprs500 GUI. Even has an installer. The only platform where it's still iffy is OSX.

@HarryT
I use an sqlite database. What metadata do you maintain in your database?

Oh, the way you talked about it, I guess I assumed it was something else -- I'm going to have to download that rascal yet. :wink:

[QUOTE=kovidgoyal@HarryT
I use an sqlite database. What metadata do you maintain in your database?[/QUOTE]

Basically for each book I store:

- Author(s)
- Title
- Category(s)
- Series
- Series Position
- Format (s)
- Source
- Comments

It's a bit more complicated that that in that, for example, I have a "Book" table, an "Author" table, and a "Book/Author" link table; this lets me have a "many to many" relationship between books and authors. Similarly with category and format.

Hmm I assume you enter the metadata by hand for each book? Otherwise you're likely to have many entries for the same author in your authors table.

The data's all properly "normalised". I don't store the actual NAME of the author for each book - just a "foreign key" into the author's table. I've created some nice GUI forms in Access for doing the data entry ans searching.

Ah since I know next to nothing about databases, I'm going to ask what advantage you get from storing the authors independently of the books?

OK - "Database 101" time :).

The goal of any database design is to only store each item of information once, and once only. This is called "normalisation".

In my database, I have a table of authors ("tAuthor"), which has an author's name, and a ID, which is simply a number. Eg:

1: Asimov, Isaac
2: Dickens, Charles
3: Austen, Jane
...

I then have a list of books ("tBook"), again each one with a ID:

1: Bleak House
2: Pride and Prejudice
3: Sense and Sensibility
4: Oliver Twist

Finally, I have a "link table" ("tLnkAuthorBook") which contains pairs of numbers - an author ID and a book ID:

AuthorID BookID
2 1
2 4
3 2
....

This means that author number 2 (Dickens) is an author of book number 1 (Bleak House); author number 2 (Dickens again) is an author of book number 4 (Oliver Twist), etc.

The benefit of this is that any book can have as many different authors as you want (multiple rows in the link table with the same Book ID) and any author can have as many books as you want (multiple rows with the same author ID.

So, to find all the books that Dickens wrote, I just have to search the link table and find all the rows where the author ID = 2. Having got those rows, I look up the details of the book from the book ID. I can do this with a SQL statement such as:

SELECT Title FROM tBook INNER JOIN tLnkAuthorBook
ON tBook.ID = tLnkAuthorBook.BookID
WHERE tLnkAuthorBook.AuthorID = 2

This will give me a list of all the titles of the books for which Dickens is an author (or a co-author).

Sorry, that's very brief, but hopefully you get the idea! In reality, I don't have to type in the SQL by hand - I just have a form where I can choose an author from a drop-down list, and I'll get a list of the details of all the books that the author wrote.

Hmm I see the advantage of having things only one in the database. A not so obvious one is that you can do sorting at insert time by having a separate table for each sortable field.

OK one more question:
Suppose I wanted to do a match for a search term over several fields. What would be the most efficient way to do that in this kind of setup? Is it just a bunch of inner joins? How efficient (fast) is that?

Thanks.

Hmm I see the advantage of having things only one in the database. A not so obvious one is that you can do sorting at insert time by having a separate table for each sortable field.

That's not really true; data in a table in a relational database is not generally thought of as being "sorted"; you can sort the results of any query by adding an "ORDER BY" clause. Eg:

SELECT * from tBook ORDER BY SERIES, SERIES_POSITION

will display a list of books sorted by series name, and by series position within each series.

OK one more question:
Suppose I wanted to do a match for a search term over several fields. What would be the most efficient way to do that in this kind of setup? Is it just a bunch of inner joins? How efficient (fast) is that?

Thanks.

"Joins" specify RELATIONSHIPS between tables, rather than search conditions (although they can be used to do certain types of search). Eg, in my previous example:

SELECT Title FROM tBook INNER JOIN tLnkAuthorBook
ON tBook.ID = tLnkAuthorBook.BookID
WHERE tLnkAuthorBook.AuthorID = 2

The:

tBook INNER JOIN tLnkAuthorBook
ON tBook.ID = tLnkAuthorBook.BookID

join condition means that the "ID" column in the "tBook" table is the same value as the "BookID" column in the "tLnkAuthorBook" table.

The normal way to specify search conditions is in the "WHERE" clause of the query. If you're simply testing for equality, or for a range of values, provided that the table is "indexed" on the value you're doing the search on, it's amazingly fast (indexes are stored as "b-Tree" data structures, which are extremely rapid to search). We use databases at work which have millions of rows in them, and you can do SQL searches which return values from them in a tiny fraction of a second. It only gets slow if you do something like a "wildcard" search where an index can't be used, and the database has to "scan" each row in the table in turn to see if it matches the search condition.

SQL is well worth learning - it's a "universal" interface to databases and you can do amazing things with it. There are lots of good SQL books in any computer bookstore.

Thanks, you've opened up lots of vistas for me to explore. I do need to learn more SQL.

My pleasure!

Tough thing with dealing with SQL queries is they vary slightly from DB to DB. We had quite a few different research projects going on at my last job where I'd have to deal with mySQL, PostgreSQL, MS SQL, and Oracle. Talk about a pain in the butt getting all the query syntax mixed up when I hadn't used a particular system in a while!

In the end, I think I liked mySQL a bit better than the rest; while they all have their pro's and con's, mySQL had the best value... being free (so is PostgreSQL, but mySQL was more widely used and had a nice freeware GUI for Windows you could use mySQLPal)!

Yeah but I doubt mysql is suitable for an enduser app. I'm not going to ask my users to run a mysql server. There are libraries that present a unified API for all the databases, for e.g. sqlalchemy

Yeah but I doubt mysql is suitable for an enduser app. I'm not going to ask my users to run a mysql server. There are libraries that present a unified API for all the databases, for e.g. sqlalchemy

Just use SQLite... No seperate install required.

yeah that is what i use at the moment.