static web page vs database

[mpevah1]

I'm debating on how to create some css pages. the data will almost never change but will still need the ability to do so. now I'm wondering if I should just write a script (this is all on ASP and SQL )that will create/update the css page if the data in the database changes. Or I can have the css page dynamically created with the info from the SQL server.

These css pages are gonna be very small, I wouldn't be concerned about the disk space. I'm more concerned about all the calls to the SQL server.

Any ideas?

[uncle_bob]

If the rest of your site is asp pages, getting their content from the database, then you may as well have the css file created dynamically as well. If most of your site is static html pages then it would make sense to use a static css file, that is only changed when you infrequently change the data.

I always try and go for a consistant approach, so everything on the site works in the same way. Having to remember special cases is going to cause problems when you forget.

[mpevah1]

Thanks fellow new user,

I guess since I don't have too much formatting being done I'll just make them little inline style sheets.

[mep00]

Your best bet might be to try to make one global CSS page (or at least a very small number). You can use body id's for exceptions (an ingenius idea I found here on a CSS thread). Static pages are always faster than dynamic pages. Also, dynamic pages may have problems with chaching.

One of the beuties of CSS is that fron one page an unlimited number of other pages can be styled. If you have as little CSS as it sounds, you're probibly not using CSS to it's full potential (even considering the limitations of most modern browsers).

[Avitar]

I agree with mep00: You should use external global style sheet(s) for your site. That way you can more easily modify your site.

Static Pages have advantages most importantly: Lower processing overhead.

I have always been a strong beliver in keeping data seperate from code, therefore database everything possible.

SQL calls are relatively fast, so my general rule of thumb is: If you had to change it more than once, it should be in a database.

My general concept for big and small sites alike should be: Keep Data, Server Processing Code, and Presentation Code Seperate. It takes a bit more time to serve up the first page, but in the long run it will take less time to serve up successive pages if you designed a good site. The more seperation of datatypes the easier it is to organize, modify, locate, and add content. This means seperate:

ASP/CGI/PHP/JAVA/etc. Files for server processing.
external Oracle/MySQL/MSSQL/ect. Database
external *.xml configuration files
segmented *.xml RSS feeds
external *.css sytle sheets
external *.js javascript modules
with a very small *.html bow to tie all the code together.

You will get slammed by the harsh realities of web development if you don't do it right from the get go, regaurdless of the site size.

Be clever, plan carefully, embed the minimum amount of code possible at all times.

[SEO_Sucks]

try DB2HTML?

can build a 40,000 page site in 30 seconds...
can be easily updated...
can build static pages in different formats... (htm, html, asp, xml, etc...)

easy and effective? possibly?