wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Ms sql bigint: int, bigint, smallint и tinyint (Transact-SQL) — SQL Server

alexxlab
No Comments

Содержание

Как преобразовать bigint (временную метку UNIX) в datetime в SQL Server?

Это основано на работе, проделанной Дэниелом Литтлом для этого вопроса, но с учетом перехода на летнее время (работает для дат 01-01 1902 и более поздних из-за ограничения int в функции dateadd):

Сначала нам нужно создать таблицу, в которой будут храниться диапазоны дат для перехода на летнее время (источник: История времени в США ):

CREATE TABLE [dbo].[CFG_DAY_LIGHT_SAVINGS_TIME](
  [BEGIN_DATE] [datetime] NULL,
  [END_DATE] [datetime] NULL,
  [YEAR_DATE] [smallint] NULL
) ON [PRIMARY]

GO

INSERT INTO CFG_DAY_LIGHT_SAVINGS_TIME VALUES
('2001-04-01 02:00:00.000',   '2001-10-27 01:59:59.997',    2001),
('2002-04-07 02:00:00.000',   '2002-10-26 01:59:59.997',    2002),
('2003-04-06 02:00:00.000',   '2003-10-25 01:59:59.997',    2003),
('2004-04-04 02:00:00.000',   '2004-10-30 01:59:59.997',    2004),
('2005-04-03 02:00:00.000',   '2005-10-29 01:59:59.997',    2005),
('2006-04-02 02:00:00. 000',   '2006-10-28 01:59:59.997',    2006),
('2007-03-11 02:00:00.000',   '2007-11-03 01:59:59.997',    2007),
('2008-03-09 02:00:00.000',   '2008-11-01 01:59:59.997',    2008),
('2009-03-08 02:00:00.000',   '2009-10-31 01:59:59.997',    2009),
('2010-03-14 02:00:00.000',   '2010-11-06 01:59:59.997',    2010),
('2011-03-13 02:00:00.000',   '2011-11-05 01:59:59.997',    2011),
('2012-03-11 02:00:00.000',   '2012-11-03 01:59:59.997',    2012),
('2013-03-10 02:00:00.000',   '2013-11-02 01:59:59.997',    2013),
('2014-03-09 02:00:00.000',   '2014-11-01 01:59:59.997',    2014),
('2015-03-08 02:00:00.000',   '2015-10-31 01:59:59.997',    2015),
('2016-03-13 02:00:00.000',   '2016-11-05 01:59:59.997',    2016),
('2017-03-12 02:00:00.000',   '2017-11-04 01:59:59.997',    2017),
('2018-03-11 02:00:00.000',   '2018-11-03 01:59:59.997',    2018),
('2019-03-10 02:00:00.000',   '2019-11-02 01:59:59.997',    2019),
('2020-03-08 02:00:00.000',   '2020-10-31 01:59:59.997',    2020),
('2021-03-14 02:00:00. 000',   '2021-11-06 01:59:59.997',    2021),
('2022-03-13 02:00:00.000',   '2022-11-05 01:59:59.997',    2022),
('2023-03-12 02:00:00.000',   '2023-11-04 01:59:59.997',    2023),
('2024-03-10 02:00:00.000',   '2024-11-02 01:59:59.997',    2024),
('2025-03-09 02:00:00.000',   '2025-11-01 01:59:59.997',    2025),
('1967-04-30 02:00:00.000',   '1967-10-29 01:59:59.997',    1967),
('1968-04-28 02:00:00.000',   '1968-10-27 01:59:59.997',    1968),
('1969-04-27 02:00:00.000',   '1969-10-26 01:59:59.997',    1969),
('1970-04-26 02:00:00.000',   '1970-10-25 01:59:59.997',    1970),
('1971-04-25 02:00:00.000',   '1971-10-31 01:59:59.997',    1971),
('1972-04-30 02:00:00.000',   '1972-10-29 01:59:59.997',    1972),
('1973-04-29 02:00:00.000',   '1973-10-28 01:59:59.997',    1973),
('1974-01-06 02:00:00.000',   '1974-10-27 01:59:59.997',    1974),
('1975-02-23 02:00:00.000',   '1975-10-26 01:59:59.997',    1975),
('1976-04-25 02:00:00.000',   '1976-10-31 01:59:59.997',    1976),
('1977-04-24 02:00:00. 000',   '1977-10-31 01:59:59.997',    1977),
('1978-04-30 02:00:00.000',   '1978-10-29 01:59:59.997',    1978),
('1979-04-29 02:00:00.000',   '1979-10-28 01:59:59.997',    1979),
('1980-04-27 02:00:00.000',   '1980-10-26 01:59:59.997',    1980),
('1981-04-26 02:00:00.000',   '1981-10-25 01:59:59.997',    1981),
('1982-04-25 02:00:00.000',   '1982-10-25 01:59:59.997',    1982),
('1983-04-24 02:00:00.000',   '1983-10-30 01:59:59.997',    1983),
('1984-04-29 02:00:00.000',   '1984-10-28 01:59:59.997',    1984),
('1985-04-28 02:00:00.000',   '1985-10-27 01:59:59.997',    1985),
('1986-04-27 02:00:00.000',   '1986-10-26 01:59:59.997',    1986),
('1987-04-05 02:00:00.000',   '1987-10-25 01:59:59.997',    1987),
('1988-04-03 02:00:00.000',   '1988-10-30 01:59:59.997',    1988),
('1989-04-02 02:00:00.000',   '1989-10-29 01:59:59.997',    1989),
('1990-04-01 02:00:00.000',   '1990-10-28 01:59:59.997',    1990),
('1991-04-07 02:00:00.000',   '1991-10-27 01:59:59.997',    1991),
('1992-04-05 02:00:00. 000',   '1992-10-25 01:59:59.997',    1992),
('1993-04-04 02:00:00.000',   '1993-10-31 01:59:59.997',    1993),
('1994-04-03 02:00:00.000',   '1994-10-30 01:59:59.997',    1994),
('1995-04-02 02:00:00.000',   '1995-10-29 01:59:59.997',    1995),
('1996-04-07 02:00:00.000',   '1996-10-27 01:59:59.997',    1996),
('1997-04-06 02:00:00.000',   '1997-10-26 01:59:59.997',    1997),
('1998-04-05 02:00:00.000',   '1998-10-25 01:59:59.997',    1998),
('1999-04-04 02:00:00.000',   '1999-10-31 01:59:59.997',    1999),
('2000-04-02 02:00:00.000',   '2000-10-29 01:59:59.997',    2000)
GO

Теперь мы создаем функцию для каждого американского часового пояса. Предполагается, что время unix указано в миллисекундах. Если это в секундах, удалите / 1000 из кода:

Тихий океан

create function [dbo].[UnixTimeToPacific] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @pacificdatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @pacificdatetime =  dateadd(hour,case when @interimdatetime between begin_date and end_date then -7 else -8 end  ,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)
     if @pacificdatetime is null 
       select @pacificdatetime= dateadd(hour, -7, @interimdatetime)
return @pacificdatetime    
end

Восточная

create function [dbo]. [UnixTimeToEastern] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @easterndatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @easterndatetime =  dateadd(hour,case when @interimdatetime between begin_date and end_date then -4 else -5 end  ,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)
     if @easterndatetime is null 
       select @easterndatetime= dateadd(hour, -4, @interimdatetime)
return @easterndatetime    
end

Центральная

create function [dbo].[UnixTimeToCentral] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @centraldatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @centraldatetime =  dateadd(hour,case when @interimdatetime between begin_date and end_date then -5 else -6 end  ,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)
     if @centraldatetime is null 
       select @centraldatetime= dateadd(hour, -5, @interimdatetime)
return @centraldatetime    
end

Гора

create function [dbo]. [UnixTimeToMountain] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @mountaindatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @mountaindatetime =  dateadd(hour,case when @interimdatetime between begin_date and end_date then -6 else -7 end  ,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)
     if @mountaindatetime is null 
       select @mountaindatetime= dateadd(hour, -6, @interimdatetime)
return @mountaindatetime    
end

Гавайи

create function [dbo].[UnixTimeToHawaii] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @hawaiidatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @hawaiidatetime =  dateadd(hour,-10,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)

return @hawaiidatetime    
end

Аризона

create function [dbo]. [UnixTimeToArizona] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @arizonadatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @arizonadatetime =  dateadd(hour,-7,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)

return @arizonadatetime    
end

Аляска

create function [dbo].[UnixTimeToAlaska] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @alaskadatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @alaskadatetime =  dateadd(hour,case when @interimdatetime between begin_date and end_date then -8 else -9 end  ,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)
     if @alaskadatetime is null 
       select @alaskadatetime= dateadd(hour, -8, @interimdatetime)
return @alaskadatetime    
end

Типы данных Microsoft SQL Server

Полный список всех типов данных в Microsoft SQL Server

Заголовки:

Источники

Приоритет типов данных (Transact-SQL)

Если оператор связывает два выражения различных типов данных, то по правилам приоритета типов данных определяется, какой тип данных имеет меньший приоритет и будет преобразован в тип данных с большим приоритетом.
Если неявное преобразование не поддерживается, возвращается ошибка.
Если оба операнда выражения имеют одинаковый тип данных, результат операции будет иметь тот же тип данных.

