Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Table design for online book.

17 views
Skip to first unread message

The Natural Philosopher

unread,
May 23, 2012, 10:35:20 AM5/23/12
to
I am trying to puzzle out the best way of doing this: Essentially I have
an entity called 'book' which is split into 'chapters' each one of which
is a massive chunk of text. (let's ignore illustrations and diagrams for
now).

I want to serve that as 'pages' of fixed geometric size into a fixed
frame. I can easily enough calculate page start offsets in characters
into the text, but what is the best way to store them. For some reason I
can't picture the way to separate this and map it into in SQL tables...

Is there any better way than
database: book
table: chapters; fields: id, title, number, content
table: page offsets; fields: id, chapter id, number, offset

?

It seems more complex than I feel it should be..





--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.

Jerry Stuckle

unread,
May 23, 2012, 12:44:12 PM5/23/12
to
On 5/23/2012 10:35 AM, The Natural Philosopher wrote:
> I am trying to puzzle out the best way of doing this: Essentially I have
> an entity called 'book' which is split into 'chapters' each one of which
> is a massive chunk of text. (let's ignore illustrations and diagrams for
> now).
>
> I want to serve that as 'pages' of fixed geometric size into a fixed
> frame. I can easily enough calculate page start offsets in characters
> into the text, but what is the best way to store them. For some reason I
> can't picture the way to separate this and map it into in SQL tables...
>
> Is there any better way than
> database: book
> table: chapters; fields: id, title, number, content
> table: page offsets; fields: id, chapter id, number, offset
>
> ?
>
> It seems more complex than I feel it should be..
>

I would put each page in its own row. Something like:

Book: bookid, title, author, etc.
Chapter: bookid, chapterid, chapternumber, title
Page: chapterid, pageid, pagenumber, pagetext

You could get rid of chapterid and pageid, instead using compound
primary keys, i.e. chapter would have (bookid, chapternumber) and Page
would have (bookid, chapternumber, pagenumber).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================

Erick T. Barkhuis

unread,
May 23, 2012, 1:05:36 PM5/23/12
to
The Natural Philosopher:

>I am trying to puzzle out the best way of doing this: Essentially I
>have an entity called 'book' which is split into 'chapters' each one
>of which is a massive chunk of text. (let's ignore illustrations and
>diagrams for now).

So, that sounds like a table "books", with something like
- bookID
- bookTitle
- perhapsOtherFields

and a table "chapters", n:1 to "books":
- chapterID
- bookID (FK)
- chapterText

>
>I want to serve that as 'pages' of fixed geometric size into a fixed
>frame.

Is that size depending on the number of characters? The size of the
characters? Anything else? Is the user able to change appearance, so
that the contents of the 'page' is different from what another user may
expect?

>I can easily enough calculate page start offsets in characters
>into the text, but what is the best way to store them.

Why would you?
If you want to be able to return a certain substring of chapterText,
then do so. You need not store exactly what you need to present...the
presentation is done in the presentation layer.


>Is there any better way than
>database: book

Errrmmm...is there just one book? Are you going to introduce a database
for each book?

>table: chapters; fields: id, title, number, content
>table: page offsets; fields: id, chapter id, number, offset

If you can calculate the offset at the time you need to present the
data, there's no need (yet) to store that offset. It would even be
useless as soon as you decide to change the size of the frame or chunk.



--
Erick

The Natural Philosopher

unread,
May 23, 2012, 2:59:25 PM5/23/12
to
Erick T. Barkhuis wrote:
> The Natural Philosopher:
>
>> I am trying to puzzle out the best way of doing this: Essentially I
>> have an entity called 'book' which is split into 'chapters' each one
>> of which is a massive chunk of text. (let's ignore illustrations and
>> diagrams for now).
>
> So, that sounds like a table "books", with something like
> - bookID
> - bookTitle
> - perhapsOtherFields
>
> and a table "chapters", n:1 to "books":
> - chapterID
> - bookID (FK)
> - chapterText
>
>> I want to serve that as 'pages' of fixed geometric size into a fixed
>> frame.
>
> Is that size depending on the number of characters? The size of the
> characters? Anything else? Is the user able to change appearance, so
> that the contents of the 'page' is different from what another user may
> expect?

I wuill go with ans near as possible a nailed down font at a fixed size.

>
>> I can easily enough calculate page start offsets in characters
>> into the text, but what is the best way to store them.
>
> Why would you?
> If you want to be able to return a certain substring of chapterText,
> then do so. You need not store exactly what you need to present...the
> presentation is done in the presentation layer.

how else do in know how to turn to page 376?


>
>
>> Is there any better way than
>> database: book
>
> Errrmmm...is there just one book? Are you going to introduce a database
> for each book?
>

could do yes.

>> table: chapters; fields: id, title, number, content
>> table: page offsets; fields: id, chapter id, number, offset
>
> If you can calculate the offset at the time you need to present the
> data, there's no need (yet) to store that offset. It would even be
> useless as soon as you decide to change the size of the frame or chunk.
>

