"
Author: Traci St.Martin/Craig Stancl
Email: stancl.craig@mayo.edu
Team: LexEVS
Contract: [Contract number]
Client: NCI CBIIT
National Institutes of Heath
US Department of Health and Human Services
Sign off |
Date |
Role |
CBIIT or Stakeholder Organization |
Reviewer's Comments (If disapproved indicate specific areas for improvement.) |
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Detailed Design
Return to design document https://wiki.nci.nih.gov/display/EVS/LexEVS+6.0+Design+Document#LexEVS6.0DesignDocument-DetailedDesign
Single Database Table vs. Multiple Database Tables
LexEVS 6.0 will include an option to load CodingSchemes into a single, common set of tables, or individual sets of tables for each CodingSchemes. Some considerations for each option:
- Single Table Advantages:
- Limits Table proliferation in the database.
- All Coding Schemes centralized into one table.
- Single Table Disadvantages:
- Possible performance penalty. A query will be executed against the common table, which will be many times larger than the ontology loaded as an individual table.
To the underlying API, the actual table that data is stored in will be abstracted. All queries will except a Prefix -- whether that prefix is from the common table, or from an individual table, the query remains the same.
The prefix will be stored in the registry table of the database. The prefixed is then obtained given a CodingScheme URI and Version. Every CodingScheme will be loaded in the Registry, and the prefix will be retrievable given its URI and Version.
Prefixes are automatically injected into SQL statements to direct the SQL to the appropriate table. For instance:
SELECT FROM $prefix$entity WHERE ...
Prior to the execution of the SQL statement, the '$prefix$' placeholder will be replaced with the actual prefix retrieved from the Registry.
