Re: Mapping arbitrary number of attributes to DB
Date: Tue, 24 Oct 2006 10:44:09 -0800
Message-Id: <453e5201$0$19615$88260bb3_at_free.teranews.com>
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.
Thanks.
j
-- Joshua Kugler Lead System Admin -- Senior Programmer http://www.eeinternet.com PGP Key: http://pgp.mit.edu/ ID 0xDB26D7CE -- Posted via a free Usenet account from http://www.teranews.comReceived on Tue Oct 24 2006 - 20:44:09 CEST