On Sat, Jun 6, 2009 at 8:30 AM, Richard Broersma <richard.broer...@gmail.com > wrote:
> On Sat, Jun 6, 2009 at 12:10 AM, Gianvito Pio<pio.gianv...@gmail.com> > wrote: > > > That value doesn't have to be fixed, but I want to define it in a > > way that it changes its structure when the sensor type changes. For > > example, for Temperature sensor I would like to have just a float number, > > but for the humidity I could need of absolute and relative humidity > > (2 floats). I'd just like to know if I can say that the VALUE is a > composite > > type...that I have then to specialize in Temp Type and Humidity > type...using > > them in their particular case. > > I think that best solution for what you want to achieve is to design > you own vertically partitioned table hierarchy. PostgreSQL's table > inheritance isn't going to allow that relationships that you may want > between the sub-types. > > Another PostgreSQL specific feature that allows for hierarchical data > is the contrib module h-store. Its kind-of like EAV for a column > instead of a table. Are we storing sensor types (name, etc, sensor-report) where the report column has to be polymorphic or are we storing instances of sensor results (sensor-id, sensor-report). For the former a single table with an array of number in the report column might work, for the latter it seems that separate type specific tables extending/dependent to a table of sensors could do the trick. What you're using to access the store might also affect the design.
