views:

25

answers:

1

Ive got a database that receives links and content related to a specific football club,and the way im storing the content at the moment is in 2 seperate tables,1 that stores the links and the details,fm_sources, and another that stores club specific information,fm_club, that will be used to run queries against the fm_sources content to find relevant infomation.

The question is,ive across an API that will virtually guarantee data that is associated with 1 club,would it be better for me to have a different table for each club with the rows being associated with the club on initial storage,this would allow me to use very simple SQL queries as opposed to massive LIKE comparisons as i used here. I could then simpley run a query like this

SELECT * FROM fm_liverpool ORDER BY created_date DESC LIMIT 15

This method would then require me to have multiple tables for each club but each table would replicate the same columns.

A: 

The normalization comment is correct: You would have one table for club names and information, one for fm_sources, and likely a third that links the two. You would need more tables should you get more data.

You shouldn't really have to do "massive LIKE comparisons" - at most one, for the football club look up name. Everything else should be JOINed by IDs.

ajacian81