Re: Mapping arbitrary number of attributes to DB

David Portas wrote:

>> Thus, each
>> station can have a number of attributes that vary from one to dozens.  I
>> can't tell the scientists "You may have 32 sensors per station, no more,
>> no
>> less."  That just won't work, for reasons I hope are obvious. :)

Sorry, I didn't mean to suggest that anyone did...just thinking out-loud I guess.

> So you'll need attributes for Wind Speed, Temperature, Humidity etc.
> Obviously those are very different domains so they belong in separate
> columns. If each type of reading is totally independent of the others
> then one would expect to see a separate table for each, with a common
> key presumably comprising the station number and a timestamp. This is
> of course totally unsupported guesswork on my part.

What you suggest is good, and might work if I had a fixed domain and set of sensors. But the set of sensors, and types, could change at any time. If it were feasible to take that approach (currently, it's not), we could go into production, and two months down the road, we would need to import data for sensor type Zerple, that does not fit in any of our previous profiles, and we might have 20 different readings of type Zerple on each sample (line of the data file). Creating a new table for each type of new sensor is not going to work.

I admit, I'm working with a problem that is *very* database unfriendly. I guess I'll see what I can read and come up with.

Thanks for your input so far.

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.com