Dynamic Database or Static?

What benefits does each offer over the other?

[Sharron]

Can I start by apologising by posting this wice, but I was looking t something in another forum and posted this while I was there - but I don't think the forum was relevant - sorry..

Does anyo1 have any advice or strong preference to use a dynamic database driven site over a static one?

I am aware that using the data base approach is more suited to vast product lines, and have had also been advised that it’s a bit quicker than a static site. I am however concerned about the fact that SEs can’t read any of the data because there is no page for it to crawl..

As the SE can read the static pages I am assuming it should help improve ranking as the Spider will have access to the product information that would include keywords. BUT…. I have also been told that the spider will only crawl the first 100 characters of the page which would mean it isn’t accessing the additional information therefore giving no ranking benefit and taking out any advantage that I know of for static over dynamic database.

I am loath to follow any route that will discount any legitimate method for an SE to access keywords and have no reason to prefer one method above another apart from the SE friendly aspect.

Any suggestions on which side of the fence is best?

[Nick_W]

Hi

It's a question of horses for courses. If you have vast amounts of products then a DB solution would/could be a huge benefit. SE's have no problems crawling these pages if you make provision for them.

On the other hand, static pages are easier to tweak individually.

I build DB driven websites and they're great for some things but my latest project is static pages because I need to tweak unpredictable elements on the page. For example:

If the product just has a title, description, price. then a DB would be great. But if you need to add odd bits and pieces then static pages might be better.

Nick

[mattur]

I am aware that using the data base approach [is] a bit quicker than a static site

Generally speaking a static site will always be quicker than a database driven site - the web server has less to do to deliver a static page, and static pages are more cacheable by default (though you can change the cacheability of any type of page).

I've done some sites where the pages are "semi-static": all the (slow changing) product content is in an offline database which is then used to programatically create the static html files offline, and these are then uploaded to the web server.

Doing it this way means you get the best of both worlds and you can move to a fully dynamically-generated site using the same database at a later date if you need to.

[brotherhood of LAN]

Sharron,

You will have probably read people worrying about things like ? and & appearing in their dynamic URL's, but that will not be a prob if you choose to go down the dynamic road. There are many ways to get round it.

All in all, basically what Nick said- bigger sites are more suited for db's, small sites/bespoke pages are more suited to static IMO

DB's are great.

Consider what you think your site will be like in 12 months....and if you choose to go static, consider that one day you may "need" to go dynamic via all the maintenance you may have to do if you are using a static layout.

[Crazy_Fool]

databases are great, especially if you need to change content quite a lot. if you write the script properly, it can generate all the page content, links, titles, meta tags, mouseovers etc for you dynamically - that is far easier than doing it all by hand for each static page. adding a new page is as simple as adding a new row to the database. need to make a design change on the site? one simple change to the database script will change all "pages" on the site in one go.

each "page" in a data driven site has a unique url with ? and & and = sybmols. search.asp?page=1 is a different url to search.asp?page=2 and so on. search engines will identify these as being different pages just the same as page1.html and page2.html. remember that whatever script you use will generate HTML for the browser - what the spider sees is that HTML output, which is no different to the HTML on static pages.

most search engines can spider database sites with ? and & and = in the urls with no difficulty. use no more than 2 name=value pairs. do not put session IDs in the urls. if you use linux / unix web server, then you can also use mod_rewrite to change urls so that you can use:
search/xyz/123.html
instead of
search.php?this=xyz&that=123
or something similar (best to look in the perl / php forum for more information).

dynamic sites may be slightly slower than static HTML sites, but the difference is normally negligible and most people would not notice the difference. webmasterworld uses a database of some form or another to store all message content yet it works very well and very fast.

now if you can tell us a bit about your site, maybe we can say whether using a database is a good or bad idea for your site.

[ukgimp]

If you dont have thousands of lines you ay wish to consider actinic.

I set one up recently. It creates the catlogue locally in HTML and then you upload it. I can say 100% that is it crawlable. Google goes nuts for it and I have had scooter milling around in the deep pages.

I get regular deep hits to particular product sections.

.Easy to set up, cheap and crawlable. Just bear it in mind as an options thay "may" suit.

Cheers