Object-oriented thinking in SQL context?

From: <dr.coffee1_at_gmail.com>
Date: Mon, 8 Jun 2009 08:46:03 -0700 (PDT)
Message-ID: <bf7e8cca-4cbc-4a8c-b452-1bacb4846b8e_at_g1g2000yqh.googlegroups.com>

Hi folks.

I have a problem with wrapping my mind into the 'right' wrinkles. I need to come up with a database design in SQL/MSAccess, since that's the tool that is available to me. The subject of the database is an inventory of electronic instruments, and the objective is to maintain a status log of these instruments.

The naive idea is:

  • Instrument ID
  • Instrument status (active / stand-by / inactive)
  • Instrument location (room / shelf / position)

The above ought to be valid for all instruments. Then there are a few instruments that need to be calibrated before use. These need to have some additional fields:

  • Calibration status ( OK / not calibrated )
  • Calibration data ( varies with type of instruments )

The problem is the latter two fields. Only a few instruments need to be calibrated at all; and the calibration data varies with the exact type of instrument. A microphone might need a gain factor from sound pressure to voltage; a GPS position sensor might need an (x,y,z) location plus orientation along three axes.

The above would be almost trivial to implement in an object-oriented context (well, this si my first attempt at databases at all - my experience is with OO programming), but I don't see how to come up with a table-based database design.

Any general ideas on how to design a SQL database around such constraints?

Dr. C. Received on Mon Jun 08 2009 - 17:46:03 CEST

Original text of this message