Re: Object-oriented thinking in SQL context?

From: <cimode_at_hotmail.com>
Date: Mon, 8 Jun 2009 09:30:00 -0700 (PDT)
Message-ID: <a04d8622-4fc0-45f0-8568-7fa922f61230_at_h23g2000vbc.googlegroups.com>


On 8 juin, 17:46, dr.coff..._at_gmail.com 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