NIH | National Cancer Institute | NCI Wiki  

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Scrollbar
icons

...

...

false

...

Page info

...

title

...

title

Panel
titleDocument Information

...

...

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

Revision History

Version

Date

Description of Changes 

Author

1.0

5/14/10

Initial Version Approved via Design Review

Team

This document describes use of a Single Database Table versus Multiple Database Tables. *Contract:* \[Contract number\] *Client:* NCI CBIIT National Institutes of Heath US Department of Health and Human Services Panel

titleContents
Table of Contents
maxLevel3
Column

Sign off

Date

Role

CBIIT or Stakeholder Organization

Reviewer's Comments (If disapproved indicate specific areas for improvement.)

 

 

 

 

 

 

 

 

 

Detailed Design

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.

  Image Modified

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

Code Block

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.

Scrollbar

...

iconsfalse