1. Original schema
1.1. Experiment database
1.2. List of available experiments (separate database schema)
2. Refined schema (step 1)
2.1. Experiment database
- there is no intervals table anymore
- redundant columns in
entry
table where removed scheduler
table no longer keeps info related to MDSPlus
based notation of source dataentry_data
contains column for holding complex data
3. Refined schema (step 2)
3.1. Experiment database
- complex types are stored as real and imaginary
- variables contain
ids
in the name instead of cpo
4. Refined schema (step 3)
4.1. Experiment database
- scheduler table is now called request
- all the plural names of tables were changed to singular ones
- all the indexes are now unified (naming convention is the same across all the indexes)
5. Refined schema (step 4)
5.1. Experiment database
- request table no longer holds URI for the data entry
- there is a new table: experiment. This table contains location of data we are working with. As we may have multiple requests for a single experiment (e.g. update of the data) I want to keep URI in separate table.
- entry table is now linked with request - this way it points to the experiment (via request)
- There is a new table: replace - this table will contain information for tracking additional info (as described in Proposal on Metadata Schema Standardisation and Mapping Existing Schemas)
- There is a new table: reference - this table will allow to store multiple DOI (maybe something else) related to a particular entry
- There is a new table: tag - this table will contain all the tags defined by users
- There is a new table: tag_entry - this table will contain all the links between: user, tag and entry; this way it will be possible to track who has tagged entry with given tag
- Removed: machine table is no longer here. Do we really need it?
6. Refined schema (step 5)
6.1. Experiment database
- auto increment for all ID fields in database
- further unification of fields (all primary keys and foreign keys are represented solely by INT)
- further cleaning of indexes
7. Refined schema (step 6)
7.1. Experiment database
- all text fields are now represented by VARCHAR (it's still a subject to change)
- using TEXT as type of column lead to strange issues in some of the SQL engines (e.g. H2)
8. Refined schema (step 7)
8.1. Experiment database
- table replace was renamed to entry_replacement - by accident, we have used reserved word
9. Refined schema (step 8)
9.1. Experiment database
- There is a new table:
variable_type
- it describes possible types of the variables - Inside variable table, there is no longer
variable_type
column. Instead there is a foreign key (variable_type_id
) that points at variable_type.id
- There is a new table:
request_status
- it describes possible statues of the request - Inside request table there is no longer
status
column - instead there is a foreign key (request_status_id
) that points at request_status.id
10. Refined schema (step 9)
10.1. Filter table
- There is a new table: filter - it allows to store custom user filters
- There is a new table: user_filter - it allows to link filter with user; it is possible to share filter between different user - this is why filters require linking table between user and filter
11. Refined schema (step 10)
11.1. user_filter
- There are fixes inside user_filter table
- There is a new explicit ID column
- relations are non-identifying (user - user_filter - filter)
12. Refined schema (step 11)
12.1. experiment_description
12.2. VARCHAR to TEXT
- all text fields are now represented by TEXT fields
{"serverDuration": 110, "requestCorrelationId": "36b96b58d8931367"}