Re: Object-oriented thinking in SQL context?

From: <>
Date: Mon, 8 Jun 2009 09:30:00 -0700 (PDT)
Message-ID: <>

On 8 juin, 17:46, wrote:
> 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.

Before doing any database design, you need to define first your problem in a way you are not accustomed to. OO thinking is too sloppy and imprecise to be easily transposed to database design. Received on Mon Jun 08 2009 - 18:30:00 CEST

Original text of this message