Cú pháp thích hợp trong SQL Server để giải quyết các bảng là gì?

Điều này có vẻ giống như một câu hỏi khá rõ ràng, nhưng tôi đã không thể nghĩ ra thuật ngữ thích hợp cho những gì tôi đang cố gắng hỏi, vì vậy việc đưa ra tài liệu tham khảo cho điều này là phức tạp. Tuy nhiên, câu trả lời có vẻ hiển nhiên.Cú pháp thích hợp trong SQL Server để giải quyết các bảng là gì?

Khi kiểm tra tài liệu đào tạo chung cho SQL Server, chúng được đề xuất luôn đề cập đến các bảng trong cả hai truy vấn "thông thường" (một cái gì đó bạn có thể viết cho dịch vụ web cơ bản) và truy vấn SQL có thể là một thủ tục được lưu trữ, như sau:

[databasename].[dbo].[some_table].[sometimesacolumngoeshere]

Mặc dù tôi đã tìm thấy nó rất phổ biến để đi qua procs lưu trữ, vv, mà chỉ cần sử dụng:

my_column or [my_column]

Sự khác biệt ở đây là rõ ràng rằng một cung cấp một "địa chỉ" tuyệt đối rõ ràng , trong khi ot cô ấy là tiềm ẩn.

Làm thế nào để bạn biết khi nào phù hợp để sử dụng cái này với nhau, và bạn cũng gọi cái này là gì?

Tùy chọn của tôi sẽ luôn rõ ràng và nếu bạn cần tiết kiệm dung lượng và/hoặc làm rõ hơn, bạn có thể bí danh với "địa chỉ" rõ ràng, đúng không?

Nguồn

2012-04-05 Ray

Bạn là chính xác. Về cơ bản, SQL sẽ cố gắng tìm trường bạn đang tìm kiếm "my_column" trong tất cả các bảng trong các phần FROM và JOIN của bạn. Tuy nhiên, nếu bạn tình cờ có một "my_column" trong bảng A và trong bảng B thì bạn cần phải nói rõ ràng "my_column" mà bạn đang tìm kiếm bằng cách bao gồm tên bảng. Điều này đi lên chuỗi để dbo và databasename nếu bạn có va chạm ở đó là tốt.

Hầu hết thời gian, bạn sẽ thấy rằng mọi người không rõ ràng gọi ra các bảng mà cột có trong trừ khi họ tham gia nhiều bảng.

Ví dụ tôi viết truy vấn của tôi như thế này:

SELECT a.field1, b.field2 
FROM tableA AS a 
INNER JOIN tableB AS b ON a.id = b.a_id 
WHERE a.id = 123

Ở đây tôi đang sử dụng AS để tableA bí danh và TableB xuống một dễ đọc hơn và b. Tôi có thể chỉ là một cách dễ dàng bằng văn bản truy vấn của tôi như thế này:

SELECT tableA.field1, tableB.field2 
FROM tableA 
INNER JOIN tableB ON tableA.id = tableB.a_id 
WHERE tableA.id = 123

Hoặc như thế này, nếu field1 và field2 là duy nhất để có bảng, nhưng điều này được một chút bối rối khi đến nơi mỗi phần dữ liệu đến từ.

SELECT field1, field2 
FROM tableA 
INNER JOIN tableB ON tableA.id = tableB.a_id 
WHERE tableA.id = 123

Nguồn

2012-04-05 17:03:37

Tôi không thể không đồng ý với điều đó. Sử dụng bí danh bảng chắc chắn sẽ giúp giảm sự lộn xộn và vẫn cung cấp gợi ý cần thiết để cho biết trường nào là một trường bằng cách xem xét truy vấn một mình. +1 cho bạn. – David

SQL Server có bốn tên phần:

thường Hầu hết các bạn tham khảo một đối tượng theo tên
```
SELECT * FROM MyTable 
```
Sau đó, bạn có thể xác định chủ sở hữu hoặc giản đồ của đối tượng:
```
SELECT * FROM dbo.MyTable 
```
Sau đó, bạn có thể tham chiếu cơ sở dữ liệu mà đối tượng đang sống trong:
```
SELECT * FROM master.dbo.MyTble 
```
Cuối cùng, bạn có thể tham khảo bảng trên một máy chủ khác nhau
```
SELECT * FROM test1.master.dbo.MyTable 
```

Nó giải thích tốt hơn tôi có thể vào MSDN

Nguồn

2012-04-05 16:59:53 Phil