В SQL Server используется следующий приоритет типов данных:

  1. sql_variant
  2. xml
  3. datetimeoffset
  4. datetime2
  5. datetime
  6. smalldatetime
  7. date
  8. time
  9. float
  10. real
  11. decimal
  12. money
  13. smallmoney
  14. bigint
  15. int
  16. smallint
  17. tinyint
  18. bit
  19. ntext
  20. text
  21. image
  22. timestamp
  23. uniqueidentifier
  24. nvarchar (including nvarchar(max) )
  25. nchar
  26. varchar (including varchar(max) )
  27. char
  28. varbinary (including varbinary(max) )
  29. binary (lowest)

Синонимы типов данных (Transact-SQL)

Синонимы типов данных включены в SQL Server ради совместимости со спецификацией ISO.
Эти синонимы и соответствующие им системные типы данных SQL Server приведены в следующей таблице.

СинонимСистемный тип данных SQL Server
Binary varyingvarbinary
char varyingvarchar
characterchar
characterchar(1)
character(n)char(n)
character varying(n)varchar(n)
Decdecimal
Double precisionfloat
float[(n)] for n = 1-7real
float[(n)] for n = 8-15float
integerint
national character(n)nchar(n)
national char(n)nchar(n)
national character varying(n)nvarchar(n)
national char varying(n)nvarchar(n)
national textntext
timestamprowversion

Синонимы типов данных можно использовать вместо соответствующих базовых типов данных в инструкциях языка определения данных (data definition language, DDL),
таких как CREATE TABLE, CREATE PROCEDURE или DECLARE @variable. Однако после создания объекта синонимы утрачивают силу.
При создании объекта ему назначается базовый тип данных, связанный с синонимом.
Никаких признаков того, что в инструкции, создавшей объект, был указан синоним, не остается.

Всем объектам, производным от первоначального объекта, таким, как столбцы результирующего набора или выражения, назначается базовый тип данных.
Все последующие вызовы функций работы с метаданными, выполняемые для первоначального объекта и любых производных от него объектов, сообщают базовый тип данных,
а не синоним. Это имеет место при работе с метаданными, например в процедуре sp_help и других системных хранимых процедурах, представлениях информационных схем и различных API-операции над метаданными, сообщающих типы данных столбцов таблицы или результирующего набора.

Точность, масштаб и длина (Transact-SQL)

Точность представляет собой количество цифр в числе. Масштаб представляет собой количество цифр справа от десятичной запятой в числе. Например: число 123,45 имеет точность 5 и масштаб 2.

В среде SQL Server максимальная точность типов данных numeric и decimal по умолчанию составляет 38 разрядов. В более ранних версиях SQL Server максимум по умолчанию составляет 28.

Длиной для числовых типов данных является количество байт, используемых для хранения числа. Длина символьной строки или данных в Юникоде равняется количеству символов. Длина для типов данных binary, varbinary и image равна количеству байт. Например, тип данных int может содержать 10 разрядов, храниться в 4 байтах и не должен содержать десятичный разделитель. Тип данных int имеет точность 10, длину 4 и масштаб 0.

При сцеплении двух выражений типа char, varchar, binary или varbinary длина результирующего выражения является суммой длин двух исходных выражений, но не превышает 8 000 символов.

При сцеплении двух выражений типа nchar или nvarchar длина результирующего выражения является суммой длин двух исходных выражений, но не превышает 4 000 символов.

Если два выражения одного и того же типа данных, но разной длины, сравниваются с помощью предложения UNION, EXCEPT или INTERSECT, длина результата будет равняться длине максимального из двух выражений.

Точность и масштаб числовых типов данных, кроме decimal, фиксированы. Если арифметический оператор объединяет два выражения одного и того же типа, результат будет иметь тот же тип данных с точностью и масштабом, определенными для этого типа. Если оператор объединяет два выражения с различными числовыми типами данных, тип данных результата будет определяться правилами старшинства типов данных. Результат имеет точность и масштаб, определенные для этого типа данных.

Следующая таблица определяет, как вычисляется точность и масштаб результата, если результат операции имеет тип decimal. Результат имеет тип decimal, если одно из следующих утверждений является истиной:

  • Оба выражения имеют тип decimal.
  • Одно выражение имеет тип decimal, а другое имеет тип данных со старшинством меньше, чем decimal.

Выражения операндов обозначены как выражение e1 с точностью p1 и масштабом s1 и выражение e2 с точностью p2 и масштабом s2. Точность и масштаб для любого выражения, отличного от decimal, соответствуют типу данных этого выражения

ОперацияТочность результатаМасштаб результата *
e1 + e2max(s1, s2) + max(p1-s1, p2-s2) + 1max(s1, s2)
e1 — e2max(s1, s2) + max(p1-s1, p2-s2) + 1max(s1, s2)
e1 * e2p1 + p2 + 1s1 + s2
e1 / e2p1 — s1 + s2 + max(6, s1 + p2 + 1)max(6, s1 + p2 + 1)
e1 { UNION | EXCEPT | INTERSECT } e2max(s1, s2) + max(p1-s1, p2-s2)max(s1, s2)
e1 % e2min(p1-s1, p2 -s2) + max( s1,s2 )max(s1, s2)

* Точность и масштаб результата имеют абсолютный максимум, равный 38. Если значение точности превышает 38, то соответствующее значение масштаба уменьшается, чтобы по возможности предотвратить усечение целой части результата.

SQL Server, SSIS и Biml типы данных

Таблица ниже является упрощенной схемой связи между типами данныхSQL Server, SSIS и Biml.
Таблица не включает все возможные комбинации и все виды типов данных, но полезна как быстрая ссылка при разработке и изучении Biml.

SQL ServerSSIS VariablesSSIS Pipeline BufferOLE DBADO.NETBiml
bigintInt64DT_I8LARGE_INTEGERInt64Int64
binaryObjectDT_BYTES—BinaryBinary
bitBooleanDT_BOOLVARIANT_BOOLBooleanBoolean
charStringDT_STRVARCHARStringFixedLengthAnsiStringFixedLength
dateObjectDT_DBDATEDBDATEDateDate
datetimeDateTimeDT_DBTIMESTAMPDATEDateTimeDateTime
datetime2ObjectDT_DBTIMESTAMP2DBTIME2DateTime2DateTime2
datetimeoffsetObjectDT_DBTIMESTAMPOFFSETDBTIMESTAMPOFFSETDateTimeOffsetDateTimeOffset
decimalDecimalDT_NUMERICNUMERICDecimalDecimal
floatDoubleDT_R8FLOATDoubleDouble
geography—DT_IMAGE—ObjectObject
geometry—DT_IMAGE—ObjectObject
hierarchyid—DT_BYTES—ObjectObject
image (*)ObjectDT_IMAGE—BinaryBinary
intInt32DT_I4LONGInt32Int32
moneyObjectDT_CY, DT_NUMERICCURRENCYCurrencyCurrency
ncharStringDT_WSTRNVARCHARStringFixedLengthStringFixedLength
ntext (*)StringDT_NTEXT—StringString
numericDecimalDT_NUMERICNUMERICDecimalDecimal
nvarcharStringDT_WSTRNVARCHARStringString
nvarchar(max)ObjectDT_NTEXT——String
realSingleDT_R4FLOAT, DOUBLESingleSingle
rowversionObjectDT_BYTES—BinaryBinary
smalldatetimeDateTimeDT_DBTIMESTAMPDATEDateTimeDateTime
smallintInt16DT_I2SHORTInt16Int16
smallmoneyObjectDT_CY, DT_NUMERICCURRENCYCurrencyCurrency
sql_variantObjectDT_WSTR, DT_NTEXT—ObjectObject
tableObject————
text (*)ObjectDT_TEXT——AnsiString
timeObjectDT_DBTIME2DBTIME2TimeTime
timestamp (*)ObjectDT_BYTES—BinaryBinary
tinyintByteDT_UI1BYTEByteByte
uniqueidentifierString, ObjectDT_GUIDGUIDGuidGuid
varbinaryObjectDT_BYTES—BinaryBinary
varbinary(max)ObjectDT_IMAGE—BinaryBinary
varcharStringDT_STRVARCHARStringAnsiString
varchar(max)ObjectDT_TEXT——AnsiString
xmlObjectDT_NTEXT——Xml

(* Данные типы данных будут удалены в будущих версиях SQL Server. 38 -1Exact Numericssmallmoney4-214 748.3648 to 214 748.3647Exact Numericsmoney8-922 337 203 685 477.5808 to 922 337 203 685 477.5807Approximate Numericsfloat1-24
25-537
154
8-3.40E+38 to -1.18E-38, 0 and 1.18E-38 to 3.40E+38
-1.79E+308 to -2.23E-308, 0 and 2.23E-308 to 1.79E+308Date and Timedate30001-01-01 through 9999-12-31
January 1, 1 CE through December 31, 9999 CEDate and Timesmalldatetime41900-01-01 through 2079-06-06
January 1, 1900 through June 6, 2079
00:00:00 through 23:59:59Date and Timetime8-11
12-13
14-163
4
500:00:00.0000000 through 23:59:59.9999999Date and Timedatetime21-2
3-4
5-76
7
80001-01-01 through 9999-12-31
January 1, 1 CE through December 31, 9999 CE
00:00:00 through 23:59:59. 31 — 1)n + 2Other Data TypescursorOther Data Typessql_variantmax 8016Other Data Typeshierarchyidmax 892Other Data Typesrowversion8Other Data Typestimestamp(*)Other Data Typesuniqueidentifier16Other Data Typesxmlmax 2GbOther Data TypestableSpatial Data TypesgeometrySpatial Data Typesgeography

