The token_id is a leftover, since before the CPDB we used that to connect to the tokens table. I would be cautious about removing it, since there are probably links, and as far as I recall, there is no requirement to use the CPDB for every survey - can't you still run a survey with just it's own stand-alone tokens table?

Jason, you might have misunderstood: The question was if to remove the token_id column from the "survey_links" table?

Don't use cpdb myself, but when token table is removed or changed there should still be a reference. So make sure to use a left join to the token table and handle the missing data correctly.

I can see how it is redundant, but if you were just doing a join between the CPDB and the tokens table for a survey, then without it you'll need to also join to the responses table, so it may be false economy to remove it.

I am sorry, I don't understand: Why would I also need to join to the responses table?

If you take another link at the survey_links table you can see that the fields
date_created
date_invited
date_completed

are redundant, too. If we remove these fields we would know in what token tables the participant would be - but to get specifics we would need to lookup each entry in the particular tokens table. I think this only matters if the participant is part of a huge number of surveys - and only if someone really opens up the participants grid and looks at the details of a participant.
Also currently them same participant cannot have several token entries in the same survey (so there is no problem either).

Comments?

At design time I was hoping we could allow multiple participants in the same survey, but that was for another time. I see no need to remove the field, it has low overheads, and it has possible future use.

The other fields you mention were also added so that there would be specific information about when the participant was joined / invited to a particular survey. It is supposed to be a reference to the action of joining a participant to a survey. It should relieve some database overheads for commonly required data in the CPDB screens.

If you want to drop them and gather the information by doing joins with other tables, then so be it - but I think given the size of the tables that may be joined, you'd just be adding overhead to frequent calls.

But afaik they are not frequently called. Just once when I open the detail view for a user in the CPDB grid? I also see no other uses in the source code.

What's bothering is the redundant data - it is easy to forget to update it when you update the main tokens.

Let's just put this in 2.10 where the database will get reworked anyway.