public inbox for [email protected]  

help / color / mirror / Atom feed

From: Adrian Klaver <[email protected]>
To: Achilleas Mantzios - cloud <[email protected]>
To: [email protected] <[email protected]>
Cc: Achilleas Mantzios <[email protected]>
Subject: Re: Ideas about presenting data coming from sensors
Date: Thu, 13 Feb 2025 09:12:03 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>

On 2/13/25 01:53, Achilleas Mantzios - cloud wrote:
> Now my problem is on the design . We have :
> 
> a) tags that have primitive values, float4 lets say - this is the 
> majority, e.g. 60% of all tags
> 
> b) tags that contain alarms data also with defined structure, which have 
> additional data such as time of the initial alarm set, acknowledgement 
> of this alarm , validity of this alarm. Those represent smth like 35% fo 
> all tags
> 
> c) tags that are basically polymorphic (about 11 of them all in all), 
> each one has different structure, and their fields/cols range a few (1) 
> up to many (25)
> 
> We have a table for a) and a table for b).
> 
> If we followed a strict normalized approach then we would create 
> additionally 11 tables each tag of type c) . And we are not guaranteed 
> that the same tags would have the same structure over the whole 
> fleet/manufacturers. So we are thinking of putting all semi-structured 
> data of tags of type c) into one table with a single col of type jsonb .
>> From what I read timescaledb plays nice with jsonb (or at least not bad).
> 
> Do you ppl see any gotcha with this approach ?

The only thing I can see at this time is: 'And we are not guaranteed 
that the same tags would have the same structure over the whole 
fleet/manufacturers.'

That would seem to me to point to a need for a table that maps a 
structure template to a fleet or manufacturer and a corresponding field 
in table c) that holds the fleet/manufacturer information.

> 
> For starters we will not convert yet to timescaledb, but store them and 
> handle them like normal tables. At least until we grasp the ins and outs 
> of this.
> 
>>
>>>
>>> Thank you!
>>>
>>>
>>>
>>>
>>

-- 
Adrian Klaver
[email protected]

view thread (11+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Ideas about presenting data coming from sensors
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox