Sqlserver
 sql >> база данни >  >> RDS >> Sqlserver

PARSE() срещу CAST() срещу CONVERT() в SQL Server:Каква е разликата?

Може би сте се сблъсквали с T-SQL PARSE() , CAST() и CONVERT() функции при работа със SQL Server и се чудех каква е разликата. И трите функции изглежда вършат едно и също нещо, но има фини разлики между тях.

В тази статия се стремя да очертая основните разлики между тези функции.

Сравнение

Ето таблица, която очертава основните разлики между CONVERT() , CAST() и PARSE() функции в SQL Server:

CONVERT() CAST() PARSE()
Официална дефиниция Преобразува израз от един тип данни в друг. Преобразува израз от един тип данни в друг. Връща резултата от израз, преведен към искания тип данни в SQL Server.
Приета стойност Всеки валиден израз. Всеки валиден израз. Стринг.
Връщана стойност 2-ри аргумент, преведен към искания тип данни, както е предоставено от 1-вия аргумент. 1-ви аргумент, преведен към искания тип данни, както е предоставено от втория аргумент. 1-ви аргумент, преведен към искания тип данни, както е предоставено от втория аргумент.
Поддържани реализации Между всеки два типа данни. Между всеки два типа данни. Само от низ до дата/час и числови типове.
Приема стила Аргумент? Да. Не. Не.
Приема култура Аргумент? Не. Не. Да.
Изисква .NET Framework? Не. Не. Да.

Някои други точки в допълнение към горната таблица:

  • Документацията на Microsoft посочва, че PARSE() няма да бъде отдалечено (тъй като зависи от наличието на CLR). Отдалечаването на функция, която изисква CLR, би причинила грешка на отдалечения сървър.
  • Има някои стойности, които PARSE() може да се справи с но CAST() и CONVERT() не може (например низове, използващи определени формати за дата).
  • CAST() е включен в стандарта ANSI SQL-92.
  • Някои твърдят, че CAST() има по-добра производителност от другите две.
  • Има определени разходи за производителност при анализиране на стойности на низове. Следователно, PARSE() обикновено ще работи по-бавно от другите две.

По-долу са дадени примери за ситуации, в които всяка функция би била най-подходяща.

Кога да се използва CAST()

Може да се направи добър аргумент за използването на CAST() за всеки сценарий, който не е изброен по-долу. Както споменахме, CAST() е част от стандарта ANSI SQL от SQL-92, така че трябва да бъде по-преносим между различни СУБД (ако това е изискване).

Освен това някои твърдят, че CAST() има по-добра производителност от другите две (ето една интересна статия, която сравнява производителността и между трите функции).

Съществуват обаче и основателни причини, поради които може да предпочетете (или трябва) да използвате CONVERT() през CAST() .

Кога да се използва CONVERT()

CONVERT() функцията може да ви бъде полезна, когато трябва да използвате style аргумент, за да посочите как трябва да бъде форматирана датата при конвертиране между дата и низ. Ето няколко примера:

DECLARE @date datetime2 = '2018-06-07 02:35:52.8537677';
SELECT
    CONVERT(nvarchar(30), @date, 100) AS '100',
    CONVERT(nvarchar(30), @date, 101) AS '101',
    CONVERT(nvarchar(30), @date, 102) AS '102',
    CONVERT(nvarchar(30), @date, 103) AS '103';

Резултат:

+---------------------+------------+------------+------------+
| 100                 | 101        | 102        | 103        |
|---------------------+------------+------------+------------|
| Jun  7 2018  2:35AM | 06/07/2018 | 2018.06.07 | 07/06/2018 |
+---------------------+------------+------------+------------+

Можете да направите това само с CONVERT() защото:

  • CAST() не поддържа style аргумент; и
  • PARSE() не преобразува от дата/час в стойност на низ (също не поддържа style аргумент)

Кога да използвам PARSE()

Въпреки различните недостатъци на тази функция (производителност, зависимост от .NET, ограничено преобразуване на типове данни), тя също има някои предимства и има някои сценарии, при които може да бъде единственият ви избор. Например, когато предоставяте дата, която включва името на деня от седмицата, като петък, 20 юли 2018 г. .

Когато другите връщат грешка

Ето примери, където PARSE() е единствената функция от трите, която може успешно да преобразува стойността, без да хвърля грешка.

В тези примери се опитваме да преобразуваме различни стойности на низове в дата тип данни. Въпреки това, стойностите на низовете, които предоставяме, включват името на деня от седмицата. Това причинява проблеми за CAST() и CONVERT() , но PARSE() няма проблем.

PARSE()

SELECT 
    PARSE('Friday, 20 July 2018' AS date) AS 'Result 1',
    PARSE('Fri, 20 July 2018' AS date) AS 'Result 2',
    PARSE('Friday 20 July 2018' AS date) AS 'Result 3';

Резултат:

+------------+------------+------------+
| Result 1   | Result 2   | Result 3   |
|------------+------------+------------|
| 2018-07-20 | 2018-07-20 | 2018-07-20 |
+------------+------------+------------+

Така че PARSE() няма проблем с формата на датата, която предоставяме.

CONVERT()

SELECT 
    CONVERT(date, 'Friday, 20 July 2018') AS 'Result 1',
    CONVERT(date, 'Fri, 20 July 2018') AS 'Result 2',
    CONVERT(date, 'Friday 20 July 2018') AS 'Result 3';

Резултат:

Conversion failed when converting date and/or time from character string.

Така че CONVERT() не може да преобразува низа, когато е в такъв формат.

CAST()

SELECT 
    CAST('Friday, 20 July 2018' AS date) AS 'Result 1',
    CAST('Fri, 20 July 2018' AS date)AS 'Result 2',
    CAST('Friday 20 July 2018' AS date) AS 'Result 3';

Резултат:

Conversion failed when converting date and/or time from character string.

И CAST() връща същата грешка.

Така че, ако откриете, че получавате грешки с другите две функции, опитайте PARSE() вместо това.

Уточняване на културата

Друг сценарий, при който може да предпочетете да използвате PARSE() функцията е, когато указва културата/езика, на който се предоставя низът. PARSE() има незадължителен аргумент, който ви позволява да укажете коя култура да използвате. Ако е пропуснато, се използва езикът на текущата сесия.

Пример за включване на culture аргумент:

SELECT 
    PARSE('07/01/2018' AS date USING 'en-US') AS 'Result 1',
    PARSE('07/01/2018' AS date USING 'de-DE') AS 'Result 2';

Резултат:

+------------+------------+
| Result 1   | Result 2   |
|------------+------------|
| 2018-07-01 | 2018-01-07 |
+------------+------------+

Алтернатива на културата

Въпреки ползата от възможността да посочите културата с PARSE() , имате възможност да променяте езиковите настройки, което означава, че бихте могли да постигнете същия ефект, когато използвате CAST() или CONVERT() .

Например, като използвате SET LANGUAGE us_english преди заявката ще промени текущите езикови настройки на us_english . Въпреки че това не ви позволява да посочите различни култури в заявката (както в горния пример), то засяга цялата заявка (и всички последващи заявки).

Можете също да промените настройките за формата на датата по същия начин. Например, SET DATEFORMAT mdy .

Ето пример за промяна на езиковата настройка преди да стартирате заявка с CAST() и CONVERT() :

Немски:

SET LANGUAGE German;
SELECT CONVERT(date, '07/01/2018') AS 'Convert';
SELECT CAST('07/01/2018' AS date) AS 'Cast';

Резултат:

+------------+
| Convert    |
|------------|
| 2018-01-07 |
+------------+
Die Spracheneinstellung wurde in Deutsch geändert.
+------------+
| Cast       |
|------------|
| 2018-01-07 |
+------------+

us_english:

SET LANGUAGE us_english;
SELECT CONVERT(date, '07/01/2018') AS 'Convert';
SELECT CAST('07/01/2018' AS date) AS 'Cast';

Резултат:

+------------+
| Convert    |
|------------|
| 2018-07-01 |
+------------+
Changed language setting to us_english.
+------------+
| Cast       |
|------------|
| 2018-07-01 |
+------------+

Не забравяйте, че когато правите това, вие променяте средата на езика/формата на датата за сесията. Не забравяйте да го промените обратно!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Вземете текущата часова зона на сървъра в SQL Server (T-SQL)

  2. Форматиране на числа чрез запълване с водещи нули в SQL Server

  3. Обобщена таблица на SQL Server с множество агрегати на колони

  4. Весели туитове за живота на DBA

  5. Топ 3 причини хората да преминават към SaaS