Best practice for handling multiple “point-level” tables (Field Mapping, ESG, Prospectors) under the

NimbusInsights
NimbusInsights Posts: 4 Calcite Rank Badge
in MX Deposit

Hi everyone,

In our project, the Field Mapping data is currently stored inside the main Header table, and we have a “child” table for Field Mapping Samples. Now we need to add two additional point-level tables: one for ESG and one for Prospectors.

We created the two new tables, but it looks like “Point” becomes unified across all tables — as if the system treats them as belonging to the same overarching Header structure. Because of this, all tables appear to be tied to the same point register.

My question is:
How do projects usually handle this scenario?
Is it recommended to separate Field Mapping from the Header, creating a dedicated Field Mapping table, so the structure becomes something like:

HEADER

FIELD MAPPING

PROSPECTORS

ESG

This would keep each point-based workflow independent, instead of sharing a single “Point” entity.

Any best practices or examples from other projects would be extremely helpful.

Thanks in advance!

Categories