Re: Type inheritance

On Sat, Jun 6, 2009 at 8:30 AM, Richard Broersma <richard(dot)broersma(at)gmail(dot)com
> wrote:

> On Sat, Jun 6, 2009 at 12:10 AM, Gianvito Pio<pio(dot)gianvito(at)gmail(dot)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.