• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 392
  • Last Modified:

dividing table?

Now I'm having a table 'articles', with the following fields: id, title, article, author, score and counter. Would it be interesting to divide this table into two tables?
For instance:
articles: id, title, article, author
scoring: id, score, counter

where the two id's match?

What do you think?
3 Solutions
There are a couple of scenarios where this would be a good idea:

1/ If each article can have more than 1 score and counter.

2/ If you are likely to access the data from the articles table without the score/counter data often, or vice versa.

If each article has only one score and counter and you will be displaying this data simultaneously in most instances then no. Keep them in one table.
CWS (haripriya)Commented:
If you have more than one 'score' and 'counter' values for the same 'title', 'author','article' you can go for two tables, otherwise it is better to keep the same table for all the fields.

If you are having lot more fields in that table apart from these 6 fields, you can split the table. Or could you explain you decided to divide the tables?
jvuzAuthor Commented:
I'm thinking about it, because I'll also want to add a field where I'll put the number of visits of that article. And maybe in the future I'll want to add some other fields in. That's why I was thinking to divide the table already, so it won't be difficult if I want to add something in the future. For the number of visits, I was thinking to create another table. What are your ideas about that?
Depends on how much information regarding the visits you want to store. Ideally you could create a seperate table to log each individual visit with the IP address, datetime of visit, etc ... which will enable you to break the information down into visitors per day, unique visitors per day, per month, per year, etc, etc.

If you're just interested in "hits" on an article, then just add a "hits" field to the main table and increment it by one each time a new visitor comes to the site. This will entail much less overhead for your server, but of course it wouldn't be possible to categorise it as above.
to reinforce what has already been said:
don't split the tables

proper normalization technique is to only split the tables if you are going to have a many-to-one or many-to-many relationship. otherwise you are just adding in needless talbe linking on one-to-one relationship which slows things down.
for example, a coder wo previously worked for my employer created a database that contained 2 tables (among many others) for storing information on letters. one table contained the letter blob and creation date, the other contained the print date. now every time we want to get a count of unprinted letters, we have to query the 2 tables joined together, which is prohibitively slow with 100000 records (which many clients have), taking 15-30 seconds for a query that could take 1 second.

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now