Có sự khác biệt nào giữa việc đặt bí danh cột ở đầu hoặc cuối định nghĩa cột không?


12

Tôi đã luôn nhìn thấy và viết các bí danh cột của mình là

SELECT 1 as ColumnName

nhưng hôm nay đã bắt gặp một truy vấn được sử dụng

SELECT ColumnName = 1

Có sự khác biệt nào trong cách hai truy vấn này được thực hiện không? Hoặc có một tiêu chuẩn trong số các DBA về việc sử dụng cái nào?

Cá nhân tôi nghĩ rằng thứ 2 sẽ dễ đọc / duy trì hơn cho các định nghĩa cột dài hơn (ví dụ tốt ở đây từ bài viết này ), tuy nhiên tôi chưa bao giờ thấy cú pháp thứ 2 được sử dụng trước ngày hôm nay vì vậy tôi tự hỏi liệu có lý do nào tôi không nên sử dụng nó.


2
Lưu ý rằng hình thức gán của bí danh nhận xét không phải là di động, vì vậy mặc dù nó làm cho mọi thứ khá dễ đọc khi bạn đang thực hiện RẤT NHIỀU công việc cột dẫn xuất, thật khó chịu khi phải chuyển đổi nó sau này sang DBMS khác.
Cade Roux

@Cade Celko đưa ra lập luận đó về những điều nhất định mọi lúc. Nếu tôi phải chuyển đổi một cơ sở mã SQL Server sang Oracle hoặc PG hoặc MySQL, thành phần bí danh sẽ là điều tôi lo lắng nhất. Vì, không giống như Celko, tôi không quan tâm đến việc tránh tất cả các tính năng độc quyền trong trường hợp chúng tôi chuyển toàn bộ kiến ​​trúc của mình sang một RDBMS khác. Tôi tự hỏi mức độ thường xuyên xảy ra bên ngoài lớp học ...
Aaron Bertrand

@AaronBertrand Tôi đồng ý về việc chuyển đổi hàng loạt. Tôi đã chuyển đổi một loạt các công cụ thành Teradata và đây là vấn đề ít nhất. Điều tiếp tục xảy ra với tôi thường xuyên hơn là tôi sẽ nhập toàn bộ dữ liệu bảng thô vào Máy chủ SQL của riêng tôi và thực hiện các chế độ xem hoặc truy vấn trên đó hoặc bất cứ điều gì tôi làm để phân tích nó, sau đó tôi sẽ viết một truy vấn hoặc Proc cho nguồn phương ngữ hệ thống được gọi từ SSIS hoặc bất cứ điều gì để có được CHỈ chính xác dữ liệu tôi muốn trên dây. Trong những trường hợp đó, tôi có ý thức viết SQL kiểu ANSI rất chung chung. Và sau đó tôi vẫn phải thay đổi mọi thứ như các hàm ngày.
Cade Roux

Câu trả lời:


17

Không có sự khác biệt trong chức năng cơ bản của hai loại răng cưa ( astrái ngược với =). Những gì nó sôi nổi chính xác là những gì bạn đã đề cập: Khả năng đọc và bảo trì.

Theo ý kiến ​​của tôi , cựu ( <Expression> as <Alias>) dễ đọc hơn nhiều vì nó tự giải thích. Khi bạn có SELECT ColumnName = 1tôi nghĩ sẽ rất dễ nhầm lẫn khi đặt một biến vào những đêm dài mệt mỏi. Bạn có thể nhầm lẫn rằng SELECT @ColumnName = 1và đó sẽ là chức năng hoàn toàn khác nhau. Do đó, để tránh bất kỳ khả năng nào của truy vấn "nhìn hai lần", hoặc thậm chí tệ hơn ... lỗi trong cách hiểu / mã hóa, tôi đi với SELECT 1 as ColumnName100% thời gian.

Sở thích cá nhân, nhưng tính nhất quán (cho bản thân và trong nhóm của bạn) là vua . Bất cứ điều gì bạn thấy dễ dàng nhất, hãy đi cùng và làm điều đó mọi lúc. Không có gì bực bội hơn việc chuyển đổi qua lại để ai đó khắc phục sự cố / xem xét / duy trì mã.

Cách không đề cập thứ ba là sử dụng <Expression> <Alias>. Nói cách khác, cách thứ hai của bạn mà không có astừ khóa. Tôi nghĩ rằng điều này cũng tệ như =biểu tượng. Nó thiếu khả năng đọc ở mức tăng của những gì? Không gõ ba ký tự phụ ( asvà một khoảng trắng). Không đáng

