Home/ Questions/Q 288601
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T05:49:56+00:00

I am creating a laboratory database which analyzes a variety of samples from a

  • 0

I am creating a laboratory database which analyzes a variety of samples from a variety of locations. Some locations want their own reference number (or other attributes) kept with the sample.

How should I represent the columns which only apply to a subset of my samples?

Option 1:
Create a separate table for each unique set of attributes?
SAMPLE_BOILER: sample_id (FK), tank_number, boiler_temp, lot_number
SAMPLE_ACID: sample_id (FK), vial_number
This option seems too tedious, especially as the system grows.

Option 1a: Class table inheritance (link): Tree with common fields in internal node/table
Option 1b: Concrete table inheritance (link): Tree with common fields in leaf node/table

Option 2: Put every attribute which applies to any sample into the SAMPLE table.
Most columns of each entry would most likely be NULL, however all of the fields are stored together.

Option 3: Create _VALUE_ tables for each Oracle data type used.
This option is far more complex. Getting all of the attributes for a sample requires accessing all of the tables below. However, the system can expand dynamically without separate tables for each new sample type.

SAMPLE:
 sample_id*
 sample_template_id (FK)

SAMPLE_TEMPLATE:
 sample_template_id*
 version *
 status
 date_created
 name

SAMPLE_ATTR_OF     
 sample_template_id* (FK)
 sample_attribute_id* (FK)

SAMPLE_ATTRIBUTE:
 sample_attribute_id*
 name
 description

SAMPLE_NUMBER:
 sample_id* (FK)
 sample_attribute_id (FK)
 value

SAMPLE_DATE:
 sample_id* (FK)
 sample_attribute_id (FK)
 value

Option 4: (Add your own option)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    To help with Googling, your third option looks a little like the Entity-Attribute-Value pattern, which has been discussed on StackOverflow before although often critically.

    As others have suggested, if at all possible (eg: once the system is up and running, few new attributes will appear), you should use your relational database in a conventional manner with tables as types and columns as attributes – your option 1. The initial setup pain will be worth it later as your database gets to work the way it was designed to.

    Another thing to consider: are you tied to Oracle? If not, there are non-relational databases out there like CouchDB that aren’t constrained by up-front schemas in the same way as relational databases are.

    Edit: you’ve asked about handling new attributes under option 1 (now 1a and 1b in the question)…

    • If option 1 is a suitable solution, there are sufficiently few new attributes that the overhead of altering the database schema to accommodate them is acceptable, so…

    • you’ll be writing database scripts to alter tables and add columns, so the provision of a default value can be handled easily in these scripts.

    Of the two 1 options (1a, 1b), my personal preference would be concrete table inheritance (1b):

    • It’s the simplest thing that works;
    • It requires fewer joins for any given query;
    • Updates are simpler as you only write to one table (no FK relationship to maintain).

    Although either of these first options is a better solution than the others, and there’s nothing wrong with the class table inheritance method if that’s what you’d prefer.

    It all comes down to how often genuinely new attributes will appear.

    • If the answer is “rarely” then the occasional schema update can cope.

    • If the answer is “a lot” then the relational DB model (which has fixed schemas baked-in) isn’t the best tool for the job, so solutions that incorporate it (entity-attribute-value, XML columns and so on) will always seem a little laboured.

    Good luck, and let us know how you solve this problem – it’s a common issue that people run into.

    • 0