Migrating non-geometric network layers to a Utility Network

[ScottMinter]

We are migrating our Geometric Network to Utility network (version 10.9.1).

We have additional layers that are not included in the GeoMetric Network but relate to the Gas Distribution Network. We are trying to decide if these should be left int he current GeoDatabase or migrated into the new Utility Network Database. Does anyone have any "best practice" advice?

I've attached a document with some advice, do you agree or disagree?

We are a small Gas Distribution Company and our entire Asset package we are importing is only 450MB so performance likely will not be an issue.

30K meters, 27K service pipe, 35K distribution pipe

[gis_KIWI4 · Accepted solution]

@ScottMinter - 
You mention that these additional layers relate to the Distribution Network. Do you want them to be used with the UN functionality like Tracing, Network Management, containment & associations? 
If yes, then you will need to find a place for them in the UN schema. 

There is no requirement for the non-UN Data to live in same database as your UN data.

If the data is just meant going to participate in the Utility Network going forward then it's worth considering putting it in a different database unless you have a really good reason to put this data in the same database. 

If your non-UN  data is interacting with the UN data say via relationship class then you might consider putting them together.

Given the size of your network, I don't think we need to worry about performance considerations.

As for our implementation (Small Electricity Distribution Utility)we have kept two separate databases.
Some of our non-UN data also lives on Enterprise as hosted feature layers.

[ScottMinter]

Just knowing you are using two different databases helps me. It seems it is best practice to keep utility network in its own database and that is what we will do. Thank you for the good explanation.

[SamDeLore]

It really depends on the nature of the relationship and how you want to show that. What are the features in the related layers?

If you want an inherent link from UN feature to this other feature, then the structure domain might be a good fit and associate or attach to the network to establish a feature level link.

If the features are non-spatial then the UN object tables would be the place to put them, they can still be associated at the feature level.

However, keep in mind, placing these layers in your UN means you'll need to establish rules for all of these relationships and the data in these extra layers needs up to a certain standard to avoid Topology errors / dirty areas, but the benefit is you'll get all of the UN functionality for these additional layers.