Bạn nên sử dụng ít nhất là lược đồ, có một sự khác biệt hiệu suất. – HLGEM

Hmmm, tôi phải điều tra. – Phil

Một khác biệt nhỏ: http://stackoverflow.com/questions/1112374/sql-server-performance-and-fully-qualified-table-names – Phil

Tôi nghĩ rằng đây là một trong những câu hỏi đó là chủ quan và sẽ trở thành vấn đề ưu tiên, nhưng:

Từ góc độ dễ đọc, tôi cho rằng CHỈ rõ ràng khi cần thiết. Các câu lệnh SQL thường khá phức tạp mà không cần đọc nhiều văn bản không cần thiết.

Tôi nghĩ rằng

SELECT TOP 1000 [StoreNumber] 
     ,[Address1] 
     ,[Address2] 
     ,[City] 
     ,[St] 
     ,[Zip] 
     ,[ZipSuffix] 
     ,[LocationType] 
     ,[LocationSubType] 
     ,[Corp] 
     ,[Division] 
     ,[ZoneNumber] 
     ,[DistrictNumber] 
     ,[StateNumber] 
    FROM [CommonData].[dbo].[vw_StoreData]

là một LOT dễ đọc hơn

SELECT TOP 1000 [CommonData].[dbo].[vw_StoreData].[StoreNumber] 
     ,[CommonData].[dbo].[vw_StoreData].[[Address1] 
     ,[CommonData].[dbo].[vw_StoreData].[[Address2] 
     ,[CommonData].[dbo].[vw_StoreData].[[City] 
     ,[CommonData].[dbo].[vw_StoreData].[[St] 
     ,[CommonData].[dbo].[vw_StoreData].[[Zip] 
     ,[CommonData].[dbo].[vw_StoreData].[[ZipSuffix] 
     ,[CommonData].[dbo].[vw_StoreData].[[LocationType] 
     ,[CommonData].[dbo].[vw_StoreData].[[LocationSubType] 
     ,[CommonData].[dbo].[vw_StoreData].[[Corp] 
     ,[CommonData].[dbo].[vw_StoreData].[[Division] 
     ,[CommonData].[dbo].[vw_StoreData].[[ZoneNumber] 
     ,[CommonData].[dbo].[vw_StoreData].[[DistrictNumber] 
     ,[CommonData].[dbo].[vw_StoreData].[[StateNumber] 
    FROM [CommonData].[dbo].[vw_StoreData]

(Nó trở nên tệ hơn khi bạn bắt đầu bảng tham gia, và thậm chí tồi tệ hơn nếu bạn đang tham gia bảng trên cơ sở dữ liệu khác nhau.)

tôi có thể nhìn thấy nơi bạn có thể tranh luận rằng thứ hai là dễ đọc hơn nếu bạn cần phải biết chính xác cơ sở dữ liệu, lược đồ và bảng một lĩnh vực cụ thể xuất phát từ bằng cách nhìn vào truy vấn một mình.

Nhưng trong SQL Server, ví dụ, bạn có thể mở truy vấn đó trong một nhà thiết kế và xem nó trong chế độ xem đồ họa thân thiện hơn nhiều.

IMHO, thời gian duy nhất mà tôi có thể sử dụng cú pháp đầy đủ là khi cần thiết, khi vượt qua ranh giới bảng/cơ sở dữ liệu/lược đồ, hoặc nếu bạn đã có hai bảng với tên trường tương tự.

Ví dụ:

SELECT TOP 1000 [CommonData].[dbo].[vw_StoreData].[StoreNumber] 
     ,[Address1] 
     ,[Address2] 
     ,[City] 
     ,[St] 
     ,[Zip] 
     ,[ZipSuffix] 
     ,[LocationType] 
     ,[LocationSubType] 
     ,[Corp] 
     ,[Division] 
     ,[ZoneNumber] 
     ,[DistrictNumber] 
     ,[StateNumber] 
    FROM [CommonData].[dbo].[vw_StoreData] 
    Inner Join [CommonData].[dbo].[vw_StorePhones] 
    ON [CommonData].[dbo].[vw_StorePhones].[StoreNumber] = [CommonData].[dbo].[vw_StoreData].[StoreNumber]

Và ngay cả trong trường hợp đó, tôi muốn sử dụng Table Aliases để rút ngắn nó lên và làm cho nó dễ đọc hơn.

Tất cả điều đó nói rằng, trong thế giới thực, rất có thể bạn sẽ thấy mình làm việc cho một công ty đã quyết định định dạng chuẩn và bạn sẽ cần phải mã hóa theo tiêu chuẩn của công ty.

Nguồn

2012-04-05 17:00:41 David

Rất không đồng ý – HLGEM

Đó là lý do tại sao tôi nói đó là chủ quan và một vấn đề ưu tiên. ;-) – David

Mặc dù có thể sử dụng tên ngụ ý cho cột nhưng đây là lựa chọn không phù hợp với khía cạnh bảo trì. Tôi không bao giờ đưa mã sản xuất ra mà không bí danh mỗi cột bởi vì, khi bạn quay trở lại một năm sau đó để thay đổi báo cáo hoặc truy vấn đó, bạn thực sự không muốn phải tìm ra trong số 20 bảng bạn đã tham gia vào nó Ngoài ra, không chỉ định làm cho cơ sở dữ liệu làm việc khó hơn để tìm cột và bạn đã mã hóa nhiều lỗi hơn nơi bạn có các tên cột giống nhau trong hai bảng không có tham chiếu. Đó là một thói quen tốt để được sử dụng tài liệu tham khảo explict.

Nguồn

2012-04-05 17:06:08 HLGEM

Đối tượng có thể được chuyển qua một hoặc nhiều số nhận dạng.

Bạn có thể sử dụng một số nhận dạng duy nhất để chỉ một đối tượng, nhưng nếu số nhận dạng không rõ ràng, bạn phải sử dụng nhiều số nhận dạng để nhận dạng duy nhất đối tượng.

Ví dụ, hai bảng tên TableA hiện trong lược đồ khác nhau phải được tham chiếu trong một truy vấn sử dụng ít nhất một hai định danh, schema_one.TableA và schema_two.TableA.

Có một số MDSN page nơi bạn có thể tìm hiểu thêm về tên đối tượng và số nhận dạng. Về việc sử dụng một số mã định danh cho tên đối tượng, nếu bạn cụ thể hơn, bạn giảm sự mơ hồ trong truy vấn và tăng tốc phân tích truy vấn, vì công cụ cơ sở dữ liệu không phải giải quyết các vấn đề mơ hồ, với chi phí về khả năng đọc của các truy vấn.

Sở thích cá nhân của tôi (đối với các đối tượng thường dùng nhất) đang sử dụng schema.Table khi tham chiếu bảng và column, nếu một bảng được tham chiếu trong truy vấn và table.column nếu nhiều bảng được tham chiếu trong truy vấn.

Nguồn

2012-04-05 17:06:54 gonsalu

Số nhiều sai.

Với ví dụ về một thủ tục lưu trữ sử dụng tên đầy đủ đề cập đến các đối tượng trong cơ sở dữ liệu tương tự, đây là hai lý do để không hoàn toàn đủ điều kiện theo cách đó:

Nếu bạn có một thủ tục lưu trữ đề cập đến một đối tượng trong cùng một cơ sở dữ liệu, nó sẽ phá vỡ nếu bạn đổi tên cơ sở dữ liệu của bạn.
Nếu bạn đã bắt đầu sử dụng Visual công cụ cơ sở dữ liệu Studio để thêm kịch bản cơ sở dữ liệu của bạn để kiểm soát nguồn, bạn nhận được rất nhiều lời cảnh báo để đối phó với

Đó là một ý tưởng tốt để hiểu và sử dụng schemas đúng

Nguồn

2016-02-14 23:08:08

Trong hầu hết các trường hợp tôi sẽ luôn tư vấn sử dụng các địa chỉ đầy đủ để an toàn

[databasename].[dbo].[some_table].[sometimesacolumngoeshere]

Tuy nhiên, điều này chỉ thực sự cần thiết khi bạn có nhiều cơ sở dữ liệu. Tôi chỉ bao giờ gặp phải một hoặc hai vấn đề lựa chọn cơ sở dữ liệu và điều này thường được cố định bằng cách chọn đúng trong máy chủ sql.

Một khi bạn đang thực sự bên trong một truy vấn và bạn đã cho bảng một bí danh rút gọn thì thực sự không cần phải bao gồm địa chỉ đầy đủ vì điều này đã được tham chiếu.

ví dụ

FROM [databasename].[dbo].[some_table].[sometimesacolumngoeshere] SOME 

    SELECT SOME.Name

Nguồn

2017-09-14 09:28:20

Cú pháp thích hợp trong SQL Server để giải quyết các bảng là gì?

Trả lời

Các vấn đề liên quan