Jaka jest właściwa składnia w SQL Server do adresowania tabel?

Question

To wydaje się dość oczywiste pytanie, ale nie byłem w stanie wymyślić właściwego terminu na to, co próbuję zadać, więc wymyślanie materiałów referencyjnych było trudne. Odpowiedzi wydają się jednak oczywiste.

Podczas badania materiałów szkoleniowych Pluralsight dla SQL Server zalecano, aby zawsze odwoływały się do tabel w zapytaniach "zwykłych" (coś, co można napisać dla podstawowej usługi sieciowej) i do zapytania SQL w prawdopodobnie procedurze przechowywanej, takiej jak następujące:

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

Choć znalazłem to bardzo często natknąć przechowywanych proca, etc., które po prostu wykorzystują:

my_column or [my_column] 

różnica tutaj jest oczywiście, że jedna zapewnia absolutną „adres” jawnie , podczas gdy ot ona jest ukryta.

Skąd wiadomo, kiedy należy używać jednego z nich, a także jak się to nazywa, adresując?

Moja preferencja byłaby zawsze jednoznaczna, a jeśli chcesz zaoszczędzić miejsce i/lub uczynić sprawę bardziej przejrzystą, możesz podać alias do wyraźnego pełnego "adresu", prawda?

Answer 1

Masz rację. Zasadniczo SQL spróbuje znaleźć szukane pole "my_column" we wszystkich tabelach w sekcjach FROM i JOIN. Jeśli jednak zdarzy ci się mieć "moja_kolumna" w tabeli A i w tabeli B, musisz jawnie powiedzieć, której "mojej_kolumny" szukasz, dołączając nazwę tabeli. To powoduje przejście do dbo i databasename, jeśli masz również kolizje.

W większości przypadków ludzie nie wywołują jawnie tabel, w których znajduje się kolumna, chyba że dołączają do wielu tabel.

Na przykład piszę moje pytania tak:

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

Tutaj używam AS do aliasu TABLEA i tableB do bardziej czytelnego a i b. Mógłbym równie dobrze napisane moje zapytanie tak:

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

Albo tak, jeśli pole1 i pole2 są unikalne tam stolików, ale to staje się trochę mylące, ponieważ tam, gdzie każda część danych pochodzi.

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

Answer 2

SQL Server ma cztery imiona część:

• Najczęściej odwołać obiekt o nazwie

  SELECT * FROM MyTable 
  

• Następnie można określić właściciela lub schematu obiektu:

  SELECT * FROM dbo.MyTable 
  

• Następnie można odwołać się do bazy danych, w której znajduje się obiekt:

  SELECT * FROM master.dbo.MyTble 
  

• Wreszcie można odwołać się do tabeli na innym serwerze

  SELECT * FROM test1.master.dbo.MyTable 
  

Jest to wyjaśnione lepiej niż ja na MSDN

Answer 3

Myślę, że to jedno z tych pytań, które subiektywne i okaże się to kwestią preferencji, ale:

Z punktu widzenia czytelności argumentowałbym, że będę TYLKO JEDYNYM, gdy będzie to konieczne. Bardzo często instrukcje SQL są wystarczająco złożone, bez konieczności czytania niepotrzebnego tekstu.

myślę że

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

jest dużo bardziej czytelny niż

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] 

(Jest jeszcze gorzej, kiedy zaczynają tabel łączenia, a nawet gorzej, jeśli jesteś łączenia tabel w różnych bazach danych.)

widzę gdzie można argumentować, że drugi jest bardziej czytelny jeśli trzeba dokładnie wiedzieć, które bazy danych, schemat i tabela szczególna dziedzina pochodzi patrząc na samego zapytania.

Ale na przykład w SQL Server można otworzyć to zapytanie w projektancie i wyświetlić je w znacznie bardziej przyjaznym widoku graficznym.

