> Thanks, Tibor.
> As I see it, using an alias is just a matter of
> convenience for the writer; the reader would have to look
> at the FROM clause to then relate the alias to a specific
> DB object.
> Furthermore, in order to maintain some kind of sanity, it
> would make sense then to impose some kind of naming
> convention on aliases and requiring you (the writer) to
> remember yet another set of rules.
> I think, though, that regardless of whether one uses
> aliases or the owner.objectname approach, always
> qualifying column names is good practice. And according
> to Billy Yao's last message, it's good for performance.
> >-----Original Message-----
> >My recommendation is to give the table an alias name in
> the FROM clause and use that alias name (no
> >database or owner) in the other places of the query.
> >SELECT od.col1, od.col2, o.cola
> >FROM dbo.OrderDetails AS cd
> > INNER JOIN dbo.Orders AS o ON o.oid = od.oid
> >WHERE o.OrderNumber = 34
> >--
> >Tibor Karaszi, SQL Server MVP
> >Archive at: http://groups.google.com/groups?
> oi=djq&as_ugroup=microsoft.public.sqlserver
> message
> >> Yes, all the answers I've gotten so far helped. Thanks.
> >> Obviously, a complicating factor would be when there
> is one or more joins.
> >> Is such a case, does using the dbo.objectname
> qualifier have any impact on
> >> performance?
> >> I know it is required to resolve the ambiguous column
> names but it seems to
> >> me that using a qualifier would have to absolutely
> resolve which object owns
> >> which columns; am I wrong?
> >> Consider the following:
> >> SELECT
> >> FirstName,
> >> LastName,
> >> dbo.Contacts.PhoneNumber as ContactPhoneNumber,
> >> dbo.Contacts.ZipCode as ContactZipCode,
> >> CustomerName,
> >> dbo.Customer.PhoneNumber as CustomerPhoneNumber,
> >> dbo.Customer.ZipCode as CustomerZipCode
> >> FROM dbo.Contacts
> >> INNER JOIN dbo.Customers on dbo.Contacts.CustomerID =
> >> dbo.Customers.CustomerID
> >> SELECT
> >> dbo.Contacts.FirstName,
> >> dbo.Contacts.LastName,
> >> dbo.Contacts.PhoneNumber as ContactPhoneNumber,
> >> dbo.Contacts.ZipCode as ContactZipCode,
> >> dbo.Customer.CustomerName,
> >> dbo.Customer.PhoneNumber as CustomerPhoneNumber,
> >> dbo.Customer.ZipCode as CustomerZipCode
> >> FROM dbo.Contacts
> >> INNER JOIN dbo.Customers on dbo.Contacts.CustomerID =
> >> dbo.Customers.CustomerID
> >> Also, if fully qualifying column names does not
> negatively impact
> >> performance, would one not be better off fully
> qualifying them in terms of
> >> maintenance and readability?
> >> Willy
> >> > Hi Willy,
> >> > Thank you for using MSDN Newsgroup! It's my pleasure
> to assist you with
> >> this issue.
> >> > From your description, I understand that you would
> like to know which of
> >> the SELECT
> >> > statements will yield better performance. I have to
> say that these two
> >> SELECT statementsare
> >> > the same as they all tell SQL Server the object
> (table) location AT THE
> >> SAME TIME.
> >> > In select statements, as we know, the SQL Server
> Parser will Start in the
> >> FROM clause, Go to
> >> > WHERE clause (if exist) and finally SELECT the
> columns. If you specify the
> >> qualified name in
> >> > the FROM clause, SQL Server has already known where
> the column should be
> >> selected in the
> >> > SELECE clause. So the two kind of performance are
> the same and good.
> >> > Additionally, as Louis pointed out, the performance
> difference will
> >> produce if the following
> >> > statements are executed:
> >> > SELECT
> >> > [CustomerName],
> >> > [PhoneNumber],
> >> > [ZipCode]
> >> > FROM [Customers]
> >> > In this way, SQL Server doesn't know where the table
> locates in and will
> >> check it first. To
> >> > improve the performance, we can tell SQL Server the
> location of objects
> >> with the following
> >> > announcement:
> >> > ----------------
> >> > Use Marketing
> >> > Go
> >> > SELECT
> >> > [CustomerName],
> >> > [PhoneNumber],
> >> > [ZipCode]
> >> > FROM [Customers]
> >> > ----------------
> >> > Willy, does this answer your question? Please feel
> free to let me know if
> >> this help solves your
> >> > problem. If there is anything more I can do to
> assist you, please feel
> >> free to post it in the group
> >> > Best regards,
> >> > Billy Yao
> >> > Microsoft Online Support
> >> > ----------------------------------------------------
> >> > Get Secure! - www.microsoft.com/security
> >> > This posting is provided "as is" with no warranties
> and confers no rights.
> >> > Please reply to newsgroups only. Thanks.
> >.