So in this lovely new module, I have an auto-increment table for the proposals that will be entered. All well and good, except that some of the proposals are going to be re-submitted in the future, because people may be asked for more information. Both proposals need to be available but linked.
If we were doing this by hand, we'd just call them 110 and 110R. However, that breaks down on the auto-increment level.
Any thoughts? The only thing I can think of would be a "resubmitted" table, and just do a couple of queries to get all the proposals. Or something like that. I'm drawing a total blank. Probably a symptom of it being Friday. :)
[23]Posted: 26.02.2005, 02:51
[24]
rank:
Helper
registered:
February 2003
Status:
offline
last visit:
11.06.08
Posts:
226
I would add a second field called something like base_proposal. In your example above the original proposal would have zero in the base_proposal field and the resubmitted proposal would have 110 in the base_proposal field. No change to the auto-increment logic. This would tie all of the resubmitted proposals to the original.
[28]Posted: 26.02.2005, 03:23
[29]
rank:
Legend
registered:
December 1969
Status:
offline
last visit:
01.12.08
Posts:
6533
Either that or allow for "resubmit" on the proposal, and use a revison field to store which revision it is.