Wait, I'm still trying to wrap my head around why someone would even want to do the above? Things don't code themselves right? So at some point in time, some bloke was attempting to accomplish something, and I can't figure out what that might be given the method used.
A) have said yes, but have yet to actually sign papers on participation and have yet to answer the survey
B) have said yes and signed the papers, but have yet to actually answer the survey
C) have said yes, signed the papers but have an incomplete survey, as in having only partially participated
D) signed, participated, answered everything
Those who haven't done it all, will need reminders and the system creates reports each week for who remind and so on. This bloke created a myriad of different tables to keep these respondents in and moves them around from table to table depending on a, b, c or d.
I hope I made it easier to visualize lol.
Haha, okay. And forgive me if I'm not taking something vital into account, but wouldn't it have been like way easier to just throw all of these states into a separate table? I'm being a little frivolous with storage space here, but the separate table could just track ID (a meaningful one of course), the current state, and maybe a timestamp? That way it could also account for a person's change in state over time. Oh, and while we're at it, maybe introduce a few new columns to account for the multiple variables involved? Then we don't have to do something stupid like set up enum fields for every possible permutation.
Then the bloke could just run a query for all people whose last known state is whatever state they want to isolate?
It can't be this simple, I've gotta be missing something here.