parts of HTML static, others dynamic - PHP or HTML - best way to lookup database

I am creating a website for products. I am wondering: is it better to use a single dynamic page using PHP, or generate an HTML page for every product, updating the pages from a php template file in a cron job? Most of the material on the page (eg. basic product information) will not change over time , but other parts of the page will be generated from database lookups (inventory, reviews, etc.)

I have heard some people arguing that it is better to have static url's (eg. category/product1.html) instead of dynamic ones (eg. products.php?id=1234) for SEO purposes. The problem I found with the former method is that it seems inconve开发者_StackOverflow中文版nient to do database lookups from an HTML page. The way I implemented it was using javascript->php:

<script type="text/javascript" src="http://localhost/inv_lookup.php?UPC=<?php echo $UPC; ?>"></script>

But then in the PHP file, you have to print javascript-formatted text:

    echo "document.write(\"" . $field . " : <b>" . $row[$i] . "</b> <br/> \")"; 

This kind of DB lookup seems sloppy to me. Any suggestions?

There's no reason you can't do it as a single .php file. With the appropriate mod_rewrite rules, you can dynamically remap a example.com/products/1234 into example.com/product.php?id=1234 URL internally.

And if you really hate exposing PHP, you can always configure the web server to treat .html files as PHP scripts (AddHandler php5-script .html).

As for printing "javascript-formatted text", it's easier to use JSON to do "formatting" for you:

<?php
    $product = array('name' => 'Deluxe Widget', 'id' => 1234);
?>
<script type="text/javascript">
    var product = <?php echo json_encode($product) ?>;
    document.write(product.name + ': <b>' + product.id + '</b><br />');
</script>

1) Don't update static html pages with cron and php. thats just crazy talk.

2) Use heredoc syntax if you want cleaner variable interpolation:

echo <<<EOF
  this is a {$row['0']} and a "$varable" for  you. oh yeah don't forget the '
EOF;

Suggestions:

1. Indeed storing & serving a page as plain HTML is very resource effective.
2. Ideally, there should be no part in the URL showing any language or implementation (no .asp, no .php, no .cgi, no .html). That way, you can switch at will, and every part of your URL is to the point for the resource you are viewing. Look into apache's mod_rewrite and the like.
3. As you noticed, some parts are more volatile then others, so storing content 'parts' (main navigation, product description, reviews) etc. separately is advisable.
4. Cron jobs are most likely not going to cut it. When someone alters a price in the backend, the frontend should show that as soon as possible. Creating hooks to invalidate / recreate content on change are going to make your life a lot easier.
5. Most likely you still want some barebone php script on the frontend, which concatenates are your separate caches, and is possibly able to create an html portion on the fly when a cache isn't available.

As a final suggestion: I'd peek at what major frameworks, CMS's & eCommerce solutions implement as a cache, there are a lot of errors you can make, and most are already solved.