that has to be preset as I cannot second guess what page size the user
might want.

So he ghets a fixed number of chars per page ..I suppose actual page 373
is just 373 x no of chars in a page and skip back to the last
whitespace..but it gets trickier when I put in images.

Hence the need to pre calculate, not to do it on the fly.

Erick T. Barkhuis

unread,
May 23, 2012, 3:29:18 PM5/23/12
to
The Natural Philosopher:

>Erick T. Barkhuis wrote:

>>Is that size depending on the number of characters? The size of the
>>characters? Anything else? Is the user able to change appearance, so
>>that the contents of the 'page' is different from what another user
>>may expect?
>
>I wuill go with ans near as possible a nailed down font at a fixed
>size.

I'm just curious: on what type of device will the pages be shown? And
with what presentation technique?

>>If you can calculate the offset at the time you need to present the
>>data, there's no need (yet) to store that offset. It would even be
>>useless as soon as you decide to change the size of the frame or
>>chunk.
>>
>
>that has to be preset as I cannot second guess what page size the
>user might want.

Can't your application keep track of the page size the user has chosen,
and what page he is on now? For instance by using sessions (if that's
possible on the device).

>
>So he ghets a fixed number of chars per page ..I suppose actual page
>373 is just 373 x no of chars in a page and skip back to the last
>whitespace..but it gets trickier when I put in images.

You said we should leave images out of scope!

>Hence the need to pre calculate, not to do it on the fly.

Well, if the document has images and paragraph titles, and animation
movies and whatnot (which may or may not be blocked separately by the
user), you will not be in charge of the presentation. But you can still
be in charge of the data...and that's what the database is for.
[Imagine what would happen if you replace one image by another of
different size...your database records wouldn't fit to page anymore!]


However, just a completely different thought:
- why would you want to store the book in a database in the first place?
- wouldn't you rather store it as a book (for instance a PDF-file) and
present numbered pages of that PDF-file instead of records from a
database?


--
Erick

The Natural Philosopher

unread,
May 23, 2012, 3:44:40 PM5/23/12
to
Good thought.
How do you 'display page 2324 of mybook.pdf' in a web frame?

Erick T. Barkhuis

unread,
May 24, 2012, 2:32:13 AM5/24/12
to
The Natural Philosopher:

>How do you 'display page 2324 of mybook.pdf' in a web frame?

In the described situation, the two simplest ways to go are:
1. Generate a pdf file for each page, so you can send that page upon
request. Since you appear to be able to define the contents of a page
(after all, you wanted to put this into a database record), it should
be possible to generate numbered single page pdf files
2. Simply send the whole document and let the reader jump to page 2324,
using his pdf reader software. If you wish, you could generate
bookmarks to enable quick jumps.

Alternatively, since you have 'chapters', why not create pdf-files for
each chapter (perhaps with bookmarks for each top-of-page, if you
must). Then send the chosen chapter-pdf to the browser/device. You will
probably not know what type of PDF-software the user has, so chances
are, that he will know better how to get to a specific page than you do.

The advantages are:
- you can always change the contents and generate new PDF files
- there's no need to stick to certain fonts, image sizes, etc.
- no need to try and force variable book contents into a structured
mysql database

--
Erick

Erick T. Barkhuis

unread,
May 24, 2012, 2:38:58 AM5/24/12
to
Erick T. Barkhuis:

>The Natural Philosopher:
>
>>How do you 'display page 2324 of mybook.pdf' in a web frame?
>
>In the described situation, the two simplest ways to go are:
>1. Generate a pdf file for each page, ...
>2. Simply send the whole document...
>
>Alternatively, since you have 'chapters', why not create pdf-files for
>each chapter ...

But if you really, really, really want to just display one page from a
large document, you may be able to find several classes and tools that
will do the job.
http://stackoverflow.com/questions/2584133/split-pdf-documents-into-separate-pages-using-php-or-possibly-perl


--
Erick

J.O. Aho

unread,
Jun 1, 2012, 5:13:34 AM6/1/12
to
On Wed, 23 May 2012, The Natural Philosopher wrote:
> Erick T. Barkhuis wrote:

>> However, just a completely different thought:
>> - why would you want to store the book in a database in the first place?
>> - wouldn't you rather store it as a book (for instance a PDF-file) and
>> present numbered pages of that PDF-file instead of records from a
>> database?
>>
> Good thought.
> How do you 'display page 2324 of mybook.pdf' in a web frame?

There seems to be quite many flash based tools for displaying pdf files,
which allows you to read the whole pdf or serve a page or even allow a
user to read X number of pages.

Of course you have to decide if you want to support flash, as adobe has
decided to stop supporting browsers/operating systems which they do
support today.

--
//Aho

The Natural Philosopher

unread,
Jun 1, 2012, 5:27:43 AM6/1/12
to
The cost of buying flash making tools and the deep hatred I have of
adobe should give you the answer to that one.
0 new messages