Database design: Splitting a blog entry into multiple pages

Question

What is the best database strategy for paginating a blog entry or page content where some entries may be a single page and some may span multiple pages? Note: The content would be article-like rather than a list of items.

The method that I'm currently considering is storing all of the content in a single text field and using a page separator like {pagebreak}. Upon retrieval, the content would be split into an array by the page separator and then the page would display the appropriate index. Is this the best way to go about it, or is there a better approach?

Answer 1

I think your current idea would be the best option. Makes it a lot easier to move the page breaks if you ever want to, or to put them in when you originally compose the article. Also allows you to have a print page option, where the entire article is in 1 field.

Answer 2

You're much better off leaving formatting like this on the client side. Let the database hold your data and your application present it to the user in the correct format.

Answer 3

It seems to me like a good solution. This way you will have your article as one piece and have the possibility to paginate it when necesary.

Answer 4

I think the correct approach is what you've mentioned: the entry should be stored in the database as a single entry, and then you can use markup / the UI layer to determine where pagebreaks or other formatting should occur.

The database design shouldn't be influenced by the UI concepts - because you might decide to change how they are displayed down the road, and you need your database to be consistent.

Answer 5

the easy way (now, but you'll pay later )is to store the entire article within one text field, but you give up some display control because you'll might need to put some html in that text. If you put html in the text, you'll have a lot of data to fix if you ever change your web page's look/feel. This may not be an issue

As a rule I try not to ever put html into the database. You might be better off using XML to define your article, and store that in one text field, so your application can properly render the contents in a dynamic way. You could store page breaks in the XML, or let the app read in the entire article and split it up dynamically based on your current look/feel.

You can use my "poor man's CMS" schema (below) if you don't want to use XML. It will give you more control over the formatting than the "all text in one field" method.

these are just a wild guess based on your question

tables:

Articles
--------
ArticleID        int  --primary key
ArticleStatus    char(1) --"A"ctive, "P"ending review, "D"eleted, etc..
ArticleAuthor    varchar(100)  --or int FK to a "people" table
DateWritten      datetime
DateToDisplay    datetime
etc...

ArticleContent
--------------
ArticleID     int  --primary key
Location      int  --primary key, will be the order to display the article content, 1,2,3,4
ContentType   char(1)  --"T"ext, "I"mage, "L"ink, "P"age break


ArticleContentText
------------------
ArticleID      int  --primary key
Location       int  --primary key
FormatStyle    char(1)  --"X"extra large, "N"ormal, "C"ode fragment
ArticleText    text

ArticleContentImage
-------------------
ArticleID      int  --primary key
Location       int  --primary key
AtricleImagePath  varchar(200)
AtricleImageName  varchar(200)

You can still put the entire article in one field, but you can split it up if it contains different types of "things".

If you have an article about PHP code with examples, the "one field method" would force you to put html in the text to format the code examples. with this model, you store what is what, and let the application display it properly. You can add and expand different types, put page breaks in, remove them. You can store your content in multiple "ArticleContentText" rows each representing a page break, or include "ArticleContent" rows that specify page breakes. You could let the app read the entire article and then only display what it wants.