Lots of tables, or LOADS of rows?

[LemonInflux]

I'm designing an application that monitors page traffic. This application collects the user's ip, checks in the database whether that ip has seen this page before. If the ip has, it adds one to the IP's view count. If it hasn't, it adds the ip to the database. My table looks like this:

 

[pre]IP | HITS

---------

  |

  |[/pre]

 

So basically, this is how the data is collected. My question is this:

 

If I am monitoring several pages, do I just add a third column called 'page', and have a HUGE table containing possibly thousands of rows, OR, do I have a table like this for every page?

[tendrousbeastie]

I'd suggest adding a third column in the existing table, called something like 'pageID'.

 

Then add a second table that contains two fields, 'pageID' and 'pageName'. The pageIDs would then be relate in a basic one-to-many relationship.

 

This way you can change a page name (if a change is required) in only one row in the second table, rather than having to change it in each row in the main table.

[LemonInflux]

It was going to be an ID column. Sorry, should have made that clear.

[tendrousbeastie]

Yeah, I was stating the obvious a little. Sorry.

 

The other benifit of the method above is that you can much more easily add new pages at a later date, by simply adding a new row to the pages table (rather than having to make a whole new table the other way).

[LemonInflux]

So you're saying just have 1 huge table with loads of rows?

[tendrousbeastie]

I certainly would use one big table with lots of rows. Much easier which ever way you look at it.

[Stopofeger]

loads loads loads of rows. fewer tables.

cause rows are flexible, tables are not.