views:

36

answers:

1

I'm designing a plugin for a high traffic forum. What I am doing is listing related threads using a search API, which has a maximum of 800 searches per day

What I'm wanting to do is create a database to store the results, cache them for one day so it will be used instead of the API.

Would a table layout such as this be optimal:

Table:
+---------+-----------+------------+
| threadid | relatedids | dateentered |
+---------+-----------+------------+
|   129314 |  1124;2144 | 1234567890  |
|   124129 |  1251;1241 | 1234567890  |
|   185292 |  1151;5125 | 1234567890  |
+----------+-----------+-----------+

related urls being thread ID's too, separated by colons. I am not too much an expert in SQL so I do not know if setting index to threadID is a good idea, or what!

+3  A: 

You clearly have a one-to-many relationship here, so you should use 2 tables instead of a separator, something like (MySQL syntax, assuming there is also a table named thread) :

create table search_thread (
   thread_id int,
   date_entered datetime,
   PRIMARY KEY (thread_id)
   FOREIGN KEY (thread_id) REFERENCES thread(thread_id));

create table search_results (
   thread_id int,
   result_id int,
   PRIMARY KEY (thread_id, result_id),
   FOREIGN KEY (thread_id) REFERENCES search_thread(thread_id),
   FOREIGN KEY (thread_id) REFERENCES thread(thread_id).
   FOREIGN KEY (result_id) REFERENCES thread(thread_id));

The benefit of this model is that it's open to extension, meaning you can add an attribute specific to the related threads. Also, you can perform some queries that are not possible with your approach, like finding how many threads are related to another (in both directions).

Damien