SQL Server to MySQL, Oracle, PostgreSQL, SQLite Data Type Mapping

General TypeTypeMySQLOraclePostgreSQLSQLite
Exact NumericsbitTINYINT(1)NUMBER(3)BOOLEANINTEGER
Exact NumericstinyintTINYINT(signed)NUMBER(3)SMALLINTINTEGER
Exact NumericssmallintSMALLINTNUMBER(5)SMALLINTINTEGER
Exact NumericsintMEDIUMINT, INTNUMBER(10)INTINTEGER
Exact NumericsbigintBIGINTNUMBER(19)BIGINTINTEGER
Exact NumericsdecimalDECIMALNUMBER(p[,s])DECIMAL(p,s)REAL
Exact NumericssmallmoneyDOUBLENUMBER(10,4)MONEYREAL
Exact NumericsmoneyDOUBLENUMBER(19,4)MONEYREAL
Approximate NumericsfloatFLOAT
DOUBLE; REAL		FLOAT(49)DOUBLE PRECISIONREAL
Date and TimedateDATEDATETEXT
Date and TimesmalldatetimeTIMESTAMPDATETIMESTAMP(0)TEXT
Date and TimetimeTIMETIMETEXT
Date and Timedatetime2DDATETIMETIMESTAMPTEXT
Date and TimedatetimeDATETIMESTAMP(3)TEXT
Date and timedatetimeoffsetTIMESTAMP
with time zone		TEXT
Caracter StringscharCHARCHARCHARTEXT
Caracter StringsvarcharVARCHARVARCHAR2VARCHARTEXT
Caracter Stringsvarchar(max)VARCHAR2TEXTTEXT
Caracter StringsncharNCHARNCHARTEXT
Caracter StringsnvarcharNCHARVARCHARTEXT
Caracter Stringsnvarchar(max)VARCHAR
TINYTEXT
TEXT(M)
MEDIUMTEXT
LONGTEXT		NCHARTEXTTEXT
Caracter Stringsntext(*)LONGTEXTTEXT
Caracter Stringstext(*)LONGTEXTTEXT
Binary Stringsimage(*)LONGBLOBLONG RAWBYTEABLOB
Binary StringsbinaryBINARYRAWBYTEABLOB
Binary StringsvarbinaryRAWBYTEABLOB
Binary Stringsvarbinary(max)VARBINARY(M)
TINYBLOB
BLOB
MEDIUMBLOB
LONGBLOB		RAWBYTEABLOB
Other Data TypescursorTEXT
Other Data Typessql_variantBLOBTEXT
Other Data TypeshierarchyidTEXT
Other Data TypesrowversionBYTEATEXT
Other Data Typestimestamp(*)RAWBYTEATEXT
Other Data TypesuniqueidentifierCHARCHAR(36)CHAR(16)TEXT
Other Data TypesxmlXMLTEXT
Other Data Typestable—
Spatial Data TypesgeometryVARCHARTEXT
Spatial Data TypesgeographyVARCHARTEXT

(* Данные типы данных будут удалены в будущих версиях SQL Server.
Избегайте использование этих типов данных в новых проектах и, по возможности, измените их в текущих проектах.)

Как я могу преобразовать bigint (UNIX timestamp) в datetime в SQL Server?

Это строит работу, проделанную Даниэлем Литтлом для этого вопроса, но с учетом перехода на летнее время (работает для дат 01-01 1902 и выше из-за ограничения int на функцию dateadd):

Сначала нам нужно создать таблицу, в которой будут храниться диапазоны дат для летнего времени (источник: история времени в США ):

CREATE TABLE [dbo].[CFG_DAY_LIGHT_SAVINGS_TIME](
  [BEGIN_DATE] [datetime] NULL,
  [END_DATE] [datetime] NULL,
  [YEAR_DATE] [smallint] NULL
) ON [PRIMARY]

GO

INSERT INTO CFG_DAY_LIGHT_SAVINGS_TIME VALUES
('2001-04-01 02:00:00.000',   '2001-10-27 01:59:59.997',    2001),
('2002-04-07 02:00:00.000',   '2002-10-26 01:59:59.997',    2002),
('2003-04-06 02:00:00.000',   '2003-10-25 01:59:59.997',    2003),
('2004-04-04 02:00:00. 000',   '2004-10-30 01:59:59.997',    2004),
('2005-04-03 02:00:00.000',   '2005-10-29 01:59:59.997',    2005),
('2006-04-02 02:00:00.000',   '2006-10-28 01:59:59.997',    2006),
('2007-03-11 02:00:00.000',   '2007-11-03 01:59:59.997',    2007),
('2008-03-09 02:00:00.000',   '2008-11-01 01:59:59.997',    2008),
('2009-03-08 02:00:00.000',   '2009-10-31 01:59:59.997',    2009),
('2010-03-14 02:00:00.000',   '2010-11-06 01:59:59.997',    2010),
('2011-03-13 02:00:00.000',   '2011-11-05 01:59:59.997',    2011),
('2012-03-11 02:00:00.000',   '2012-11-03 01:59:59.997',    2012),
('2013-03-10 02:00:00.000',   '2013-11-02 01:59:59.997',    2013),
('2014-03-09 02:00:00.000',   '2014-11-01 01:59:59.997',    2014),
('2015-03-08 02:00:00.000',   '2015-10-31 01:59:59.997',    2015),
('2016-03-13 02:00:00.000',   '2016-11-05 01:59:59.997',    2016),
('2017-03-12 02:00:00.000',   '2017-11-04 01:59:59.997',    2017),
('2018-03-11 02:00:00.000',   '2018-11-03 01:59:59.997',    2018),
('2019-03-10 02:00:00. 000',   '2019-11-02 01:59:59.997',    2019),
('2020-03-08 02:00:00.000',   '2020-10-31 01:59:59.997',    2020),
('2021-03-14 02:00:00.000',   '2021-11-06 01:59:59.997',    2021),
('2022-03-13 02:00:00.000',   '2022-11-05 01:59:59.997',    2022),
('2023-03-12 02:00:00.000',   '2023-11-04 01:59:59.997',    2023),
('2024-03-10 02:00:00.000',   '2024-11-02 01:59:59.997',    2024),
('2025-03-09 02:00:00.000',   '2025-11-01 01:59:59.997',    2025),
('1967-04-30 02:00:00.000',   '1967-10-29 01:59:59.997',    1967),
('1968-04-28 02:00:00.000',   '1968-10-27 01:59:59.997',    1968),
('1969-04-27 02:00:00.000',   '1969-10-26 01:59:59.997',    1969),
('1970-04-26 02:00:00.000',   '1970-10-25 01:59:59.997',    1970),
('1971-04-25 02:00:00.000',   '1971-10-31 01:59:59.997',    1971),
('1972-04-30 02:00:00.000',   '1972-10-29 01:59:59.997',    1972),
('1973-04-29 02:00:00.000',   '1973-10-28 01:59:59.997',    1973),
('1974-01-06 02:00:00.000',   '1974-10-27 01:59:59.997',    1974),
('1975-02-23 02:00:00.000',   '1975-10-26 01:59:59.997',    1975),
('1976-04-25 02:00:00.000',   '1976-10-31 01:59:59.997',    1976),
('1977-04-24 02:00:00.000',   '1977-10-31 01:59:59.997',    1977),
('1978-04-30 02:00:00.000',   '1978-10-29 01:59:59.997',    1978),
('1979-04-29 02:00:00.000',   '1979-10-28 01:59:59.997',    1979),
('1980-04-27 02:00:00.000',   '1980-10-26 01:59:59.997',    1980),
('1981-04-26 02:00:00.000',   '1981-10-25 01:59:59.997',    1981),
('1982-04-25 02:00:00.000',   '1982-10-25 01:59:59.997',    1982),
('1983-04-24 02:00:00.000',   '1983-10-30 01:59:59.997',    1983),
('1984-04-29 02:00:00.000',   '1984-10-28 01:59:59.997',    1984),
('1985-04-28 02:00:00.000',   '1985-10-27 01:59:59.997',    1985),
('1986-04-27 02:00:00.000',   '1986-10-26 01:59:59.997',    1986),
('1987-04-05 02:00:00.000',   '1987-10-25 01:59:59.997',    1987),
('1988-04-03 02:00:00.000',   '1988-10-30 01:59:59.997',    1988),
('1989-04-02 02:00:00.000',   '1989-10-29 01:59:59.997',    1989),
('1990-04-01 02:00:00.000',   '1990-10-28 01:59:59.997',    1990),
('1991-04-07 02:00:00.000',   '1991-10-27 01:59:59.997',    1991),
('1992-04-05 02:00:00.000',   '1992-10-25 01:59:59.997',    1992),
('1993-04-04 02:00:00.000',   '1993-10-31 01:59:59.997',    1993),
('1994-04-03 02:00:00.000',   '1994-10-30 01:59:59.997',    1994),
('1995-04-02 02:00:00.000',   '1995-10-29 01:59:59.997',    1995),
('1996-04-07 02:00:00.000',   '1996-10-27 01:59:59.997',    1996),
('1997-04-06 02:00:00.000',   '1997-10-26 01:59:59.997',    1997),
('1998-04-05 02:00:00.000',   '1998-10-25 01:59:59.997',    1998),
('1999-04-04 02:00:00.000',   '1999-10-31 01:59:59.997',    1999),
('2000-04-02 02:00:00.000',   '2000-10-29 01:59:59.997',    2000)
GO

Теперь мы создаем функцию для каждого американского часового пояса. Это при условии, что время Unix в миллисекундах. Если это в секундах, удалите / 1000 из кода:

миролюбивый

create function [dbo].[UnixTimeToPacific] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @pacificdatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @pacificdatetime =  dateadd(hour,case when @interimdatetime between begin_date and end_date then -7 else -8 end  ,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)
     if @pacificdatetime is null 
       select @pacificdatetime= dateadd(hour, -7, @interimdatetime)
return @pacificdatetime    
end

восточный

create function [dbo].[UnixTimeToEastern] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @easterndatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @easterndatetime =  dateadd(hour,case when @interimdatetime between begin_date and end_date then -4 else -5 end  ,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)
     if @easterndatetime is null 
       select @easterndatetime= dateadd(hour, -4, @interimdatetime)
return @easterndatetime    
end

центральный

create function [dbo].[UnixTimeToCentral] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @centraldatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @centraldatetime =  dateadd(hour,case when @interimdatetime between begin_date and end_date then -5 else -6 end  ,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)
     if @centraldatetime is null 
       select @centraldatetime= dateadd(hour, -5, @interimdatetime)
return @centraldatetime    
end

гора

create function [dbo].[UnixTimeToMountain] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @mountaindatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @mountaindatetime =  dateadd(hour,case when @interimdatetime between begin_date and end_date then -6 else -7 end  ,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)
     if @mountaindatetime is null 
       select @mountaindatetime= dateadd(hour, -6, @interimdatetime)
return @mountaindatetime    
end

Гавайи

create function [dbo].[UnixTimeToHawaii] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @hawaiidatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @hawaiidatetime =  dateadd(hour,-10,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)

return @hawaiidatetime    
end

Аризона

create function [dbo].[UnixTimeToArizona] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @arizonadatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @arizonadatetime =  dateadd(hour,-7,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)

return @arizonadatetime    
end

Аляска

create function [dbo].[UnixTimeToAlaska] 
 (@unixtime bigint)
   returns datetime
   as
   begin
     declare @alaskadatetime datetime
     declare @interimdatetime datetime = dateadd(s, @unixtime/1000, '1970-01-01')
     select  @alaskadatetime =  dateadd(hour,case when @interimdatetime between begin_date and end_date then -8 else -9 end  ,@interimdatetime)
     from cfg_day_light_savings_time  where  year_date = datepart(year,@interimdatetime)
     if @alaskadatetime is null 
       select @alaskadatetime= dateadd(hour, -8, @interimdatetime)
return @alaskadatetime    
end

Автор: jymbo
Размещён: 27.03.2017 08:09

T-SQL — диалект языка программирования SQL

T-SQL или Transact-SQL — диалект SQL, реализуемый компанией Microsoft в своих продуктах Microsoft SQL Server

Примеры:

Числа Фибоначчи:

Пример для версий

Microsoft SQL Server 2005,

Microsoft SQL Server 2008 R2,

Microsoft SQL Server 2012

Используется возможность рекурсивных запросов. Кол-во членов ряда — 92

declare @max_n tinyint = 92
;with t as (
	select n = 1, fib = convert(bigint,1), xfib = convert(bigint,0)
	 union all		  
	select n = n+1, fib = fib+xfib, xfib = fib from t 
        where n < @max_n
)
select fib from t

Числа Фибоначчи:

Пример для версий

Microsoft SQL Server 2005,

Microsoft SQL Server 2008 R2,

Microsoft SQL Server 2012

Используется итеративное определение чисел Фибоначчи, реализованное через рекурсивный запрос. Каждая строка запроса содержит два соседних числа последовательности, и следующая строка вычисляется как (последнее число, сумма чисел) предыдущей строки. Таким образом все числа, кроме первого и последнего, встречаются дважды, поэтому в результат входят только первые числа каждой строки.

with fibonacci(a, b) as
(
 select 1, 1
  union all
 select b, a+b from fibonacci where b < 1000
)
SELECT cast(a as varchar)+', ' AS [text()]
  FROM fibonacci
   FOR XML PATH ('')

Факториал:

Пример для версий

Microsoft SQL Server 2005

declare @max_n tinyint = 20
;with t as (
   select 1 as n, convert(bigint,1) as f
   union all
   select n+1, f*(n+1) from t
   where n < @max_n
   
)
select convert(varchar,n)+'! = '+convert(varchar(32),f)+', ' 
from t as [text] 
FOR XML PATH ('')

Руководство по SQL. Типы данных. – PROSELYTE

Тип данных в языке структурированных запросов SQL – это атрибут, которые определяет тип данных любого объекта. Каждая колонка, переменная и выражение должны относится к одному из типов данных SQL.

Мы используем типы данных во время создания таблиц, определяя, к какому именно из них принадлежит каждая колонка нашей таблицы.

Ниже приведены типы данных языка SQL, разделённые по категориям:

  • целочисленные
  • числа с плавающей точкой
  • время и дата
  • символы
  • символы Unicode
  • бинарные
  • другие

Целочисленные типы данных

Тип данныхОтДо
bigint-9,223,372,036,854,775,8089,223,372,036,854,775,807
int-2,147,483,6482,147,483,647
smallint-32,76832,767
tinyint0255
bit01
decimal-10^38 +110^38 -1
numeric-10^38 +110^38 -1
money-922,337,203,685,477.5808+922,337,203,685,477.5807
smallmoney-214,748.3648+214,748.3647

Типы данных с плавающей точкой

Тип данныхОтДо
float-1.79E + 3081.79E + 308
real-3.40E + 383.40E + 38

Время и дата

Тип данныхОтДо
datetime1 Января, 175331 Декабря, 9999
smalldatetime1 Января, 19006 Июня, 2079
dateХранит дату в формате May 30, 2016
timeХранит время в формате 15:30 P.M.

Символы

Тип данныхОписание
charМаксимальная длина – 8,000 символов. (Фиксированная длина символов, которые не входят в Unicode)
varcharМаксимальная длина – 8,000 символов. (Изменяющаяся длина данных, не входящих в Unicode).
varchar(max)Максимальная длина – 231characters, Изменяющаяся длина данных, не входящих в Unicode (только для SQL Server 2005).
textИзменяющаяся длина данных, не входящих в Unicode с максимальной длинной – 2,147,483,647 символов.

Символы Unicode

Тип данныхОписание
ncharМаксимальная длина – 4,000 символов.( Фиксированная длина Unicode)
nvarcharМаксимальная длина – 4,000 символов.( Изменяющаяся длина Unicode)
nvarchar(max)Максимальная длина – 231 символ. ( Изменяющаяся длина Unicode, только для SQL Server 2005)
ntextМаксимальная длина – 1,073,741,823 символов. ( Изменяющаяся длина Unicode)

Бинарные типы данных

Тип данныхОписание
binaryМаксимальная длина – 8,000 байтов.( Фиксированная длина бинарных данных)
varbinaryМаксимальная длина – 8,000 байтов.( Изменяющаяся длина бинарных данных)
varbinary(max)Максимальная длина – 231 байт.(Фиксированная длина бинарных данных. Только для SQL Server 2005)
imageМаксимальная длина – 2,147,483,647 байтов. ( Изменяющаяся длина бинарных данных)

Другие типы данных

Тип данныхОписание
sql_variantХранит значения различных типов данных, поддерживаемых сервером SQL, за исключением, text, ntext и timestamp.
timestampХранит уникальное для базы данных значение, которое обновляется при каждом изменении записи.
uniqueidentifierХранит глобальный уникальный идентификатор (GUID)
xmlХранит XML данные. Мы можем хранить экземпляр xml в колонке, либо в переменной ( Только для SQL Server 2005).
cursorХранит ссылку на курсор.
tableХранит результирующее множество для крайней обработки.

На этом мы заканчиваем изучение типов данных.

В следующей статье мы рассмотрим операторы языка структурированных запросов SQL.

Числовые типы — SQL Server

  • 2 минуты на чтение

    • M

    • j

    • c

    • м

    • c

    • +2

В этой статье

Применимо к: SQL Server (все поддерживаемые версии) База данных SQL Azure Управляемый экземпляр SQL Azure Azure Synapse Analytics Хранилище параллельных данных

SQL Server поддерживает следующие числовые типы .

В этом разделе

бит (Transact-SQL)
десятичный и числовой (Transact-SQL)
вещественный и вещественный (Transact-SQL)
int, bigint, smallint и tinyint (Transact-SQL)
money and smallmoney (Transact-SQL)

