はじめに

データ型は、列、ローカル変数、式、パラメーターなどのオブジェクトが保持できるデータの種類を指定する属性です。 RDBMSの世界全体で、データ型は通常、文字列、数値、および日付のデータ型にグループ化されます。

T-SQLは、次の6つの日付と時刻のデータ型をサポートしています。

日時
Smalldatetime
日付
時間
Datetime2
Datetimeoffset

最初の2つのデータ型は、新しいデータ型のレガシーバージョンと見なされます。この記事では、日付データ型、特に datetimeに焦点を当てます。およびdatetime2 SQLServerで使用可能なデータ型。表1に、SQLServerで使用できるさまざまな日付と時刻のデータ型の詳細を示します。

[テーブルID=59 /]

タブ1の日付と時刻のデータ型

日時と日時2

Datatimeは、24時間形式で日付と時刻を組み合わせたデータ型です。日時データ型でサポートされている日付範囲は、タブ1に示されているとおりであり、精度は約3ミリ秒です。

Datetime2は、datetimeデータ型の拡張です。可能な値の範囲が広がり、100ナノ秒の精度があり、前モデルよりもはるかに優れています。 dattime2データ型のもう1つの重要な側面は、必要なストレージが、選択した精度に応じて6〜8バイトの範囲であることです。

秒コンポーネントに小数点以下3桁を許可することにより、1ミリ秒の精度を達成できます。したがって、各値は6バイトを消費します。
秒コンポーネントに小数点以下7桁を許可することで、100ナノ秒の精度を実現できます。したがって、各値は8バイトを消費します。

デモンストレーション

間違った日付値を挿入

リスト1に示す詳細を含むテーブルを作成して、 datetimeの操作方法を示すいくつかのデモンストレーションを実行します。およびdatetime2 データ型。

-- Listing 1 Create Table and insert Rows
-- Create Table with Data Types
use Practice2017
go
create table staffers (
fname varchar(50),
lname varchar(50),
JobTitle varchar(100),
DOB datetime,
PreciseDOB datetime2,
LastLoginTime time)
go

次に、リスト2に示すようにテーブルに1行を入力しようとしますが、図1に示すエラーが発生します。エラーメッセージのキーワードは「範囲外」の値です。私たちが挿入しようとしている彼女の価値は、2017年1月1日よりも低いということです。以上9999年12月31日 。この場合、問題は、「 YYYYMMDD hh：mm：ss.nnn」の推奨エントリ形式を使用していないことです。 ’（表1を参照）。値「06101979」を読み取る ‘、SQL Serverは0610を年（YYYYと一致）と見なします。 datetime2の範囲は0001年から広くなっているため、このエラーはdatetime2データ型ではスローされません。

-- Listing 2 Insert Rows with Wrong Entry Format
insert into staffers 
values
(
'Kenneth'
,'Igiri'
,'Database Administrator'
,'06101979'
,'06101979'
,'8:00 AM'
)

図1日時列に返されるエラー

正しい日付値を挿入

リスト3に示すように、日時列に正しい入力形式を入力して問題を修正しようとします。ステートメントを再度実行すると、図2に示すエラーが発生します。このエラーは、基本的に同じ失敗が原因です。エントリーフォーマットの仕様。ただし、問題は日付「 06101979」の他の部分にあります。 ‘エントリ形式‘ YYYYMMDD hh：mm：ss.nnnと一致します ’。この場合、SQLServerは19を想定しています月であり、 79 月の日です。上記のアサーションはどちらも当てはまらないため、この暗黙的な変換の試行は失敗します。

-- Listing 3 Insert Rows with One Correct Entry Format
insert into staffers 
values
(
'Kenneth'
,'Igiri'
,'Database Administrator'
,'19791006'
,'01061979'
,'8:00 AM'
)

図2Datetime2列に返されるエラー

リスト4では、最後のアサーションを示すことができます。値01101201 datetime2の範囲に収まり、行を挿入できます。この値は、図3に示すように、0110年12月1日に変換されます。

-- Listing 4: Insert Rows with Correct Date Format
insert into staffers 
values
(
'Kenneth'
,'Igiri'
,'Database Administrator'
,'19791006'
,'01101201'
,'8:00 AM')

-- Listing 5: Insert Rows with All Correct Entry Format
insert into staffers 
values
(
'Kenneth'
,'Igiri'
,'Database Administrator'
,'19791006'
,'19791006'
,'8:00 AM'
)

データの確認

図3データセットのクエリ

スタッフテーブルをクエリすると、datetime2の代替と比較した場合に、datetimeデータ型の精度が明確にわかります。もう少し不吉なもの、言語設定に移りましょう。リスト6を見てください。日付形式を使用してまったく同じレコードを挿入しています1979年6月10日 。この形式は言語に依存しないため、言語を British に設定すると、最初のステートメントで、次に us_english 2番目の例では、生の値は同じですが、実際には2つの異なる日付を挿入していることがわかります。これが、 datetime を処理するときに、常に推奨されるエントリ形式を使用することが非常に重要である理由です。およびdatetime2 。

-- Listing 6: Impact of Language Settings

set language british
insert into staffers 
values
(
'Kenneth'
,'Igiri'
,'Database Administrator'
,'06/10/1979'
,'06/10/1979'
,'8:00 AM'
)


set language us_english
insert into staffers 
values
(
'Kenneth'
,'Igiri'
,'Database Administrator'
,'06/10/1979'
,'06/10/1979'
,'8:00 AM'
)

図4スタッフへの問い合わせ

言語設定をBritish 、SQL Serverは、最初の2つの数字を日として解釈しますが、言語設定は us_english 、SQL Serverは、最初の2つの数値を月として解釈します。ここで最後に言及する必要があるのは、レコードを挿入するときに時間コンポーネントを指定しなかったため、SQLServerは指定された日付の深夜を意味すると自動的に想定することです。

結論

この記事では、datetimeおよびdatetime2データ型がどのように見えるか、それらの主な違い、およびこれらのデータ型を使用するときに正しい日付を入力していることを確認する方法について学習しました。その過程で、開発者がこれらのデータ型を操作するときに遭遇する可能性のある2つのエラーについても調べました。

参照

SQLデータ型
Ben-Gan、I.（2016）T-SQLの基礎。 pp74-78。 MicrosoftPress。

T-SQL日時データ型