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

(* Данные типы данных будут удалены в будущих версиях 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
• бинарные
• другие

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

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

Время и дата

Символы

Символы Unicode

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

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

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

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

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

• 22.07.2017
• 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

ОБЪЯВИТЬ @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.Код всего, что мы вам покажем, доступен по ссылке в основании статьи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тип числа JavaScript

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

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

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

Чтобы убедиться, что это работает, теперь мы можем протестировать в 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 в параметре:

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

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

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

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

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

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

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

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

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

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

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

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

Готово. Обратите внимание, что число превращается в строку при использовании параметра типа 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

СОЗДАТЬ ТАБЛИЦУ 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 сек)
 

СОЗДАТЬ ТАБЛИЦУ 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 сек)

 

 ALTER TABLE OneTable ALTER COLUMN ID 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'