Forum Moderators: phranque
Static:
Easy to set up and easy to host but may be labour intensive if common elements were to change. You could use templates or includes for common elements. It would require third party search options (atomz etc)
Dynamic:
More costly than static and a greater degree of experience required. Would allow for a half decent search option. The data is scaleable and more easily transported. It would be useful to get static urls, so a rewrite would be good. Probably would require at least MySQL on scalability grounds.
Mixed:
Best of both worlds?
If you decided that a dynamic option was the best how far would you take it? Just DB driven content or menus and the whole damn lot.
Is there a (personal) cut of point to when one should move from one to another or are there any figures such as:
100 page and 500 page views a day (recommend static)
1000 page and 10,000 page views day (database)
Cheers
If the 100 pages were likely to double over a period of time I'd go with the DB but still use templates for common elements, I see no reason why a menu needs to be data driven on the type of site I think you're talking about.
Time spent on the DB and admin interface will allow you to create much more content with much less hassle in the long run...
Nick
maybe that's lazy but theres not better way then being dynamic at the beginning. ;)
(i assumed your pages will change)
Dynamic:
More costly than static
I agree with you on everything in your post except the statement above. Even a $5 web host now will let you use at least an access database and probably a mySQL database without any extra charge (except for the space it takes up). You do need to know more, though, but you can pick up Dreamweaver UltraDev (a generation old now) for like $40 nowadays. With that, the code is sloppy, but it'll make the site and then you can go in and clean it up (and learn to do it yourself while you clean).
True, though, 100 pages that aren't going to change, just get more pages that never change added to them would be a template job for me. Head/Nav/Body/Footer includes.
G.
Andreas
IMO, the generation of the dyna-static pages must have the ability to select templates and mix and match domain paths (for multi-domain projects), includes, external css, and js on-the-fly at the record level during the page-building process as well as being able to specify the output file name and extension. I like to be able to manipulate the database itself in a spreadsheet, then just load it (or just sections of it) when there's a need to write/overwrite the pages. I've found this system to be easily scaleable up to 15,000 pages and it appears it'll go to 50k or more. After that, the problem becomes more of a publication management issue, as it's hard to keep track of everything that you're doing.
I have seen hosting where it costs more for mySQL, but it seems that is not always the case so I will look into that.
I was not thinking of an actual site at the moment but I do need to consider some of these ideas in only for a learning experience for when I do get that idea or get that job.
rcj:
Your post intereges me about "large" site maintenance. Do you know where I can read more on this or find some case studies.
mix and match domain paths (for multi-domain projects)
andreas:
I have thougth of an option like that but to me it seems a little wasteful. If I was able to build pages dynamically, i may as well do that rather than process the pages locally and upload. That said I know you are responding to my suggestion that DB hosting is more expensive.
Cheers
Other than here (and that's relatively skimpy), I haven't seen any. Large site management seems to be the place where webmastering merges w/ IT. (I see a few of the guys mentioning old mainframe db experience, for instance.) Seemingly simple issues like ftp from a remote management site become huge roadblocks. Even taking advantage of directories that offer deep linking becomes a problem. (I once had large deep-linking project approved by a directory --even with a macro writing the individual links it took a couple of loooong days to do the submittals.)
>>mix and match domain paths (for multi-domain projects)
>Do you mean 1 db with internal structure for more than one page?
Yes, and more. You might have some content segments that are appropriate for multiple pages on a single domain or even multiple pages on multiple domains in the same theme (think of navigation, a common trademark, or copyright includes, as examples).
You might also have a record that you don't publish on one page, a 3-part article might be an example. From a record management standpoint, you store the data in one record but it may be used to write 3 separate web pages.
All this starts moving into (or beyond, in my case) the realm of Content Management.
<added>
Oh, and access logs, forget about those. Huge! You're reduced to continually sampling and spot-checking.
