On Sat, Jun 6, 2009 at 8:30 AM, Richard Broersma
<richard.broersma@gmail.com> wrote:
On Sat, Jun 6, 2009 at 12:10 AM, Gianvito Pio<
pio.gianvito@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.
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.
