As Mighty pointed out, there no situations where synonyms are an unavoidable necessity.
I myself come from a different environment, which the Oracle side of data storage. 🙂 In Oracle, synonyms have been part of the database for many many years now and I have seen the upsides and downsides of using synonyms.
One of the most common uses for synonyms - in my case - is to hide the data (security by obfuscation). Please look at the following example:
- we have a schema that I usually call "container schema". That schema contains all the data tables and all the stored procedures used to operate on the data
- users that access the data will not be allowed to edit or read tables directly (for a plethora of varying reasons), but they will have to use the stored procedures as API against data
- users the need the API get the API procedures exposed into their schema with the help of synonyms
- users get execution rights on the underlying procedural objects
- thus, users make "local" calls inside their schema and think they work locally without being tempted to explore stuff they do not see at all. That is because they actually call synonyms for stored database code.
I know that the above may not be applicable to a SQL Server database, but that can maybe give some ideas to a "proper" SQL Server guy.
Another use is, as the article pointed out, to simplify data access by just constructing a "local" and "simple" name for an object that otherwise would have to be accessed by complex and dotted notation, e.g. a set of data tables. I situations when you have many users writing their own ad-hoc queries and even updates to predefined data containers it is a way to simplify their life.
If you replace synonyms by views, it might still work. But there is a penalty: one is the question of privileges and access rights. Second is the handling of an extra query used to construct the view instead of a simple object name translation. And the third: can you update views in SQL Server?
There is a serious downside of synonyms. Recently we had an big outsourcing of IT done at my previous employer. And all of a sudden we had a bunch of new guys that were constructing a new set of reports for one of the systems. The tool - or maybe the guys - were not even remotely aware of the concept of synonyms, so whatever they tried in a regular SQL tool worked. But when they tried to design their queries in drag-and-drop environment, nothing worked as the tables were not there. They were getting out of their senses trying to find their precious data and I was getting mad trying to convince them to actually _w_r_i_t_e_ queries instead of drag-and-drop.
Well, that was my penny on the subject.