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?
LVL 21
jvuzAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

under_dogCommented:
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.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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?
0
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?
0
under_dogCommented:
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.
0
netmunkyCommented:
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.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
PHP

From novice to tech pro — start learning today.