article database - help needed

csxpcm

hello
im having difficulty understanding how to store articles in a database. Since a html page (the article) contains links to images, how do i store this also in the database. Should I define another table in the database, containing all images belonging to that article?
Would it be best to define just the path location to each file or store the whole article in the database.
Im just confused on how to best code a database driven article system.
The only good example i found was one holding a database of jokes, but this doesn't have things like images in the html files.

Any help would be much appreciated, or if someone could refer me to a good tutorial or resource.

Thanks in advance
Pete

Weedpacket

If you're asking whether to store the images in the database or on the filesystem, the correct answer is almost always "on the filesystem". Storing the images in the database (as blobs) would require the <img> tags to refer to PHP scripts that call the database to get the image data out, and use the database as a particularly complicated, overweight and clunky filesystem*; a lot more overhead. Storing them on the filesystem means that the <img> tags can locate the images directly via a conventional URL.

[*]Though I understand that Microsoft are considering implementing this approach for Windows filesystems in the future.

csxpcm

ok, thanks for the reply. As a further question, since an article is generally rather large and may contain rather complex formating, how is it transferred to the database. Fos instance, with the joke database example I previously referred to, this could just be typed out in a text box then submitted, via a simple 'php' page which would 'insert' it into a database.
However, for a large html page that contains formatting, tables, etc., the only way I can think of it to create the article in a package like dreamweaver, then cut-and pase the html generated into the database.
This method appears tedious. Does anyone know if better methods exist for getting the data into the article database.

yelvington

Store articles. Generate pages.

A good system design separates content from presentation "upstream" and unites the two "downstream."

Think "data" and "templates."

This allows you to change "template" and suddenly the look, feel, and navigation of an entire site is updated. If you entangle presentation with data, you can't do that.

In a well-designed content management system, article text will contain only the markup necessary to reflect its structure: paragraphs, headings, points of emphasis, et cetera.

csxpcm

ok thanks
thanks for the reply. Ill certainly look into utilising templates. However, the page requires preparation, to initially write the article (even with just basic formatting).
So do generally people prepare the html file in a package like dreamweaver, then somehow cut and paste this into the database? It just appears tedious to have to cut the html from dreamweaver for example, then paste it into a text box on a php page, ready to be inserted into a database. Im not sure of the process of getting the data into the database easily.

Thanks in advance and all the advice currently given!
Kind regards,
- Pete

yelvington

Depends. Who are your authors? What sort of system are they using to write?

In a very simple system you might cut and paste from Word, or write directly into a Web form.

If you write directly into a Web form (like the ones used in this message forum) you can improve the UI with typestyle buttons using Javascript.

If you paste from Word into a Web form, you lose basic markup.

Microsoft has an IE-specific HTML authoring control that you can integrate into your pages as if it were a Web form (if you're comfortable writing some Javascript and can find the documentation on MSDN). My company sells a low-end site management system that relies on it. It allows you to cut/paste text from Word or complete tables from Excel. Formatting is converted to HTML.

My company's CMS systems integrate with a variety of upstream tools -- Quark pages, Baseview, DTI editorial systems, and others. Each one is a special engineering challenge. But you don't go down that road unless you're integrating with some legacy workflow system.