A dimension value can be designated as ”triggers numbering”. When that dimension value is added to a response, the response receives the next unallocated number.
Pros: automatic allocation of numbers, happens precisely at the correct time (when expense claim is approved)
Cons: rather specific, difficult to envision other use cases that could use this, conceptually difficult
Always give each response to a survey a sequential number that is consecutive and unique within that survey.
Pros: conceptually simple, may have other uses as well (easy to determine who came before whom)
Cons: holes in numbering for rejected expense claims, somewhat involved to implement (can't use GENERATED ALWAYS AS IDENTITY or SERIAL, for some speed contest use cases collisions might be a thing)
Change the primary key of Response from uuid to integer
Pros: conceptually simple, clean URLs
Cons: guessable, holes in numbering at responses to other surveys and rejected expense claims, does not start at 1
Number rows in the response view (not realized into database)
Pros: dead simple to implement
Cons: numbering is dependant on filters, permanently deleting a response causes later numbers to shift
Add an option in Survey that generates bank reference numbers for each Response
Pros: Might have usefulness in other use cases as well, where invoices are sent to people signed up via a survey
Alternative ways of implementation:
GENERATED ALWAYS AS IDENTITY
orSERIAL
, for some speed contest use cases collisions might be a thing)uuid
tointeger
Slack discussion