Эта страница полезна?

да

Нет

Любой дополнительный отзыв?

Отзыв будет отправлен в Microsoft: при нажатии кнопки «Отправить» ваш отзыв будет использован для улучшения продуктов и услуг Microsoft.Политика конфиденциальности.

Пропускать
Представлять на рассмотрение

Спасибо.

Тема

  • Свет

  • Темный

  • Высокий контраст

  • Документы предыдущей версии
  • Блог
  • Внести вклад
  • Конфиденциальность и файлы cookie
  • Условия использования
  • Товарные знаки
  • © Microsoft 2021

Разница между типом данных INT и BIGINT в Sql Server

И INT, и BIGINT являются точными числовыми типами данных, используемыми для хранения целочисленных значений.63-1) Пример использования 

ОБЪЯВИТЬ @i INT
УСТАНОВИТЬ @i = 150
ПЕЧАТЬ @i

РЕЗУЛЬТАТ:
150

ОБЪЯВИТЬ @i BIGINT
УСТАНОВИТЬ @i = 150
ПЕЧАТЬ @i

РЕЗУЛЬТАТ:
150

Пример размера хранилища, используемого переменной для хранения значения 
ОБЪЯВИТЬ @i INT
УСТАНОВИТЬ @i = 150
ПЕЧАТЬ ДАННЫХ (@i)

РЕЗУЛЬТАТ:
4

ОБЪЯВИТЬ @i BIGINT
УСТАНОВИТЬ @i = 150
ПЕЧАТЬ ДАННЫХ (@i)

РЕЗУЛЬТАТ:
8

Пример значения INT вне диапазона 
ОБЪЯВИТЬ @i INT
НАБОР @i = 2147483648
ПЕЧАТЬ @i

РЕЗУЛЬТАТ:

Msg 8115, уровень 16, состояние 2, строка 2
Ошибка арифметического переполнения при преобразовании выражения в тип данных int.

ОБЪЯВИТЬ @i BIGINT
НАБОР @i = 2147483648
ПЕЧАТЬ @i

РЕЗУЛЬТАТ:
2147483648

Попытаться сохранить Отрицательное значение 
ОБЪЯВИТЬ @i INT
УСТАНОВИТЬ @i = -150
ПЕЧАТЬ @i

РЕЗУЛЬТАТ:
-150

ОБЪЯВИТЬ @i BIGINT
УСТАНОВИТЬ @i = -150
ПЕЧАТЬ @i

РЕЗУЛЬТАТ:
-150

[ТАКЖЕ ПРОЧИТАЙТЕ] SMALLINT Vs INT

Выбор правильного типа данных при создании таблицы очень важен.Неправильный выбор типа данных приведет к проблемам с производительностью и хранением со временем по мере роста данных. Поскольку неправильный выбор типа данных приводит к тому, что требуется больше места для хранения, и нет. записей, хранящихся на каждой странице данных, будет меньше. Кроме того, если индекс создается для таких столбцов, он не только занимает дополнительное место для хранения значения в строке на странице данных, но также требует дополнительного места в индексе. Меньше нет. записей, хранящихся на странице данных, то для обслуживания запросов сервер Sql не должен загружать больше.страниц данных в память. Поэтому очень важно выбрать правильный тип данных при создании таблицы. Надеюсь, что указанные выше различия помогут вам выбрать правильный тип данных при создании таблицы.

ТАКЖЕ ПРОЧИТАЙТЕ

Работа с типом BigInt в узле и SQL Server

Ваши приложения могут взаимодействовать с SQL Server несколькими способами и с разных платформ. Когда будет выпущена общедоступная предварительная версия SQL Server, работающего в Linux, кажется, что возможности будут еще больше.Microsoft гарантирует, что SQL Server будет работать практически на любой текущей платформе. Это уже не тот старый SQL Server, с которым вы уже знакомы.

Меняется не только выбор серверной платформы, но и способ доступа к ней. После этого объявления Microsoft SQL Server официально поддерживает Node. Это заставило меня задуматься: «Какие предостережения?» Исходя из культуры обычного .NET-магазина с серверной частью SQL Server, я решил заняться исследованием. В конце концов, JavaScript распространен повсеместно; он работает на каждой платформе, и у Node есть работоспособная альтернатива SQL Server.

Что бы вы ни использовали для подключения к SQL Server, будь то SSMS, ODBC или JDBC, вы будете делать это через протокол потока табличных данных (TDS). Первоначально он был разработан Sybase в 1984 году как уровень TCP / IP для связи с реляционными базами данных. Команда Microsoft решила продолжать использовать этот же протокол для взаимодействия с SQL Server. Существует реализация этого протокола в JavaScript, написанная как пакет Node, называемый Tedious, который позволяет вам получить доступ к SQL Server напрямую, не используя ODBC под капотом, как это делает Azure / node-sqlserver.Tedious поддерживает транзакции, параметры с табличным значением и массовую загрузку, поэтому готов к работе. Утомительная реализация JavaScript для среды Node, она не использует ODBC или JDBC.

Tedious поддерживает типы данных SQL Server, включая BigInt. Большинство из вас знают о последствиях типов данных при работе с таблицами SQL Server. Но как насчет Node? Среда Node запускает JavaScript, а собственные типы данных в JavaScript неизбежно отличаются. Это будет иметь последствия, если вы не знаете, как справиться с этой трудностью.63 (9 223 372 036 854 775 807). Два в степени шестьдесят три — это примерно девять квинтиллион , очень большое число. Представьте себе число больше, чем количество песчинок на Земле, оно такое большое.

Типы

BigInt в SQL Server полезны для первичного ключа в очень больших таблицах. По собственному опыту я использовал их в качестве первичного ключа для таблицы аудита аутентификации. BigInt использовался для идентификатора аудита, который использовался для данных сеанса в случае сбоя аутентификации.

SQL Server любит узкие и предсказуемые индексы. Последовательный целочисленный тип в качестве первичного ключа подходит для таблиц, в которые вы вставляете только новые строки, но не удаляете их, потому что это снижает фрагментацию индекса.

Создание таблицы SQL с помощью BigInt

Нам нужно проиллюстрировать проблемы передачи BigInt между JavaScript и SQL Server, поэтому пора заняться SQL Server. В этой статье мы будем использовать таблицу BigIntInNodeTest в базе данных FunWithBigIntInNode.Код всего, что мы вам покажем, доступен по ссылке в основании статьи.

Сначала создайте этот образец базы данных и таблицу:

СОЗДАТЬ БАЗУ ДАННЫХ FunWithBigIntInNode;

GO

ИСПОЛЬЗОВАТЬ FunWithBigIntInNode;

GO

СОЗДАТЬ ТАБЛИЦУ dbo.BigIntInNodeTest (

Id BIGINT NOT NULL,

IsAtMax BIT NOT NULL,

CONSTRAINT PK_BigIntInNodeTest_Id PRIMARY KEY (Id));

GO

ВСТАВИТЬ В dbo.BigIntInNodeTest (Id, IsAtMax)

ЗНАЧЕНИЯ (1, 0), (9223372036854775807, 1);

ГО

В этой таблице есть первичный ключ Id типа BigInt. Тип IsAtMax Bit сообщает мне, достиг ли BigInt предела. Я вставил два значения в тестовую таблицу, одно на 1 и одно на пределе.

T-SQL выше говорит вам, откуда взялась эта таблица, так что вы не заблудитесь.

Хранимая процедура

В моих Node-приложениях я предпочитаю отделять Node-код от T-SQL, чтобы получить простой и средний уровень доступа к данным.Утомительно может выполнять параметризованные хранимые процедуры на SQL Server.

Я создам две хранимые процедуры с двумя отдельными задачами. Один читает данные из таблицы, а другой записывает в нее данные.

СОЗДАТЬ ПРОЦЕДУРУ dbo.GetBigIntById (

@Id BIGINT

)

AS

ИД ВЫБРАТЬ, IsAtMax ОТ dbo.BigIntInNodeTest ГДЕ Id = @Id;

GO

СОЗДАТЬ ПРОЦЕДУРУ dbo.InsertBigInt (

@Id BIGINT,

@IsAtMax BIT

)

AS

INSERT INTO dbo.BigIntInNodeTest (Id, IsAtMax)

VALUES (@Id, @IsAtMax);

ГО

Это поможет мне поддерживать уровень доступа к данным Node в хорошем и чистом виде.

Чтение и запись данных

Теперь, когда таблица размещена в SQL Server, мы можем создать сценарий уровня доступа к данным в Node. Помните, я вставил две строки в dbo.BigIntInNodeTest, один со значением 1 и один с ограничением BigInt. Я буду использовать эти значения для запроса данных с помощью хранимой процедуры.

Для запроса значения 1 с помощью Node:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

var Connection = require («утомительно»).Связь;

var Request = require (‘утомительно’). Request;

var TYPES = require (‘утомительно’). TYPES;

var config = require (‘./ sqlConfig’);

var connection = новое соединение (config);

var requestBigInt = new Request (‘dbo.GetBigIntById’, function onRequest (err, rowCount) {

if (err) {

console.error (err);

}

if (rowCount === 0 ) {

console.log (‘Строки не найдены.’);

connection.close ();

}

});

