Best way to organize tutorials

As most of you already know, I have started a win32 tutorial website called From the Ground Up. I am planning on adding some tutorials to the site today, but was wondering what would be the best way to organize the tutorial system and was looking for some input from other people here.

There are a few ways i've thought of doing it:

#1) Have links to each tutorial statically coded in to the site
#2) Have an sql database of all of the tutorials which contains links to each of the pages.
#3) Builds off of #2, but has each tutorial physically IN the database, making it so you could possibly submit your own tutorials quite easily by typing them up and having them posted in to the queue, much like I handle the news system at this point.

Also, methods 2 and 3 have many advantages, including being able to search the posts and have specific keywords that apply to certain tutorials, whereas method 1 would require a lot of file handling and reading extra information that isn't needed.

So any input, any other methods would be great. I'm looking right now at method 2 as probably the best choice, as it would make it much less of a hassle for adding new links and things whenever I add a new tutorial.

-Thanks in advance for any input

PS- I'm also looking for someone who is good with art and webdesign to possibly draw up a better layout for the site? The design I have right now is incredibly basic and kind of boring (but that's how I am with webdesign, I can code it really nicely, it just won't look pretty to the end user, heh)

So if you want to see the current state of the site, check it out here:
http://ftgu.TheJeffFiles.com/

option 3 definatly. but if you have user submited articles, yo should seperate them or the new user might get swamped with usless info

ok, I think I will go with a version of #3, but instead of storing directly in to the database (which would be more of a hassle than anything) I'll have the tutorials themselves stored in a file elsewhere and when you want to view them it just places them in to the site's layout automatically. Also, for searching I'll just make it so you can scan the files themselves, shouldn't be too big of a problem and if it is I can change it.

Also, I am thinking of writing a script much like I've seen on other sites where users can submit replies/comments to the tutorials and give feedback basically.

putting the entire tut in the DB could be quite slow.... im no web guru but ive heard links in the DB is a faster approach. of course, if you want to support people committing tuts without you having to post it thats probably the best way.

that's why i was going for decision three, but now i actually did a combination of #2 and #3. I have two databases, one with the tutorials, links to them, hit counters, keywords, etc...another one that contains all of the posts, and each post basically points to the tutorial that it is there for. This allows me to not have to have a separate database for each one, and it works nicely :)

why not just use a wiki ??

Ok, here is how I would do it:
Id store member information (if you choose to allow people to register to the site) like there member id, date registered, number of submited articles, posts etc all in one table dedicated to member information

Id store the article itself and its relevent data in another table. Article id, who posted it, when, how many replys. This table would have two foriegn keys:
Other articles related (articles per compiler? or next step in complexity articles etc.)
Downloads for the article - source code, pdf version of tutorial etc. etc.

Then id store all messages in a table. The message would contain its id, who posted it, when, etc. It would have two foriegn keys.
who posted it
and the article it was posted to

id store download links in the last table. It would contain an id, and the direct url to the file.
You would have to create your own upload scripts to mannage the upkeep of this table of course.

table_message
m_id | f_a_id | poster_id | date_posted | content | etc.
m_id would be the primary key for this table. AUTO INCREMENT int. It is merely an identification number of this specific post
f_a_id would be the foreign key that defines what article this message is related to.
poser_id would be the id number of who posted the message, -1 could represent guests (if you allow anon posting)
content would be the content of the message posted. and etc. could represent any aditional information you want to contain about message and message replys

table_articles
a_id | f_d_id | f_r_id | poster_ids | date_posted | article | views | replys | etc.
a_id is the article identification number PRIMARY key AUTOINCRIMENT int
f_d_id would be the foreign key to a download id from the downloads table.
f_r_ids would be a forieng key of comma seperated related article id's.
poster_id is the id number of who posted the article
date_posted when it was posted
article is the actual article itself with in the database
views is counter
replys the number of messages posted related to the article

table_downloads
d_id | file_url
d_id is the download identification number, PRIMARY KEY AUTO INCRIMENT int
file_url is the link to the .zip file (or what ever format) to be downloaded.

table_members
id | name | password | date_registered | personal info fields .. | ..| ..| rating | etc.
id is the personal identification number of member PRIMARY KEY AUTOINCRIMENT int
name is the name of the member
password is his password to log in
the rest is pretty self explanitory


As far as the concern about storing the article in the database being slow.
Its actually quite fast. Just think, all the posts of this message board are stored in the database, and it isn't slow to come up with all the text when its queried. It's silly to have seperate text files for each article. Its also a lot more of a pain to manage ftp wise. If you have 48 articles, and 2 to 3 variations per compiler.. Thats a lot of pages to have to keep track of in directorys.

yah, that's basically the way I have it set up at this point, minus the user settings and whatnot. I don't think I'm going to have user accounts unless there is a good-sized community of people who'd be willing to send in tutorials, because otherwise it would be more of a waste of time than anything.

Thanks for the input though, I'll definitely take some of that info in to consideration!

Nice idea, nice site.
Hope you stick with it :)