[RESOLVED] To store page text in DB or don't bother? feedback anyone?

php_noob2

Hi all, thanks for all the help in previous posts...

I am basically digitizing some company textbooks which would change maaaybe once a year if that -and only then it would be certain pages, not a mass overhaul. What I am wondering is if I should create static pages which would contain text and perhaps an image or two or store all text in the db and just the paths to any images?

If storing text in the db, is it best practice to store the style tags there too?

thanks for any feedback!

Piranha

This is a question with no direct answer, you could do it either way.

How should the text be changed? Should you do it manually in the database/html files or should it be done with a form? If you change it from a form I would suggest a database.

The html tags make it more difficult to handle this. I would say as a general rule that you should not store tags in a database, it is pretty easy to insert malicious code.

Weedpacket

Unless you're going to be doing something like providing full-text searching (which would be hampered by all the markup anyway), I'd use a DBMS that is specifically designed for storing and quickly retrieving static files without caring a huge amount about what's in them. Such a DBMS is called a "filesystem" and you probably already have one installed 🙂

pmmenneg

First, I would definitely store the data in the database. For many reason, including:

1) Ease of making changes
2) Being able to pull this data from anywhere
3) Data integrity (if the page gets lost/changed by accident)
4) Your needs may change in the future requiring more intensive usage/changes

So, that being said, my first response would be to pull the data WITHOUT style info from the database and pass it to a common formatting function or template.

db => php page => formatting/template => php page => user

Fallback if the formatting/template is not feasable depending on the intended layout complexity would be to do as above and store the marked up text in the db, with references to css classes, so that changing a single css file will still enable you to change the formatting of all pages without having to 'touch' each db entry.

Hope this helps!

Weedpacket

Hm....

pmmenneg wrote:
1) Ease of making changes

"Maaaaybe once a year" and any bog-standard HTML editor could be used.

2) Being able to pull this data from anywhere

This thing called "the web" is quite good at doing this even for static files

3) Data integrity (if the page gets lost/changed by accident)

And if the database gets damaged? This is why we have backups.

4) Your needs may change in the future requiring more intensive usage/changes

That's true for any and every component of the site - including being served over http. Many's the time I've seen code written a certain way because "we might want do to Foo later on" and it turned out later on "we" actually wanted something totally different and all that Foo-capable stuff was suddenly in the way.

Just saying: in real apps there are no bonus points for gratuitous complication.

bretticus

Of course if you want any of your books to be remotely searchable from your website (besides google), you may want to opt for the database and without tags if possible (line breaks for break tags, etc. Weed already mentioned the trouble with tags and fulltext indexing!!!! )

farius

Static pages that are well laid out and commented would probably be the best route. This is because of the lack of need to change the data often. If it changes later, it wont matter much, you will build a database system and all is well. But if it doesn't, then you save time, thus money is saved as well.