问题
Given hundreds of database tables in multiple schemas, when creating stored procedures and views, would you recommend using aliases/synonyms or fully qualified name? Given a few schema.table like so,
Orders.OrderHeader, Production.LineThroughput, Sales.Opportunities
I expect a slight gain in performance with using qualified names but if a table such as Orders.Customers would have to be moved to Sales.Customers, I would either have to alter existing views/procedures referring to Orders.Customers or use a synonym ahead of time where such a move is anticipated. I see value in moving code into testing using synonyms but at the same time I could as well create a replica of my production environment to test/dev and not require synonyms.
SQL Server Books Online recommends to always use a fully qualified name. Some friends propose creating one synonym for each of the hundreds of tables and using only synonyms. While I prefer to use fully qualified name (more readable and self-explanatory code, knowing what referred object belongs to what schema, and habit of typing schema.table), what significant performance, operational or readability (dis)advantage have you observed with using synonyms vs fully qualified table names?
回答1:
The code (SQL or stored proc) should remain in a source code management system outside the database. If you cannot search and replace accurately, you have serious problems, so really that should be addressed first.
Where the no of tables are large, you really need to use prefixes. Not Sales.Customer but REF_Customer.
The dot specifies that it is in a separate database (MS and Sybase) or schema (DB2 and Oracle). That is a separate recovery unit, so they are maintained separately, and teh server has to switch contexts every time you cross teh boundary. Therefore you need to collect your tables properly with this in mind and use a few databases/schemas, not many. Eg. separate the reference tables, that do not get updated often, and are commonly referenced from other dbs/schemas.
Always use fully qualified names in SQL code. Not as a prefix for column names, but in every WHERE and FROM clause. That will greatly assist when moving database/schemas or environments, DEV to UAT or PROD.
回答2:
I always use aliases in queries, one main reason is the the query gets easier to read. Repeating the full table name over and over just clutters up the code.
Most of the time the table name is superflous, it's obvious just from the field name where they come from. You should however always specify which table you get a field from, that makes the query easier to maintain, and it becomes less sensetive to changes in the database.
A query usually only uses a few tables, and as they are related it's easy enough to keep track of the tables used. If not, it's only another step to determine what the alias means, and the information is available right in the query.
If you need to move a table to a different database, aliases are also helpful. As the full table name is only specified once in the query, it's easier to change.
If there is any difference in performance between different ways of specifying the same field, that would only be in the process of parsing the query, so that would be minimal. When the query is running, there is no performance difference at all.
回答3:
This is a "it depends" kind of situation.
Personally, in an application with tables spread across multiple schemas, I would prefer not to hard-code the schema names anywhere in my code; to that end, I would create private synonyms for each schema that has code.
That way, if a table is moved from one schema to another, or (worse still) a schema is renamed), I only need to update the synonyms that point to it, instead of going through all the code and views.
On the other hand, in some cases I've preferred to write code that explicitly refers to the schema - it was code for a data migration project which had to refer to the same table in multiple schemas, and we "locked down" the schema names so that it would work in DEV/TEST/etc, without needing a whole lot of synonyms.
回答4:
My two cents...
Personally, the companies I have worked at have used fully qualified object names, even when referring to objects in the same schema. On the rare occasions where we did move a table to another schema, we usually set up a view (not a synonym) in the old location for backward compatibility, mainly because we were burned by revalidation issues in the past.
Performance-wise, in Oracle at least, there are reports of a slight performance hit with synonyms, as the database has to first resolve the synonym's name, then resolve the name of the target object (table/view/package/etc.). Public synonyms have a slightly greater performance hit (2X that of non-public synonyms). However, this is somewhat disputed; see this Ask Tom article for more information. However, unless you are pushing your database to the limit, I wouldn't worry about it.
回答5:
if you anticipate that the tables are really going to be moving around, be safe, use fully qualified names.
回答6:
There is always more than answer to any question. That is why "it depends" is always the right answer. I find that when you stay true to the intentions and design you in the end you come out ahead.
Schemas are designed for namespace isolation. For example, when designing a SaaS system, schemas can be used very effectively to separate concerns for multiple tenants. Schemas can also be used to separate test from production or one application data from another. And it is not just for tables but for stored procedures and all other database objects.
DB2 provides a special register called CURRENT SCHEMA that allows you to code unqualified object names but switch to the right schema by simply setting CURRENT SCHEMA special register like so:
SET CURRENT SCHEMA = 'Production'
This, in my opinion, is a much better approach than using synonyms.
来源：https://stackoverflow.com/questions/4273242/hundreds-of-aliases-synonyms-vs-database-tables-fully-qualified-names