Best practice to name a mirrored db respect to the environment

[pmscorca]

Hi,

I usually name a workspace including a suffix (or prefix) to refer the environment (e.g. ws_xxx_dev, ws_xxx_test, ws_xxx_prod), while for the related objects (lakehouse, warehouse, pipeline, dataflow gen2, semantic model, and so on) I don't specify a such suffix or prefix.

Now, which is the best practice to name a mirrored db (f.e. from a SQL Server source)? Can I avoid to specify the environment reference?

Thanks

[v-venuppu · Accepted solution]

Hi @pmscorca ,

Thank you for reaching out to Microsoft Fabric Community.

The best practice is to put the environment name in the workspace, not in each object.So your mirrored database can keep the same name as the source system (e.g., SalesDB) without adding dev/test/prod.

Most Fabric teams follow this pattern:

Workspace: ws_project_dev / ws_project_test / ws_project_prod

Mirrored DB: SourceDB or SourceDB_Mirror (no environment suffix)

You only need an environment suffix on the DB if you are mirroring multiple databases with the same name into one workspace.

[ToddChitt]

The BEST naming convention is one that you stick with consistently throught your project, and is adopted by all involved. It doesn't really matter as long as EVERYONE uses it ALL THE TIME.

I'm going to take exception to simply naming the mirror copy the same as the source database name. I have a client with THREE installations (locations) of an ERP database soltuion, and in all three cases the database name is exactly the same. So I need to prefix or suffix the database name with a location identifier. Since my warehouse naming convention is to START with "wh_" and END with a location code, my mirror database names are "mirror_" + <Database Name> + <location code>.