IMHO, czas tylko, że będę korzystać z pełnej składni jest gdy konieczne, przy przekraczaniu granic tabeli/bazy danych/schematu, lub jeśli masz dwie tabele o tej samej nazwie pola.

Przykład:

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] 

I nawet w tym przypadku użyłbym Table Aliases skrócić go i uczynić go bardziej czytelnym.

Wszystko to powiedziawszy, w realnym świecie jest całkiem prawdopodobne, że będziesz pracować dla firmy, która już zdecydowała o standardowym formacie, i będziesz musiał kodować zgodnie ze standardem firmy.

Answer 4

Chociaż istnieje możliwość użycia nazw zmiennych w kolumnach, jest to zły wybór z aspektu łatwości obsługi. Nigdy nie umieszczam kodu produkcyjnego, który nie jest pseudonimem każdej kolumny, ponieważ kiedy wrócisz rok później, aby zmienić ten raport lub zapytanie, naprawdę nie musisz się zastanawiać, który z 20 stołów, do których się przyłączyłeś. jest dalej. Ponadto, nieokreślanie sprawia, że ​​baza danych pracuje ciężej, aby znaleźć kolumnę i masz więcej błędów w kodowaniu, gdzie masz nazwy kolumn, które są takie same w dwóch tabelach bez odniesienia. To dobry nawyk, aby korzystać z ewidentnych odniesień.

Answer 5

Obiekty można odsyłać za pomocą jednego lub kilku identyfikatorów.

Możesz użyć pojedynczego identyfikatora do odniesienia się do obiektu, ale jeśli identyfikator jest niejednoznaczny, musisz użyć większej liczby identyfikatorów, aby jednoznacznie zidentyfikować obiekt.

Na przykład dwie tabele o nazwie TableA istniejące w różnych schematach muszą być przywoływane w zapytaniu za pomocą co najmniej dwóch identyfikatorów: schema_one.TableA i schema_two.TableA.

Istnieje MDSN page, gdzie można uzyskać więcej informacji na temat nazw obiektów i identyfikatorów.

Jeśli chodzi o użycie kilku identyfikatorów dla nazw obiektów, jeśli bardziej szczegółowo, zmniejsza się niejasności w zapytaniach i przyspiesza parsowanie zapytania, ponieważ silnik bazy danych nie musi rozwiązywać problemów niejednoznaczności, kosztem czytelności zapytań.

Moje osobiste preferencje (dla najczęściej używanych obiektów) korzysta schema.Table przy odwoływaniu tabel i column, jeśli jedna tabela jest mowa w zapytaniu, a table.column jeśli kilka tabel są wymienione w zapytaniu.

Answer 6

Pluralsight są złe.

Biorąc przykład procedury przechowywanej, który wykorzystuje pełną nazwę, która odnosi się do obiektów w tej samej bazie danych, tutaj są dwa inne powody, aby nie w pełni kwalifikują się w ten sposób:

• Jeśli masz procedura składowana, która odwołuje się do obiektu w tej samej bazie danych, zostanie złamana, jeśli zmienisz nazwę bazy danych.

• Jeśli było zacząć używać Visual Database Tools Studio dodać skrypty bazy danych do kontroli źródła, można uzyskać wiele ostrzeżeń do czynienia z

To jest dobry pomysł, aby zrozumieć i wykorzystać schematów prawidłowo

Answer 7

W większości przypadków będzie zawsze radzę użyć pełnego adresu dla pewności

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

Jednak jest to naprawdę potrzebne tylko wtedy, gdy masz wiele baz danych. Zdarza mi się tylko jeden lub dwa problemy z wyborem baz danych i zazwyczaj jest to naprawiane przez wybranie właściwego na serwerze sql.

Gdy już znajdziesz się w kwerendzie i podałeś tabelę skróconego aliasu, naprawdę nie ma potrzeby dodawania pełnego adresu, ponieważ jest to już wspomniane.

np

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

    SELECT SOME.Name