That's what @carlosms and I would propose

- Users # They're the actors of the platform
  - ID
  - github_username
  - auth
  - role # [Requesters|Workers]

- FilePairs # They're the questions of the experiments, where user compares two source codes
  - ID
  - name_A # path
  - name_B # path
  - hash_A # MD5, SHA1... of the content
  - hash_B # MD5, SHA1... of the content
  - content_A
  - content_B
  - experiment_ID
  - diff

- Experiments # They describe the experiments where user compares two source codes.
  - ID
  - name
  - description

- Assignment # It stores the user answers
  - user_ID
  - pair_ID
  - experiment_ID
  - answer # [Yes|KindOf|Nope|Skip|Null]
  - duration # seconds

Assumptions:

All Assignments are created when the Worker starts answering an Experiment, being Null the value of the answer, and 0 the time elapsed,
If a worker changes its mind, and answer again an Assignment, the answer will be updated, and the new duration will be summed to the old one (or updated too, if requirements changes)

Simplifications:

We tried to model the DB considering only what we want to build, avoiding more complex possibilities like making the FilePairs a subtype of Question, having same FilePairs in different Experiments so we'd need a crossing ExperimentFilePairs, and so on.

Schema design #2

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions