Obsada T-SQL kontra konwersja

325

Co to jest ogólne wytyczne, kiedy należy użyć CASTkontra CONVERT? Czy są jakieś problemy z wydajnością związane z wyborem jednego kontra drugiego? Czy ktoś jest bliżej ANSI-SQL?

— BuddyJoe
źródło

339

CONVERTjest specyficzny dla SQL Server, CASTjest ANSI.

CONVERTjest bardziej elastyczny, ponieważ można formatować daty itp. Poza tym są one prawie takie same. Jeśli nie zależy Ci na rozszerzonych funkcjach, użyj CAST.

EDYTOWAĆ:

Jak zauważyli @beruic i @CF w komentarzach poniżej, możliwa jest utrata precyzji, gdy używana jest niejawna konwersja (to jest taka, w której nie używasz CAST ani CONVERT). Aby uzyskać więcej informacji, zobacz CAST i CONVERT, aw szczególności ta grafika: Tabela konwersji typu danych programu SQL Server . Dzięki tym dodatkowym informacjom oryginalne porady pozostają takie same. W miarę możliwości używaj CAST.

— Matthew Farwell
źródło

5

Sądzę też, że istnieją pewne konwersje numeryczne, w których CAST powinien być użyty do zachowania precyzji, ale mam problem ze znalezieniem wiarygodnego źródła tych informacji.

— beruic

2

@beruic Masz rację, w MSDN znajduje się informacja: msdn.microsoft.com/en-us/library/ms187928.aspx CAST jest wymagany do zachowania precyzji podczas konwersji między typami DECIMAL i NUMERIC.

— CF

@CF Gdzie widzisz te informacje? Połączyłem się z linkiem, który otwiera ogólną stronę CAST i CONVERT, a jedyne informacje dotyczące precyzji, jakie mogę znaleźć, to konwersja wartości zmiennoprzecinkowych, które używają notacji naukowej. Czy mogę się mylić w pierwszym komentarzu?

— beruic

6

@beruic Chodzi o to zdjęcie na dole artykułu i.msdn.microsoft.com/dynimg/IC170617.gif Teraz myślę, że być może utrata precyzji może nastąpić w domniemanej konwersji i nie nastąpi, gdy użyje się CAST lub CONVERT . Nie jest całkiem jasne ...

— CF

2

@CF Zgadzam się, że nie jest to bardzo jasne i zdecydowanie powinna istnieć bardziej szczegółowa dokumentacja na ten temat, więc miejmy nadzieję, że Microsoft to zrobi. Ale dobrze zauważony :)

— beruic

29

Konwertuj ma parametr stylu dla konwersji daty na ciąg znaków.

http://msdn.microsoft.com/en-us/library/ms187928.aspx

— Jason Saldo
źródło

12

CAST jest standardowym SQL, ale CONVERT dotyczy tylko dialektu T-SQL. Mamy małą zaletę konwersji w przypadku datetime.

Za pomocą CAST podajesz wyrażenie i typ docelowy; w przypadku CONVERT istnieje trzeci argument reprezentujący styl konwersji, który jest obsługiwany w przypadku niektórych konwersji, na przykład między ciągami znaków a wartościami daty i godziny. Na przykład CONVERT (DATE, '1/2/2012', 101) konwertuje dosłowny ciąg znaków na DATE przy użyciu stylu 101 reprezentującego standard Stanów Zjednoczonych.

— Abdeloihab Bourassi
źródło

8

Aby rozwinąć powyższą odpowiedź _{skopiowaną przez Shakti} , faktycznie byłem w stanie zmierzyć różnicę wydajności między tymi dwiema funkcjami.

Testowałem wydajność odmian rozwiązania tego pytania i stwierdziłem, że odchylenie standardowe i maksymalne czasy działania były większe przy użyciu CAST.

_{* Czasy w milisekundach, w zaokrągleniu do 1/300 sekundy, zgodnie z dokładnością DateTimetypu}

— Elaskanator
źródło

6

Coś, czego nikt jeszcze nie zauważył, to czytelność. Mający…

CONVERT(SomeType,
    SomeReallyLongExpression
    + ThatMayEvenSpan
    + MultipleLines
    )

… Może być łatwiejsze do zrozumienia niż…

CAST(SomeReallyLongExpression
    + ThatMayEvenSpan
    + MultipleLines
    AS SomeType
    )

— Atario
źródło

2

Ale myślę, że CAST jest zwykle bardziej czytelny. CAST(Column1 AS int)jest bardziej logiczne do odczytania niż w CONVERT(int, Column1)przypadku długich wyrażeń

— S.Serpooshan,

4

CAST wykorzystuje standard ANSI. W przypadku przenośności będzie to działać na innych platformach. CONVERT jest specyficzny dla serwera SQL. Ale to bardzo silna funkcja. Możesz określić różne style dla dat

— RakeshP
źródło