Разное

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

Содержание

Как преобразовать 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 varying varbinary
char varying varchar
character char
character char(1)
character(n) char(n)
character varying(n) varchar(n)
Dec decimal
Double precision float
float[(n)] for n = 1-7 real
float[(n)] for n = 8-15 float
integer int
national character(n) nchar(n)
national char(n) nchar(n)
national character varying(n) nvarchar(n)
national char varying(n) nvarchar(n)
national text ntext
timestamp rowversion

Синонимы типов данных можно использовать вместо соответствующих базовых типов данных в инструкциях языка определения данных (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 + e2 max(s1, s2) + max(p1-s1, p2-s2) + 1 max(s1, s2)
e1 — e2 max(s1, s2) + max(p1-s1, p2-s2) + 1 max(s1, s2)
e1 * e2 p1 + p2 + 1 s1 + s2
e1 / e2 p1 — s1 + s2 + max(6, s1 + p2 + 1) max(6, s1 + p2 + 1)
e1 { UNION | EXCEPT | INTERSECT } e2 max(s1, s2) + max(p1-s1, p2-s2) max(s1, s2)
e1 % e2 min(p1-s1, p2 -s2) + max( s1,s2 ) max(s1, s2)

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

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

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

SQL Server SSIS Variables SSIS Pipeline Buffer OLE DB ADO.NET Biml
bigint Int64 DT_I8 LARGE_INTEGER Int64 Int64
binary Object DT_BYTES Binary Binary
bit Boolean DT_BOOL VARIANT_BOOL Boolean Boolean
char String DT_STR VARCHAR StringFixedLength AnsiStringFixedLength
date Object DT_DBDATE DBDATE Date Date
datetime DateTime DT_DBTIMESTAMP DATE DateTime DateTime
datetime2 Object DT_DBTIMESTAMP2 DBTIME2 DateTime2 DateTime2
datetimeoffset Object DT_DBTIMESTAMPOFFSET DBTIMESTAMPOFFSET DateTimeOffset DateTimeOffset
decimal Decimal DT_NUMERIC NUMERIC Decimal Decimal
float Double DT_R8 FLOAT Double Double
geography DT_IMAGE Object Object
geometry DT_IMAGE Object Object
hierarchyid DT_BYTES Object Object
image (*) Object DT_IMAGE Binary Binary
int Int32 DT_I4 LONG Int32 Int32
money Object DT_CY, DT_NUMERIC CURRENCY Currency Currency
nchar String DT_WSTR NVARCHAR StringFixedLength StringFixedLength
ntext (*) String DT_NTEXT String String
numeric Decimal DT_NUMERIC NUMERIC Decimal Decimal
nvarchar String DT_WSTR NVARCHAR String String
nvarchar(max) Object DT_NTEXT String
real Single DT_R4 FLOAT, DOUBLE Single Single
rowversion Object DT_BYTES Binary Binary
smalldatetime DateTime DT_DBTIMESTAMP DATE DateTime DateTime
smallint Int16 DT_I2 SHORT Int16 Int16
smallmoney Object DT_CY, DT_NUMERIC CURRENCY Currency Currency
sql_variant Object DT_WSTR, DT_NTEXT Object Object
table Object
text (*) Object DT_TEXT AnsiString
time Object DT_DBTIME2 DBTIME2 Time Time
timestamp (*) Object DT_BYTES Binary Binary
tinyint Byte DT_UI1 BYTE Byte Byte
uniqueidentifier String, Object DT_GUID GUID Guid Guid
varbinary Object DT_BYTES Binary Binary
varbinary(max) Object DT_IMAGE Binary Binary
varchar String DT_STR VARCHAR String AnsiString
varchar(max) Object DT_TEXT AnsiString
xml Object DT_NTEXT Xml

(* Данные типы данных будут удалены в будущих версиях SQL Server. 38 -1 Exact Numerics smallmoney 4 -214 748.3648 to 214 748.3647 Exact Numerics money 8 -922 337 203 685 477.5808 to 922 337 203 685 477.5807 Approximate Numerics float 1-24
25-53 7
15 4
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+308 Date and Time date 3 0001-01-01 through 9999-12-31
January 1, 1 CE through December 31, 9999 CE Date and Time smalldatetime 4 1900-01-01 through 2079-06-06
January 1, 1900 through June 6, 2079
00:00:00 through 23:59:59 Date and Time time 8-11
12-13
14-16 3
4
5 00:00:00.0000000 through 23:59:59.9999999 Date and Time datetime2 1-2
3-4
5-7 6
7
8 0001-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 + 2 Other Data Types cursor Other Data Types sql_variant max 8016 Other Data Types hierarchyid max 892 Other Data Types rowversion 8 Other Data Types timestamp(*) Other Data Types uniqueidentifier 16 Other Data Types xml max 2Gb Other Data Types table Spatial Data Types geometry Spatial Data Types geography

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

General Type Type MySQL Oracle PostgreSQL SQLite
Exact Numerics bit TINYINT(1) NUMBER(3) BOOLEAN INTEGER
Exact Numerics tinyint TINYINT(signed) NUMBER(3) SMALLINT INTEGER
Exact Numerics smallint SMALLINT NUMBER(5) SMALLINT INTEGER
Exact Numerics int MEDIUMINT, INT NUMBER(10) INT INTEGER
Exact Numerics bigint BIGINT NUMBER(19) BIGINT INTEGER
Exact Numerics decimal DECIMAL NUMBER(p[,s]) DECIMAL(p,s) REAL
Exact Numerics smallmoney DOUBLE NUMBER(10,4) MONEY REAL
Exact Numerics money DOUBLE NUMBER(19,4) MONEY REAL
Approximate Numerics float FLOAT
DOUBLE; REAL
FLOAT(49) DOUBLE PRECISION REAL
Date and Time date DATE DATE TEXT
Date and Time smalldatetime TIMESTAMP DATE TIMESTAMP(0) TEXT
Date and Time time TIME TIME TEXT
Date and Time datetime2 DDATETIME TIMESTAMP TEXT
Date and Time datetime DATE TIMESTAMP(3) TEXT
Date and time datetimeoffset TIMESTAMP
with time zone
TEXT
Caracter Strings char CHAR CHAR CHAR TEXT
Caracter Strings varchar VARCHAR VARCHAR2 VARCHAR TEXT
Caracter Strings varchar(max) VARCHAR2 TEXT TEXT
Caracter Strings nchar NCHAR NCHAR TEXT
Caracter Strings nvarchar NCHAR VARCHAR TEXT
Caracter Strings nvarchar(max) VARCHAR
TINYTEXT
TEXT(M)
MEDIUMTEXT
LONGTEXT
NCHAR TEXT TEXT
Caracter Strings ntext(*) LONG TEXT TEXT
Caracter Strings text(*) LONG TEXT TEXT
Binary Strings image(*) LONGBLOB LONG RAW BYTEA BLOB
Binary Strings binary BINARY RAW BYTEA BLOB
Binary Strings varbinary RAW BYTEA BLOB
Binary Strings varbinary(max) VARBINARY(M)
TINYBLOB
BLOB
MEDIUMBLOB
LONGBLOB
RAW BYTEA BLOB
Other Data Types cursor TEXT
Other Data Types sql_variant BLOB TEXT
Other Data Types hierarchyid TEXT
Other Data Types rowversion BYTEA TEXT
Other Data Types timestamp(*) RAW BYTEA TEXT
Other Data Types uniqueidentifier CHAR CHAR(36) CHAR(16) TEXT
Other Data Types xml XML TEXT
Other Data Types table
Spatial Data Types geometry VARCHAR TEXT
Spatial Data Types geography VARCHAR TEXT

(* Данные типы данных будут удалены в будущих версиях 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,808 9,223,372,036,854,775,807
int -2,147,483,648 2,147,483,647
smallint -32,768 32,767
tinyint 0 255
bit 0 1
decimal -10^38 +1 10^38 -1
numeric -10^38 +1 10^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 + 308 1.79E + 308
real -3.40E + 38 3.40E + 38

Время и дата

Тип данных От До
datetime 1 Января, 1753 31 Декабря, 9999
smalldatetime 1 Января, 1900 6 Июня, 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' 

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

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

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

2021 © Все права защищены. Карта сайта