Author: Craig Stancl
Email:

Stancl.craig@mayo.edu

Team:

LexEVS

Contract:

CBITT

BOA

Subcontract#

29XS223

Client:

NCI

CBIIT

National

Institutes

of

Heath

US

Department

of

Health

and

Human

Services

 \\ | Initial Version Approved via Design Review | Team \\ |


This document describes use of a Single Database Table versus 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.

!Registry.jpg|alt=registry diagram"!\\

Prefixes are automatically injected into SQL statements to direct the SQL to the appropriate table. For instance:

{code}
SELECT FROM $prefix$entity WHERE ...
{code}

{scrollbar:icons=false}