requestBigInt.addParameter (‘Id’, TYPES.BigInt, 1);

requestBigInt.on (‘строка’, функция onRow (столбцы) {

console.log (столбцы);

connection.close ();

});

connection.on (‘соединение’, функция onConnect () {

connection.callProcedure (requestBigInt);

});

Это дает вам рабочее соединение с SQL Server.API управляется событиями с асинхронным поведением. Обратный вызов onConnect, например, срабатывает после установления начального соединения. Затем этот обратный вызов вызывает процедуру, использующую объект запроса. Tedious следует тем же соглашениям, что и другие API-интерфейсы Node, которые входят в стандартную библиотеку ядра. Ключ в том, чтобы знать, что асинхронное поведение использует скромные обратные вызовы в Node.

Файл sqlConfig — это файл конфигурации JSON, содержащий информацию о подключении:

{

«имя пользователя»: «имя пользователя»,

«пароль»: «пароль»,

«сервер»: «сервер»,

«параметры»: {

«база данных»: «FunWithBigIntInNode»,

«encrypt»: true

}

}

Когда вы запускаете этот запрос в Node, он дает вам правильный набор данных в столбцах.В столбце Id вы получите «1», что и было ожидаемым. Это означает, что мы можем запрашивать BigInt, используя простые старые номера ванильного JavaScript. Пока все идет хорошо.

Затем из любопытства мы установили ограничение BigInt в параметре, например:

requestBigInt.addParameter (‘Id’, TYPES.BigInt, 9223372036854775807);

Мы ожидаем, что одна строка вернется, вторую мы, конечно же, вставили.О боже, теперь там написано: «Строки не найдены». Что это могло значить? У Tedious правильный тип — TYPES.BigInt. Предел BigInt в JavaScript — это простое число. Это кажется странным, неустойчивым поведением. Это моя ошибка в том, как это запрограммировано?

Попробовав прочитать строку, в которой используется BigInt, с переменным успехом, как насчет вставки значений в таблицу?

Можно было сделать:

var Connection = require («утомительно»).Связь;

var Request = require (‘утомительно’). Request;

var TYPES = require (‘утомительно’). TYPES;

var config = require (‘./ sqlConfig’);

var connection = новое соединение (config);

var commandBigInt = new Request (‘dbo.InsertBigInt’, function onRequest (err) {

if (err) {

console.error (err);

}

connection.close ();

} );

commandBigInt.addParameter (‘Id’, TYPES.BigInt, ‘9223372036854775806’);

commandBigInt.addParameter (‘IsAtMax’, TYPES.Bit, ложь);

connection.on (‘подключиться’, функция onConnect () {

connection.callProcedure (commandBigInt);

});

На этот раз попробуйте сделать параметр BigInt строкой JavaScript. Утомительно говорит, что BigInts все равно возвращаются как струны. Не задерживайте дыхание, пока не добьетесь успеха, потому что я не верю в это.

Если вы посмотрите, что происходит в SQL Server, вы увидите следующее:

Что ж, -9223372036854775808 — это не то, что ожидалось.Почему этот результат не попал в цель с таким странным ответом? У утомительного есть то, что ему нужно, тип данных BigInt. С точки зрения Node, он отправляет строковый тип JavaScript в качестве параметра для записи данных. Что еще хуже, запрос пытается использовать номер JavaScript, который также терпит неудачу. До сих пор нам не удалось использовать тип данных BigInt на пределе для обеих операций чтения и записи. Почему Tedious не нравится это? С какими ограничениями я сталкиваюсь? Пришло время выяснить, в чем проблема.

В чем проблема?

На первый взгляд кажется, что я достиг предела с числами JavaScript, которые ниже предела BigInt. Отрицательные девять квинтиллионов — это отрицательный предел BigInt. Номер JavaScript должен превышать собственный предел типа данных Number. Если это правда, это означает, что Tedious переполняется до отрицательного лимита BigInt. Моя первая реакция — сосредоточиться на типе данных JavaScript Number и проверить его поведение.

Чтобы проверить эту теорию с помощью быстрого модульного теста:

var assert = require (‘assert’);

номер var = 9223372036854775807;

assert (номер === 9223372036854776000);

Похоже, непостоянное причудливое поведение — это способ обработки чисел в JavaScript.18. Поскольку последние три целых числа 5807 достигли жесткого предела, оно было округлено до шести тысяч.

Пора копнуть глубже.

Тип числа JavaScript

Тип данных JavaScript Number — это 64-битное значение с плавающей запятой IEEE 754. Это объясняет поведение, которое вы наблюдали при округлении лимита BigInt до ближайшей тысячи. Если вы увлекаетесь математикой, см. Спецификацию ECMAScript по типу Number. Сама спецификация содержит более подробные сведения, чем это необходимо для понимания этой проблемы.53, что равно

99254740992. Теперь это число, которое я могу проверить с помощью кода!

Чтобы проверить это, измените параметр BigInt из приведенного выше сценария вставки на максимальное целое число, которое JavaScript может точно представить:

commandBigInt.addParameter (‘Id’, TYPES.BigInt,

99254740992);

Чтобы убедиться, что это работает, теперь мы можем протестировать в SQL Server:

Успех.Прохождение теста приближает меня на один шаг к рабочему решению, в котором я уверен.

Оглядываясь назад, вы имеете дело с двумя ограничениями. Одно ограничение для типа данных SQL Server BigInt и одно для типа данных JavaScript Number. Среда Node будет поддерживать целые числа BigInt вплоть до ограничения числа JavaScript. Предел JavaScript составляет около девяти квадриллионов, что ниже, чем у BigInt. Но могу ли я сделать лучше? Есть ли способ в полной мере использовать тип данных BigInt? Да, представив их в виде строк.

Использовать необработанные строки

Учитывая, что Tedious возвращает BigInt как строковый тип JavaScript, было бы упущением не поменять тип Tedious BigInt на строку. В Tedious типы данных параметров сразу соответствуют типам данных SQL Server. Но, судя по наблюдениям, это JavaScript. Тип Tedious TYPES.BigInt сталкивается с теми же ограничениями, что и тип JavaScript Number. Тип BigInt в Tedious имеет мало общего с типом BigInt в SQL Server.

В Tedious есть много типов данных, которые соответствуют SQL Server.Каждый из них представлен статической константой, используемой в качестве перечисления, например TYPES.Bit. Просматривая список поддерживаемых типов данных, позвольте мне выбрать TYPES.VarChar. Это наиболее близкое представление целого числа BigInt, которое я могу придумать. Это имеет смысл, потому что VarChar будет отображаться на строковый тип данных JavaScript.

Чтобы проверить эту теорию, поменяйте местами тип данных Tedious в параметре:

commandBigInt.addParameter (‘Id’, TYPES.VarChar, ‘9223372036854775806’);

Если вы запустите SQL Profiler во время выполнения скрипта, вы увидите следующее:

exec dbo.InsertBigInt @ Id = ‘9223372036854775806’, @ IsAtMax = 0

SQL Server не заботится о том, чтобы параметр BigInt был заключен в апостроф. Ожидается параметр типа BigInt.Здесь возникает вопрос: выполняет ли он какое-либо приведение типов?

Выполнение именно этой хранимой процедуры с этими параметрами показывает следующий план выполнения:

Уф, никаких доказательств какого-либо странного приведения типа данных, и он использует первичный ключ для вставки, хорошо.

Похоже, что все работает как струна, это хороший прогресс. Если все, что вы когда-либо делаете, — это константы данных BigInt, этого достаточно.

У этого подхода есть ограничения.Тип строки JavaScript не является целым числом. Вы не можете делать с ним никаких математических расчетов. Непрактично увеличивать число, представленное строкой, на единицу, например, особенно если оно больше 9223372036854775806.

Итак, какие у меня варианты?

Использование библиотеки больших целых чисел NPM

Если вы посмотрите на пакет Tedious npm, вы заметите интересную зависимость. Пакет Tedious поставляется с пакетом BigNumber npm. Обратите внимание, что зависимости иногда имеют еще больше зависимостей.Иногда эти внутренние зависимости полезны для вас. Часто лучший способ проверить функциональность — это посмотреть, что у вас уже есть, прежде чем добавлять что-то новое. Таким образом вы получите решение с минимальным количеством зависимостей.

Пакет BigNumber позиционирует себя как легкую библиотеку JavaScript для Node, созданную с учетом производительности. Это сработает для моих требований BigInt.

В Node обычно можно увидеть эти типы зависимостей. Сам JavaScript — легкий язык с небольшим набором функций.Принцип дизайна, лежащий в основе Node, состоит в том, чтобы опираться на эту идею и сохранять ее простой. Например, базовые библиотеки Node — это низкоуровневые API. Идея состоит в том, чтобы полагаться на пользовательские пакеты для удовлетворения остальных ваших потребностей. Это сознательное решение основной команды проекта Node.

Например, я хочу взять число BigInt и вычесть его на единицу:

var bigNumber = require (‘большое число’).n;

var number = bigNumber (‘9223372036854775806’). Минус (1);

commandBigInt.addParameter (‘Id’, TYPES.VarChar, number.toString ());

Готово. Обратите внимание, что число превращается в строку при использовании параметра типа VarChar.

Это удовлетворит все ваши потребности BigInt, и все это с облегченной зависимостью. Имейте в виду, что эта зависимость не добавляет остроты моему поясу. Эта зависимость BigNumber поставляется с Tedious, и это здорово.

Взгляд вперед

Node — это легкий альтернативный способ взаимодействия с SQL Server. SQL Server может многое предложить, поскольку многие профессионалы знакомы с его механизмом запросов. Представьте, что вы попадаете в кадровый резерв с многолетним опытом работы с SQL Server. Оказывается, то же самое относится и к JavaScript. JavaScript существует более 25 лет, и очень многие ИТ-специалисты имеют в этом опыт. JavaScript и SQL Server — потрясающая комбинация.

Для этой простоты существует компромиссный компромисс.Система типов SQL Server отличается от JavaScript. Вы можете возразить, что система типов JavaScript — это лишь небольшое подмножество. Вы обнаружите, что некоторые типы имеют проблемы при переводе между двумя системами, а некоторые — нет. Например, тип BigInt — яркий тому пример. Главное — сохранять бдительность и осознавать, что вы работаете с JavaScript. Изучение системы типов JavaScript позволит вам преодолеть множество препятствий.

Максимальное предельное значение

для целочисленного типа данных в SQL Server 2012

В этой статье я описал, как вычислить максимальный диапазон различных целочисленных типов данных в SQL Server.TINYINT, SMALLINT, INT и BIGINT — все это числовые типы данных. Разница между этими типами данных заключается в минимальном и максимальном значениях. Итак, давайте посмотрим на практический пример того, как вычислить максимальный диапазон целочисленного типа данных в SQL Server. Пример разработан в SQL Server 2012 с использованием SQL Server Management Studio.

Вычисление максимального диапазона различных целочисленных типов данных.

Тип данных Bigint

Тип данных Bigint представляет собой целое число.(n-1) здесь N = 64

  1. Выберите Power (cast (2 as varchar), (64) -1) как ‘Bigint max range’ из sys.types, где name = ‘BIGInt’

Диапазон типа данных Bigint: от -9 223 372 036 854 775 808 до 9 223 372 036 854 775 807 . (n-1) — это формула для нахождения максимума типа данных INT.(n-1) здесь N = 64

  1. Выберите Power (cast (2 as varchar), (16) -1) как ‘Smallint max range’ из sys.types, где name = ‘SMALLInt’

Диапазон типа данных Smallint составляет от -32768 до 32767 .

Тип данных Tinyint

Tinyint представляет собой целое число, которое может храниться в 1 байте.

Диапазон типа данных T inyint составляет от 0 до 255 .

BIGINT v INT. Есть ли что-то важное?

Ответ — да.

В этом случае у нас есть два числовых типа данных MySQL, оба Integer. Фактически MySQL имеет 9 различных числовых типов данных для чисел с целой, фиксированной точностью и с плавающей запятой, однако мы сосредоточимся только на двух, BIGINT и INT. Это соображение по дизайну является частью моей недавней презентации «Топ-20 советов по дизайну для архитекторов данных».

В чем разница?
Сначала мы обратимся к Справочному руководству по MySQL, в 10.1.1. Обзор числовых типов мы видим следующее.


INT [(M)] [НЕ ПОДПИСАНО] [ZEROFILL]

Целое число нормального размера. Диапазон со знаком: от -2147483648 до 2147483647. Диапазон без знака: от 0 до 4294967295.

BIGINT [(M)] [НЕ ПОДПИСАНО] [ZEROFILL]

Большое целое число. Диапазон со знаком: от -9223372036854775808 до 9223372036854775807. Диапазон без знака: от 0 до 18446744073709551615.

Хорошо, ну, INT может хранить значение до 2,1 миллиарда, а BIGINT может хранить значение до некоторого большего числа до 20 цифр.Этот поиск MySQL не очень помог с деталями, нам нужно копнуть глубже, чтобы найти 10.2. Числовые типы, в которых мы обнаруживаем, что INT — это 4-байтовое целое число, а BIGINT — это 8-байтовое целое число.

Так в чем же дело?

На самом деле довольно много. Использование INT вместо BIGINT может значительно сократить дисковое пространство. Одно только это изменение может сэкономить вам 10% -20% (в зависимости от вашей конкретной ситуации). Что еще более важно, при использовании в качестве первичного ключа, а также для внешних ключей и индексов уменьшение размера индекса может составить 50%, и это повысит производительность при использовании этих индексов.

Мой подход таков. Давайте для начала сосредоточимся на первичных и внешних ключах. Собираетесь ли вы хранить в своей таблице более 2,1 миллиарда строк? Ответ должен быть отрицательным? Если вы скажете «да», то у вас действительно грандиозные планы, но вы также не учитываете последствия обработки больших наборов данных (тема для дальнейшего обсуждения).

Из этого правила есть исключения: если вы выполняете огромное количество операций вставки и удаления, то, хотя у вас может не быть 2,1 миллиарда строк, вы, возможно, сделали 2.1 миллиард вставок. Опять же, в этом случае следует рассмотреть более эффективные методы проектирования.

Тест

Как и все остальное, нам нужны доказательства, чтобы обосновать претензию. Используя образец базы данных Sakila.

Начнем с простой таблицы пересечений, в которой много столбцов, состоящих только из чисел. Это покажет лучшую ситуацию.

Мы создадим две таблицы, одну со всеми столбцами BIGINT, а другую со всеми столбцами INT, а затем сравним размер. Эти таблицы небольшие, но они показывают долю экономии дискового пространства.

СОЗДАТЬ ТАБЛИЦУ inventory_bigint КАК инвентарь;
ИЗМЕНИТЬ ТАБЛИЦУ inventory_bigint
  ИЗМЕНИТЬ inventory_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  ИЗМЕНИТЬ film_id BIGINT UNSIGNED NOT NULL,
  ИЗМЕНИТЬ store_id BIGINT UNSIGNED NOT NULL;
INSERT INTO inventory_bigint SELECT * from inventory;
СОЗДАТЬ ТАБЛИЦУ inventory_int КАК инвентарь;
ИЗМЕНИТЬ ТАБЛИЦУ inventory_int
  ИЗМЕНИТЬ inventory_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
  ИЗМЕНИТЬ film_id INT UNSIGNED NOT NULL,
  ИЗМЕНИТЬ store_id INT UNSIGNED NOT NULL;
INSERT INTO inventory_int SELECT * from inventory;

 
выберите table_name, engine, row_format, table_rows, avg_row_length,
        (data_length + index_length) / 1024/1024 как total_mb,
         (data_length) / 1024/1024 как data_mb,
         (index_length) / 1024/1024 как index_mb
из information_schema.столы
где table_schema = 'sakila'
и table_name LIKE 'inventory%'
заказать по 6 убытков;
+ ------------------ + -------- + ------------ + -------- ---- + ---------------- + ------------- + ------------- + ------------- +
| table_name | двигатель | row_format | table_rows | avg_row_length | total_mb | data_mb | index_mb |
+ ------------------ + -------- + ------------ + -------- ---- + ---------------- + ------------- + ------------- + ------------- +
| inventory_bigint | InnoDB | Компактный | 293655 | 51 | 43.60937500 | 14.51562500 | 29.09375000 |
| inventory_int | InnoDB | Компактный | 293715 | 37 | 29.54687500 | 10.51562500 | 19.03125000 |
| инвентарь | InnoDB | Компактный | 293707 | 33 | 22.54687500 | 9.51562500 | 13.03125000 |
+ ------------------ + -------- + ------------ + -------- ---- + ---------------- + ------------- + ------------- + ------------- +
3 ряда в наборе (0,15 сек)

В этом примере часть данных уменьшилась с 14 МБ до 10 МБ или 28%, а часть индекса с 29 МБ до 19 МБ или 34%.

СОЗДАТЬ ТАБЛИЦУ customer_bigint LIKE customer;
ИЗМЕНИТЬ ТАБЛИЦУ customer_bigint
     ИЗМЕНИТЬ customer_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
     ИЗМЕНИТЬ store_id BIGINT UNSIGNED NOT NULL,
     ИЗМЕНИТЬ address_id BIGINT UNSIGNED NOT NULL,
     ИЗМЕНИТЬ активный BIGINT UNSIGNED NOT NULL;

СОЗДАТЬ ТАБЛИЦУ customer_int LIKE customer;
ИЗМЕНИТЬ ТАБЛИЦУ customer_int
     ИЗМЕНИТЬ customer_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
     ИЗМЕНИТЬ store_id INT UNSIGNED NOT NULL,
     ИЗМЕНИТЬ address_id INT UNSIGNED NOT NULL,
     ИЗМЕНИТЬ активный INT UNSIGNED NOT NULL;

выберите table_name, engine, row_format, table_rows, avg_row_length,
        (data_length + index_length) / 1024/1024 как total_mb,
         (data_length) / 1024/1024 как data_mb,
         (index_length) / 1024/1024 как index_mb
из information_schema.столы
где table_schema = 'sakila'
и table_name LIKE 'customer%'
заказать по 6 убытков;

