Modeling related data in a utility network

[VishApte_NGIS]

Thanks for the informative article @RobertKrisher 

Can you please elaborate more on Related Records option. Is it the standard Relationship Class between spatial object in the UNM such as ElectricDevice and non-spatial table not part of the UNM topology e.g. TransformerUnitAttributes, either zero to one or zero to many?

I always contemplated to keep only mandatory topological and network attributes in the base UNM classes such device, line, junction and assembly and define additional business attributes in the related table(s), separate one for each ASSETGROUP. However, a thread long ago suggested it has performance penalty. Solved: Best Practices for Attribute Data Modeling in UN - Esri Community

Has any customer modeled business attributes using related tables?

[RobertKrisher]

This thread was created from a comment on this article: https://community.esri.com/t5/arcgis-utility-network-blog/modeling-related-data-in-a-utility-network...

I have clarified the article to explicitly state that the related records are non-network features/rows.

I haven't seen any examples of moving all the business attributes into related tables, but maybe someone in the community can speak to what their experience has been with it?

What I more commonly see is customers who had heavily a heavily de-normalized data model restructure their data model to move fields for things like customer data, inspection data, etc into related tables. Wide tables and many relationship classes both carry their own performance costs, so be considerate with how you store and manage your data. This is a principle that doesn't apply to GIS, but any application that is built on a relational database.