Re: Mapping arbitrary number of attributes to DB
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Tue, 24 Oct 2006 23:34:07 +0200
Message-ID: <453e8643$0$324$e4fe514c_at_news.xs4all.nl>
>
> Well, that is almost exactly what I had originally. :) See:
> http://groups.google.com/group/comp.databases.theory/browse_thread/thread/78267e0f38faa5c9/d24f8dcf6619342b
>
> 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.
Date: Tue, 24 Oct 2006 23:34:07 +0200
Message-ID: <453e8643$0$324$e4fe514c_at_news.xs4all.nl>
Joshua J. Kugler wrote:
> Bob Stearns wrote:
>> Joshua J. Kugler wrote: >>> So, I guess stated another way, forget about those files...how 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:
> http://groups.google.com/group/comp.databases.theory/browse_thread/thread/78267e0f38faa5c9/d24f8dcf6619342b
>
> 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