Re: Mapping arbitrary number of attributes to DB

From: mAsterdam <>
Date: Tue, 24 Oct 2006 23:34:07 +0200
Message-ID: <453e8643$0$324$>

Joshua J. Kugler wrote:
> Bob Stearns wrote:

>> Joshua J. Kugler wrote:
>>> So, I guess stated another way, forget about those might I go
>>> about (or where might I read about) mapping an arbitrary number  of
>>> attributes to a database in a clean, efficient way?
>> What is wrong with a model like:
>> Station(stationid, location, name, etc)
>> Instrument(instrumentid, datatype, rangemin, rangemax, etc)
>> StationInstruments(stationid, instrumentid, positionininputstream)
>> Recordings(stationid, instrumentid, recordingid [maybe a timestamp],
>> value)
>> When new instrument types come on line new Instrument rows are added. If
>>   instruments deliver non numeric data, then the simple (rangemin,
>> rangemax) will have to be extended in fairly obvious ways.

> Well, that is almost exactly what I had originally. :) See:
> I just wondered if there were better ideas. :) Maybe that is the best idea
> after all.
> I also have toyed with the idea of putting each set of readings in a list
> structure, serializing it, and inserting it into the database. Is that
> ugly? Yeah, probably, but *it fits requirements* because all we really
> need to be able to do is store/retrieve by time/date...searching for
> specific values isn't really a part of the system; getting at a set of
> readings by time/date is. So, we'll see. I'll talk to the stakeholders
> some more and get them to determine exactly how much searching they want
> vs. straight retrieval.

(Try to) Establish /specific/ information needs - not a description, but real examples. Starting from those needs you can work your way back to the (real) facts you will need to capture.

Typifying those facts gives you a good starting structure for your design. Received on Tue Oct 24 2006 - 23:34:07 CEST

Original text of this message