Đối với mục đích phóng đại, hãy xem một truy vấn như thế này:

use AdventureWorks2012;
go

select
    [New Name] = Name,
    NewDepId = DepartmentID,
    GroupName as GName,
    ModifiedDate MyModDate
from HumanResources.Department;

Không phải mã mà tôi muốn xem lại.


5
nó luôn làm tôi khó chịu khi nhìn thấy cái cuối cùng, nơi họ loại trừ từ khóa "as". Không bắt buộc nhưng đau khi đọc một loạt mã.

10

Cá nhân tôi thấy alias = expressiondễ đọc và dễ hiểu hơn. Lý do là khi tôi đang khắc phục sự cố một SELECTcâu lệnh có các biểu thức dài, tôi có thể muốn tìm biểu thức thông qua tên cột chứ không phải cách khác. Nhanh chóng, tìm biểu thức mà ứng dụng thấy là alias2:

SELECT
  alias1 = (long expression with aggregates and multiple column references),
  (long expression with aggregates and multiple column references AS alias2
FROM ...

Đó là sở thích của tôi. Bạn có thể khác. Không có lợi thế thực sự để sử dụng cái này hay cái kia ngoại trừ lý do chủ quan / mùi vị. Điều quan trọng là bạn chọn một cách để làm điều đó và thực hiện một cách nhất quán (và trừ khi bạn lật một đồng xu, có thể bảo vệ sự lựa chọn của bạn khi bạn chống lại một người thích cách khác). Nhưng nếu bạn viết mã cho một DBA cầu kỳ như tôi, hãy chuẩn bị cho nó được viết lại. :-)

Tôi đã viết về điều này .

Một điều tôi cảm thấy mạnh mẽ hơn nữa là việc sử dụng các trích dẫn đơn xung quanh tên bí danh, vd

column AS 'alias'
'alias' = column

Một hình thức không được chấp nhận nhưng cả hai đều rất khó đọc - và nhiều người mới nhầm tên bí danh là một chuỗi theo nghĩa đen, vì đó là hình dạng của nó. Vì những lý do tương tự, tôi hoàn toàn ghét việc sử dụng dấu ngoặc kép ( "alias"). Nếu bạn cần thoát bí danh của mình vì đó là một từ dành riêng hoặc được chọn hoặc định dạng kém, hãy sử dụng [square brackets].


2
Hoàn toàn đồng ý về khía cạnh báo giá. Đối với biểu thức dài, những gì cá nhân tôi làm là sử dụng trả về vận chuyển và lập bảng dòng mới và sau đó đặt as <Alias>dòng cuối cùng của định nghĩa cột. Nhưng chắc chắn đồng ý, nó cá nhân như cách bạn thích cà phê của bạn.
Thomas Stringer

@ThomasStringer thấy tôi muốn vận chuyển trả lại biểu thức. Nếu một dòng bắt đầu với AS Aliasđiều đó ASkhông hữu ích khi tôi quét theo chiều dọc cho một tên bảng cụ thể. Tôi cá là chúng tôi cũng không đồng ý về nơi đặt dấu phẩy. :-)
Aaron Bertrand

Tôi đã thử sử dụng các trích dẫn đơn xung quanh các bí danh cột của mình một lần vì nó làm cho chúng có màu đỏ nổi bật trong SSMS, nhưng sự khó chịu khi gõ phím trích dẫn quá nhanh đã trở thành quá nhiều đối với tôi và tôi đã rơi vào những cách lười biếng của mình. Ngoài ra, nó không hoạt động tốt cho mục đích dự định của nó khi tôi có chuỗi trong truy vấn của mình. Có lẽ tôi sẽ gắn bó ASvì đó là những gì chúng ta sử dụng ngay bây giờ (tôi thường thêm một dòng mới trước AS ColumnNameđể chúng gần như xếp hàng), nhưng tôi đồng ý rằng =nó dễ đọc hơn nhiều trong các định nghĩa cột dài hơn.
Rachel

2
@AaronBertrand Đối số của tôi để đặt dấu phẩy lên hàng đầu là nó giúp dễ dàng hơn để biết định nghĩa cột bắt đầu từ đâu, đặc biệt với các định nghĩa cột nhiều dòng.
Rachel

1
@AaronBertrand Tôi thường không làm việc với mã thụt lề rõ ràng>. <
Rachel
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.