There can be many PositionSamples for a single record so I figured it might be worth it to try and optimize this a bit.
I thought I might try and store the samples as a list of tuples (serialized as arrays when in json format). E.g.
You can prevent Ecto from generating an id (the UUID in your case, which is, by default, the primary key), using the schema attributes @primary_key. In your case, if i understand correctly, you’d do:
# schema definition
Concerning premature optimisations, i’d say yes (assuming you’re using Postgres). In any case, considering you seem to have a well defined list of fields, meaning, JSON fields in Postgres strength to handle difficult to predict data structure isn’t really the needed tool here, i’d go for another table before anything else, if i was concerned with performance. For a small set of data though, that you don’t need to query directly (or too often, or that require doing things like using geospatial data in your case), it’s fine.
If you’re storing timescale and position data one would assume that at some point you’d want to filter that data by location or time windows, in which case I’d definitely go for a separate table for easier bound, indexed lookups. And probably with PostGIS if location searches are part of your core business model.