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.