My mental image of your database schema is that you have one table for each Vhost, with location, hits, and perhaps modification time columns. If it's normalized, you might have a hosts table with a host_id, and a locations table as described before, but with a host_id which can be used to join on the hosts table.

Actually, the schema is one table for vhosts, one for locations, and one for hits.

The location table has a vhost_id column (as a foreign key) and the hit table has a location ID linked as a foreign key.

Additionally, although I'm not sure of the wisdom of this move, since locations can nest, I have a 'parent id' linked as a foreign key within the location table (i.e. a location can have a 'parent' ... this way I can keep track of hits to a directory that aren't hits to the particular file).

All this is supposed to be user-configurable (the various admins of the various virtual hosts can set up which locations they want reporting on)

If this brings to mind any further ideas about design, etc. I'd love to hear it.

Thanks to all who've replied so far!

Philosophy can be made out of anything -- or less