Lately I've run into a few instances of synonyms in different situations. There have been more than a few questions lately about accessing code from different databases and the hassles this creates over time. Often the answer is to migrate to synonyms, which can decouple some of your code. Many experts seem to prefer this solution, though I've seen a few people push back as this being a complex or problematic solution.

Today, I'm asking how you feel about synonyms? If you have a reason to be pro or con, then perhaps you can leave a comment, or write an article if you've solved a problem with synonyms.

The other place I've seen this come up is with customers for Redgate that have multiple databases that are trying to automate their database DevOps process. Performing a validation of your code in a build is complex when there are dependencies on other databases. This can be a complex topic, and Kendra discusses this in our DevOps Advocate channel. Again, this is a way of avoiding some technical debt if you implement synonyms in your code. I think as we move to containerized database platforms, this will become even more important.

The last place I've run into synonyms is where a few users have tried to write a stored procedure that exists in one database, but runs in the context of whatever database it's called from. That doesn't work, though the BOL documentation is rather sparse on the stored proc and function use of synonyms. I wonder, do some of you use synonyms for those programmable objects? It's certainly better than writing three part naming, but likely not habit you have.

If you are using any sort of synonym in your work, and love or hate them, let us know why. This is (I think) and under-used feature of SQL Server, and one that more people should be aware of as an option in their daily work.