Database-driven web content

devoir

I'm toying with taking a crack at a custom news/content website as a means of learning the finer details of PHP, databases and dealing with dynamic content.

One thing that's given me pause for thought as I've been designing this in my head is how to handle the actual pages themselves. An example would be the front page, which would be loaded with a bunch of database-stored news item (probably 50-75). Why would this be dynamic, as in re-created everytime a person loads the page? As opposed to having the page stored as a one-time generated HTML file that is updated only when say a new object is inserted in the appropriate table (forced by the actual submission page).

Please bare in mind I've only ever touched database-orientated web development very briefly before, so these might have obvious answers to people who are experienced. I'm coming at this from someone who basically sysadmins servers and networks for the most part, and I'm trying to diversify my skillset a bit.

Box

Joomla.

devoir

Part of the whole point of this is not to rely on already developed software. I have taken a look around, and I'm not going to really learn that much PHP/database-wise, and none of the software appears to be geared towards what I want to do. If I am going to put effort into customising it, I'd rather put the effort into coding it and learn more along the way rather than just be adept at fooling about with the templates of another system.

That, and it didn't really answer the question. But thanks for the tip, I might be able to learn some design stuff from it.

Q_Prime

the reason it'd be dynamic is because it's easier to program . i mean your system works. it just seems like a bit of a hassle. especially for administrative functions. if you write the page dynamically, you can have a delete button right on the entry, or you can load the news items in text areas so that way you could instantly change something. i mean these are just novel ideas but it's much more convenient when you look at modifying the data pulled from the database.

devoir

I get what you're saying. But from a database load and general website performance point of view, if you took the extra effort to generate these static pages, which then had hooks back into the database for functions like editing, etc.?

It might be that I just don't know enough about PHP and database handling to see the problem, but can't you write the static page with hooks back into where the data originated from? So let's say I have an index page of all one-line news items, and I wanted to have a web 2.0 style sliding box open up underneath with the actual detail - isn't it possible to write your PHP so that when it generates the static page it'll create the appropriate database call to operate behind that 'reveal more' clicky button to give the additional content?

That way you still have the web 2.0 goodness and functionality, but if someone is just browsing, every page view they pull isn't a hit on the database. Yes/no?

Fristle

I don't know if a 100% home-made PHP website with user-controlled input is the best idea security-wise, especially if you're still learning the ins and outs. But hey, I guess no better way to learn.

devoir

There won't actually be any user controlled content. It's like a really specialised blog that may allow users to alter how they view the content.

Q_Prime

http://www.tizag.com/phpT/filecreate.php

It's entirely possible. i myself would not bother with that, because the added load of db queries vs the work required to write static pages. i rather let the db do the work. but if you need to improve responsiveness or just want to experiment then by all means give it a try.

i don't see how the dynamic content would be faster by a noticeable degree. but i haven't taken the time to test it. i'm when preforming large queries involving thousands of results it would be a great improvement but for a news site i'm not sure. but don't let me discourage you. it does sound like a good idea and it will give you a speed boost, i just have no idea how much.

devoir

Q_Prime wrote: »

http://www.tizag.com/phpT/filecreate.php

Thanks! As you've guessed, I've got virtually no PHP-specific knowledge, but I do know programming and databases in general.

It's entirely possible. i myself would not bother with that, because the added load of db queries vs the work required to write static pages. i rather let the db do the work. but if you need to improve responsiveness or just want to experiment then by all means give it a try.

I guess it's just the OCD in me, if it can be made better, it should. And it's a ridiculous dream, but it's the kind of concept that could see bucketloads of hits a day. Even if this version/content doesn't, I can always take the software and try another market.

i don't see how the dynamic content would be faster by a noticeable degree. but i haven't taken the time to test it. i'm when preforming large queries involving thousands of results it would be a great improvement but for a news site i'm not sure. but don't let me discourage you. it does sound like a good idea and it will give you a speed boost, i just have no idea how much.

It just seems a little silly to have the same content pulled from the database over and over again (front page, containing 100 or so rows of a given table) when the content in the database itself may only get updated every 10-15 minutes. A static page, from from I understand, generally induces less load than a database call. Now imagine if you're running this all on the one box. This means that the database is in effect doing nothing except when it is updated, which means your single box should be able to handle more webpage requests at a faster rate.

If you think a little bit further along the track, with separate database servers and webservers, you would in effect end up being bottlenecked by your webservers faster than your database servers. At least based on my theorycraft.

Anyway, thank you very much. Even if it doesn't work as I expected, at least you confirmed that the basic theory is somewhat sound, and made me think a bit more critically of the idea.

Lewisham

While all this is theoretically true, you aren't building a scalable web site. You aren't handling thousands of requests a minute. There is no need to generate anything statically.

The database going to respond very quickly on simple SQL statements. The number of rows is irrelevant if the SQL query is just one extracting stuff out of a couple of tables.

I doubt you will see any speed increase at all, maybe a couple of milliseconds.

You're trying to solve something that isn't a problem.

devoir

It is an experiment. I didn't say there was a need, I was saying that if it could be done, I wanted to try it.

I _know_ that it isn't going to make a difference right now.

Janin

Using statically generated HTML is called caching, and it can be one of the more complex parts of a page. If I were you, I'd worry about generating purely dynamic pages before anything fancy.