So we've got a table called "books" and we want to build records of how
often each book is accessed and when. How would you store such
information so that it wouldn't become a huge unmanageable table?
Before I go out trying to plan something like this I figured I'd ask and
see if anyone had an
Eci,the usual way is:create table books (id_book serial, author text, title text ...)create table access (id_access serial, id_book int4, timeofaccess timestamp,...)then for every access you write 1 record to access.
A rough estimate: a book may be lent out every hour once, so that is 8544 records
What if instead of book checkouts we were looking at how often a book
was referenced? In which case we're talking multiple times an hour, and
we could easily have each book requiring hundreds of thousands of rows.
Multiply that by hundreds of thousands of books and a the table seems
to become
Eci,I could not google them up quickly, but there are people dealing with tables with millions of records in PostgreSQL.Per technical data the number of rows in a table is unlimited in PostgreSQL:
http://www.postgresql.org/about/There may be performance-reasons to split up a table of that size, but
On 7/16/06, Eci Souji <[EMAIL PROTECTED]> wrote:
So we've got a table called "books" and we want to build records of howoften each book is accessed and when. How would you store suchinformation so that it wouldn't become a huge unmanageable table?
Before I go out trying to plan something like this
Hi,
On Sun, 16 Jul 2006, Eci Souji wrote:
What if instead of book checkouts we were looking at how often a book was
referenced? In which case we're talking multiple times an hour, and we could
easily have each book requiring hundreds of thousands of rows. Multiply that
by hundreds of thousa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eci Souji wrote:
> What if instead of book checkouts we were looking at how often a book
> was referenced? In which case we're talking multiple times an hour, and
> we could easily have each book requiring hundreds of thousands of rows.
> Multiply th
I think "books" may have thrown everyone for a loop. These are not
physical books, but rather complete scanned collections that would be
available for search and reference online. One of the most important
features required would be keeping track of how often each book was
referenced and when
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
IOW, files. No problem.
The # of files is known. That's a start. Is there any existing
metric as to how often they are accessed? That's what you need to
know before deciding on a design.
This simple design might be perfectly feasible:
CREATE TABL