+ ----------------- + -------- + ------------ + --------- --- + ---------------- + ------------- + ------------- + - ------------ +
| table_name | двигатель | row_format | table_rows | avg_row_length | total_mb | data_mb | index_mb |
+ ----------------- + -------- + ------------ + --------- --- + ---------------- + ------------- + ------------- + - ------------ +
| customer_bigint | InnoDB | Компактный | 154148 | 139 | 37.09375000 | 20.54687500 | 16.54687500 |
| customer_int | InnoDB | Компактный | 151254 | 121 | 30.06250000 | 17.51562500 | 12.54687500 |
| клиент | InnoDB | Компактный | 37684 | 125 | 7.81250000 | 4.51562500 | 3.29687500 |
| список_клиентов | NULL | NULL | NULL | NULL | NULL | NULL | NULL |
+ ----------------- + -------- + ------------ + --------- --- + ---------------- + ------------- + ------------- + - ------------ +
4 ряда в наборе (0.22 сек)

В этом примере часть данных уменьшилась с 20 МБ до 17 МБ или 15%, а часть индекса с 16 МБ до 12 МБ или 25%.

ПРИМЕЧАНИЕ. Набор данных для этого примера был увеличен.

Заключение

Даже с этими простыми таблицами и небольшими наборами данных ясно, что INT — это экономия дискового пространства по сравнению с BIGINT. На многих клиентах я наблюдал огромную экономию в базах данных с несколькими ТБ просто за счет небольшого количества оптимизаций схемы. Если бы одна только эта экономия для более оптимизированного дизайна базы данных составляла всего 10%, это легкие 10%, которые отражают прямое улучшение производительности.

Об авторе

Рональд Брэдфорд предоставляет консультационные и консультационные услуги по архитектуре данных, производительности и масштабируемости для решений MySQL. Профессионал ИТ-индустрии в течение двух десятилетий с обширным опытом работы с базами данных в MySQL, Oracle и Ingres. Его опыт охватывает архитектуру данных, разработку программного обеспечения, миграцию, анализ производительности и внедрение производственных систем. Его знания, полученные в результате 10-летнего консультирования во многих отраслях, технологиях и странах, предоставили уникальное понимание того, как найти решения проблем.За дополнительной информацией обращайтесь к Рональду.

Ссылки

10.5.4 Сопоставление типов сервера Microsoft SQL

10.5.4 Сопоставление типов Microsoft SQL Server

В следующей таблице показано соответствие между Microsoft SQL.
Типы данных сервера (источника) и типы данных MySQL.

Таблица 10.2 Отображение типов

В MySQL установлен флаг

Тип источника MySQL Тип Комментарий
ИНТ ИНТ
TINYINT TINYINT UNSIGNED.
МАЛЕНЬКИЙ МАЛЕНЬКИЙ
BIGINT BIGINT
БИТ ТИНИИНТ (1)
ПОПЛАВОК ПОПЛАВКА Значение точности используется для размера хранилища в обоих.
НАСТОЯЩИЙ ПОПЛАВКА
НОМЕР ДЕСЯТИЧНЫЙ
ДЕСЯТИЧНЫЙ ДЕСЯТИЧНЫЙ
ДЕНЬГИ ДЕСЯТИЧНЫЙ
МАЛЕНЬКАЯ ДЕНЬГА ДЕСЯТИЧНЫЙ
СИМВОЛ СИМВОЛ / ДЛИННЫЙ ТЕКСТ В зависимости от длины.MySQL Server 5.6 и выше может иметь CHAR
столбцы длиной до 255 символов. Что-нибудь
больший размер переносится как LONGTEXT.
NCHAR СИМВОЛ / ДЛИННЫЙ ТЕКСТ В зависимости от длины. MySQL Server 5.6 и выше может иметь VARCHAR
столбцы длиной до 65535 символов. Что-нибудь
больше переносится в один из типов больших двоичных объектов ТЕКСТ. В
MySQL, набор символов строк зависит от столбца
набор символов вместо типа данных.
VARCHAR VARCHAR / MEDIUMTEXT / LONGTEXT В зависимости от длины. MySQL Server 5.6 и выше может иметь VARCHAR
столбцы длиной до 65535 символов. Что-нибудь
больше переносится в один из типов больших двоичных объектов ТЕКСТ.
NVARCHAR VARCHAR / MEDIUMTEXT / LONGTEXT В зависимости от длины. MySQL Server 5.6 и выше может иметь VARCHAR
столбцы длиной до 65535 символов.Что-нибудь
больше переносится в один из типов больших двоичных объектов ТЕКСТ. В
MySQL, набор символов строк зависит от столбца
набор символов вместо типа данных.
ДАТА ДАТА
ДАТА ВРЕМЕНИ ДАТА
DATETIME2 ДАТА Диапазон дат в MySQL: 1000-01-01 00:00:00.000000 — 9999-12-31
23: 59: 59.999999 ‘. Примечание: значения долей секунды приводятся только
хранится с MySQL Server 5.6.4 и выше.
МАЛЕНЬКАЯ ВРЕМЯ ДАТА
DATETIMEOFFSET ДАТА
ВРЕМЯ ВРЕМЯ
TIMESTAMP ВРЕМЯ ВРЕМЕНИ
ROWVERSION ВРЕМЯ ВРЕМЕНИ
ДВОИЧНЫЙ ДВОИЧНЫЙ / СРЕДНИЙ / LONGBLOB В зависимости от длины.
VARBINARY VARBINARY / MEDIUMBLOB / LONGBLOB В зависимости от длины.
ТЕКСТ VARCHAR / MEDIUMTEXT / LONGTEXT В зависимости от длины.
NTEXT VARCHAR / MEDIUMTEXT / LONGTEXT В зависимости от длины.
ИЗОБРАЖЕНИЕ TINYBLOB / MEDIUMBLOB / LONGBLOB В зависимости от длины.
SQL_VARIANT не перенесено Этот тип данных не поддерживается.
ТАБЛИЦА не перенесено Этот тип данных не поддерживается.
ИЕРАРХИД не перенесено Этот тип данных не поддерживается.
УНИКАЛЬНЫЙ ИДЕНТИФИКАТОР VARCHAR (64) Уникальный флаг, установленный в MySQL.Нет специальной поддержки для вставки
значения уникального идентификатора.
ИМЯ СИСТЕМЫ VARCHAR (160)
XML ТЕКСТ

SQL SERVER — ALTER Column from INT to BIGINT — Error and Solutions

Некоторое время назад я написал блог о проблеме перехода значения столбца идентификатора, вы можете прочитать его отсюда. SQL SERVER — Перейти в столбец идентификатора после перезапуска! В этом сообщении блога мы узнаем, как устранить ошибку, когда мы изменяем столбец с int на bigint.

Один из моих клиентов обратился ко мне за консультацией, и они исчерпали целочисленный диапазон. В связи с этим они хотели узнать возможные способы изменить существующий столбец на тип данных bigint.

РЕШЕНИЕ / ВОЗМОЖНОЕ РЕШЕНИЕ

Если бы в этой таблице не было первичного ключа, мы могли бы использовать синтаксис ALTER TABLE… ALTER COLUMN для изменения типа данных, как показано ниже.

 ALTER TABLE OneTable ALTER COLUMN ID bigint

В случае зависимости первичного ключа или FK произойдет сбой с ошибкой ниже:

Msg 5074, уровень 16, состояние 1, строка 1
Объект PK_OneTable зависит от столбца ‘Я БЫ’.
Msg 4922, уровень 16, состояние 9, строка 1
ALTER TABLE ALTER COLUMN ID не удалось, поскольку один или несколько объектов обращаются к этому столбцу.

Более подробную информацию о синтаксисе и ограничениях можно найти на https://docs.microsoft.com/en-us/sql/t-sql/statements/alter-table-transact-sql.

Вот решения, которыми я с ними поделился.

Решение 1

  1. Создайте новый столбец bigint в таблице
  2. Обновите этот новый столбец значениями из столбца int
  3. Удалите столбец int
  4. Переименуйте столбец bigint

Вот пример:

 СОЗДАТЬ ТАБЛИЦУ [dbo].[OneTable] (
[ID] [int] НЕ NULL ПЕРВИЧНЫЙ КЛЮЧ,
[FName] [nchar] (10) NULL,
[Lname] [nchar] (10) NULL,
)
ИДТИ

ALTER TABLE OneTable ДОБАВИТЬ NewColumn BIGINT NOT NULL
ИДТИ
ОБНОВЛЕНИЕ OneTable SET NewColumn = ID
ИДТИ
ALTER TABLE [dbo]. [OneTable] DROP CONSTRAINT [PK_OneTable] WITH (ONLINE = ON)
ИДТИ
ИЗМЕНИТЬ ТАБЛИЦУ OneTable DROP COLUMN ID
ИДТИ
ИСПОЛЬЗУЙТЕ [Foo]
ИДТИ
ALTER TABLE [dbo]. [OneTable] ADD CONSTRAINT [PK_OneTable] PRIMARY KEY CLUSTERED
(
[NewColumn] ASC
)
ИДТИ

EXEC sp_rename 'OneTable.NewColumn', 'ID', 'COLUMN'

У этого подхода есть проблема, заключающаяся в том, что порядок столбцов может измениться и приложение может выйти из строя, если это зависит от порядка столбцов.

No related posts.

Share :

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *