Regardingh Combined domain network of Water and electric utility in a single Enterprise SQL database

[PragatiSingh]

we are moving to arcgis utility network for our electric and water geometric network data to Postgres enterprise database. How we separate the two domain networks within the postgres instance? Do we need to create separate databases within the instance

[AyanPalit]

@PragatiSingh Electric and Water don't mix - best to keep them as separate databases, one for each domain network.

[JakeJacobsAVA]

We recently received advice from Esri to have our gas and electric UN's in one database but in separate schemas. @AyanPalit can you describe what the criteria are for deciding on separate schemas vs separate databases? Also PostgreSQL here.

[RichRuh]

I would base it on the structure of your organization. If one GIS group serves both water and electric, then putting them in a single utility network makes sense.

If most of your users are using water or electric, and you want different permissions for each domain (e.g., water GIS users can view electric, but not edit) , then it might make sense to split them up.

[JakeJacobsAVA]

Oh interesting. How does that work with the permissions? I thought that was just managed at the portal level with what groups the feature service is shared with?

[RichRuh]

When you publish a utility network to a feature service, you need to include the *entire* utility network. 

If you put both domain networks (water, electric) in a single utility network, that entire utility network is included in the feature service.  You can only set permissions on the feature service as a whole.

If you split them up into two utility networks, you would publish them as two services, and could set different permissions on each one.

Another consideration is if you want to share the structure network between domains. While you don't often see water pipes attached to poles, they may share trenches or other facilities. 

[JakeJacobsAVA]

Interested still to know about the distinction between putting two utility networks in separate schemas (which Esri recommended to us recently) and two separate databases (which Ayan Palit recommended here). Seems like in that case it wouldn't be for permission management.

[AyanPalit]

@JakeJacobsAVA As is evident in this thread, there are multiple parameters in play.

Organizations are unique in their mix of utility domains that drive functional requirements, workload separations, IT policies (e.g RDBMS platform), integration needs. Accordingly, one size/recommendation will not fit all. Advice community members to consider their unique requirements/circumstances to right-size the Utility Network design.   

[RobertKrisher]

@PragatiSingh there's lots of discussion here. You have two domain networks, and the assumption is that you want them to be in separate utility networks You could put them in the same utility network if you wanted them to share structures or had some other compelling reason, but that is not typical for water/electric.

If you do want to have multiple utility networks, then you can have options. If you just want to manage one database, you can put them in the same database but give each one separate schemas. If you put them in the same schema you will get name conflicts on the structure classes (so you'll have structurejunction and structurejunction_1).

If you want to manage them in separate databases, then you are free to do that using however many databases, instances, and servers that you want because the two utility networks are not related in any way.

[PierreloupDucroix]

Interesting topic. I'm working on a migration project where the client manages an electricity and water network.

Their common use case is to use the unique identifier of the utility poles (an identifier that indicates the pole's position on the network) to locate each field intervention, including on the water networks, since they don't have addresses.

While it's possible to manage this without merging the two domains into a single unified UN, it could be useful to associate the water elements with their corresponding utility poles and use this association in tracing, for example, to easily find the nearest pole to send a field team to.