Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 80E836329A0 for ; Sat, 6 Jun 2009 12:11:20 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 65588-02 for ; Sat, 6 Jun 2009 12:11:17 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pz0-f186.google.com (mail-pz0-f186.google.com [209.85.222.186]) by mail.postgresql.org (Postfix) with ESMTP id E77956321D6 for ; Sat, 6 Jun 2009 12:11:16 -0300 (ADT) Received: by pzk16 with SMTP id 16so1570987pzk.15 for ; Sat, 06 Jun 2009 08:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=/kn5d0YLUIjWzc91ojaqXBlSWYMiG/1n64NsoAvFeBk=; b=djy8YJbGMEmN8QCltWHLcgr2Lu80db1VGQg5kXgTsGNuOhQ2KNPEKprDq9mJZgQHnA Nd48jT3loAer0CUadP/+ZyTpsX1qI0DncPAwkwlLKQLYDahbe3wOL02iC2HnBbt2rnoa 80NGgzVcIq2pn+PDCsSIk6E/Dt5srzBVbY2V4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=sUAO+UHyPPXBFL1AdyKgDQgdFsragvAbbPFkY4W5HY1EhzqXr617/fZ+L+sRmhLHvi r09EG/skioLJ8M5ml0U3lAt8PUiNrwRe50QHwZXAwiMlu77vj4mlQiGSVr6xWmpB9Oxb gFXvRjqgISC10rhxgRF/VR7reTR0H6EwiZJZM= MIME-Version: 1.0 Received: by 10.142.142.16 with SMTP id p16mr1674334wfd.321.1244301072616; Sat, 06 Jun 2009 08:11:12 -0700 (PDT) In-Reply-To: <396486430906060730t1afd39a9p49b056158b1d2194@mail.gmail.com> References: <5eca56860906050330w6171b327k95881b13c4dca466@mail.gmail.com> <4A294A00.5020802@gmail.com> <5eca56860906060010y4177b88apcf587d62f7286b5d@mail.gmail.com> <396486430906060730t1afd39a9p49b056158b1d2194@mail.gmail.com> Date: Sat, 6 Jun 2009 09:11:12 -0600 Message-ID: <5c4ddc540906060811i71e7892bqb208084512c92f90@mail.gmail.com> Subject: Re: Type inheritance From: Rob Sargent To: pgsql-sql@postgresql.org Content-Type: multipart/alternative; boundary=000e0cd147dc6d4fb7046baf6b51 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 200906/30 X-Sequence-Number: 32635 --000e0cd147dc6d4fb7046baf6b51 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Jun 6, 2009 at 8:30 AM, Richard Broersma wrote: > On Sat, Jun 6, 2009 at 12:10 AM, Gianvito Pio > 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. --000e0cd147dc6d4fb7046baf6b51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 6, 2009 at 8:30 AM, Richard Broe= rsma <ri= chard.broersma@gmail.com> wrote:
On Sat, Jun 6, 2009 at 12:10 AM, Gianvito Pio<pio.gianvito@gmail.com> wrote:
> =A0That value doesn't have to be fixed, but I want to define it in= =A0a
> way that it changes its structure when the sensor type changes. For > example,=A0for Temperature sensor I would like to have=A0just a=A0floa= t number,
> but for the humidity I could need of absolute and relative humidity > (2=A0floats). 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=A0and Humidity type= ...using
> them in their particular case.

I think that best solution for what you want to achieve is to design<= br> you own vertically partitioned table hierarchy. =A0 PostgreSQL's table<= br> 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. =A0Its kind-of like EAV for a column
instead of a table.

=A0
Are we storing senso= r 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).=A0 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.=A0 What you're using to access the stor= e might also affect the design.
=A0

--000e0cd147dc6d4fb7046baf6b51--