Re: Type inheritance
| От | Rob Sargent |
|---|---|
| Тема | Re: Type inheritance |
| Дата | |
| Msg-id | 5c4ddc540906060811i71e7892bqb208084512c92f90@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Type inheritance (Richard Broersma <richard.broersma@gmail.com>) |
| Список | pgsql-sql |
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:I think that best solution for what you want to achieve is to design
> 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.
В списке pgsql-sql по дате отправления: