I article entitled "Building a database-driven site using PHP and MySQL" or something similiar by Kevin Yank has enspired me to finally doing something about that content-driven site of mine which is growing out of hand. Thouhgt I've only strolled trough it yet (I plan to read it later in it's entirety of course, probably more than twice), the article really opened my eyes and gave me a lot of new knowledge. But, with new knowledge comes new question.

So, here are the first couple of questions in the series of probably many-to-come before I have a ready-made database driven site.

Question #1:
I've been trying to draft the tables which the database backend of my site should consist of. Since I've been working with databases prior to this (Access 2000) I know that planning a good database is 50% of the job, and I therefore want to get some input on this from those of you how know about this. I'm also curious whether my relational database-thinking can be adapted from Access to MySQL and to what extend.

My site is a typical "webmaster resource site", so the layout of the datamodel should be pretty familiar. What I'm looking for is overall input. Do I need more tables? More variable data fiels? Have I gotten the relations all wrong? Any advice in general, and so on. Here's the model:

| CHAPTER         |
| CHAPTERID       |
| ChapterName     |
| ChapterContent  |
| ChapterEdited   |
| MetaKeywords    |
| Metadescription |
| *ArticleID      |
|----------------|           |-----------------|
| ARTICLE        |           | AUTHOR          |
|----------------|           |-----------------|
| ARTICLEID      |\          | AUTHORID        |
| ArticleName    |---------|-| AuthorFirstName |
| ArticleDate    |/          | AuthorLastName  |
| *AuthorID      |           | AuthorEmail     |
| *CategoryID    |           | AuthorTitle     |
|----------------|           | AuthorBio       |
       \|/                   | AuthorPicture   |
        |                    | AuthorSiteURL   |
        |                    | AuthorSiteName  |
        |                    |-----------------|
| CATEGORY            |
| CATEGORYID          |
| CategoryName        |
| CategoryDescription |
| SubCatName        |
| SubCatDescription |
| *CategoryID       |
I guess a short explanation of my terrible computer drawing is at hand. I'll stick to just the basics, and if anyone has any other questions, please don't hesitate to ask. Also, I don't know how good my translations are as I'm used to these terms in norwegian.

- * means foreign key
- ALL CAPS are either table titles or primary keys
- I've tried to draw the relations where the arrows mean "many" and the line means "one".

And, as said, if anyone has any questions in addition to this, please ask them.

Question #2:
The datamodel above assumes that large blocks of articles (chaptercontent) will be saved into variable. I'm a litt confused about the format of this text. Since there should only been content in these data fields and no layout, should there be a blank line separating the paragraphs instead of a HTML paragraph sign. Then one would have to write some kind of sub-routine replacing the blank lines with HTML pargraph tages before placing them into the HTML code to be delivered to the browser.

I'm a little confused about this layout vs. content thingy other places as well. What about forms for instance which would require a few HTML tags no matter what. And let's say that I wanted each heading in my articles to have a specific style. Wouldn't I have to define this in the "content" using for instance the CSS style property.

I guess the main question is: What is common to put in the database, and what can be kept out of it?

Question #3:
My last question for now concerns expanding possibillities. What if I, later one, find out that I need to add another table or two. Is this possible, or do I have to roll up my sleves and start to build the entire database from scratch? I'm asking because this sometimes works in Access and sometimes it doesn't.

Thanks in advance for helping out a database-programming newbie soon to become a pro.