User Story #843
ID for single cases and version: Rethinking concerning usability and robustness
Status:
Closed
Priority:
High
Assignee:
Lukas Vonlanthen
Category:
-
Target version:
Start date:
07 Apr 2016
Due date:
29 Apr 2016
% Done:
100%
Estimated time:
(Total: 0.00 h)
Resolution:
Description
We have two different ID's:$
- ID, which identifies a practice case (either approach, or technology)
- ID to identify a single version of a case.
- Postgres SERIAL:
- Advantage:
- Postgres can handle it perfectly
- Uniqueness is handled automatically by db
- user readible because it is a single number.
- Disadvantage:
- The ID ist generated in Postgres through an INSERT statement
- Problematic when data is generated in external or offline applications
- Only robust in single application setups.
- WOCAT code
- Advantage:
- Human readable
- different information condensed in one code (Country, config, number)
- Disadvantage:
- Code has to be generated in the application after a database query looking at existing cases. The workflow is: query -> code generation -> insert in database
- Thus not very robust in multi user situations
- Code is generated when questionnaire is written in the database. This could be a problem on long edit sessions.
- Problematic when data is generated in external or offline applications
- UUID
- Advantage:
- Very robust and approved, when cases are generated in distributed applications
- UUID can be generated on any application layer: client side, server side application, db
- Disadvantage:
- Not really usable for human interaction (too long).
- Therefore can only be used 'in behind the scenes': Backend, API, ...
Subtasks