このクエリをどこかで見ました -
SELECT *
FROM HR.Employees
WHERE country <> N'JAP';
その「N」はどういう意味ですか?これが SQL サーバーに対してのみ有効かどうかはわかりません。
このクエリをどこかで見ました -
SELECT *
FROM HR.Employees
WHERE country <> N'JAP';
その「N」はどういう意味ですか?これが SQL サーバーに対してのみ有効かどうかはわかりません。
N は「National Character」を表し、文字列の内容がUnicodeであることを意味します。
デフォルトの ASCII 文字セット以外の文字を含む可能性のある適切な名前やその他のエンティティに遭遇する可能性がある場合は常に、Unicode ( nchar
/ ) を使用する必要があります。nvarchar
このような文字列をN
プレフィックスで囲まないと、データが失われます。例えば:
SELECT N'ук ферт хер', 'ук ферт хер';
結果:
----------- -----------
ук ферт хер ?? ???? ???
また、列に対する句または他の句で必ずN
接頭辞を使用する必要があります。接頭辞を使用しない場合、暗黙的な変換により深刻なパフォーマンスの問題が発生する可能性があります。WHERE
n(var)char
N
本から取得した追加情報 - http://www.amazon.com/Training-Kit-Exam-70-461-Microsoft/dp/0735666059
異なる型のオペランドを含む式を記述する場合、SQL Server は型を揃えるために暗黙的な変換を適用する必要があります。状況によっては、暗黙的な変換によってパフォーマンスが低下することがあります。さまざまな型のリテラルの適切な形式を理解し、正しいものを使用していることを確認することが重要です。正しくないリテラル型を使用する典型的な例は、Unicode 文字列 (NVARCHAR および NCHAR 型) です。
Unicode 文字列リテラルの正しい形式は、リテラルの前に大文字の N を付け、リテラルを単一引用符で区切ることです。たとえば、N'literal' です。通常の文字列リテラルの場合、リテラルを単一引用符で区切るだけです。たとえば、「リテラル」。次の例のように、フィルター処理された列が Unicode 型の場合に通常の文字列リテラルを指定するのは、非常に典型的な悪い習慣です。
SELECT empid, firstname, lastname
FROM HR.Employees
WHERE lastname = 'Davis';
列とリテラルの型が異なるため、SQL Server は一方のオペランドの型をもう一方の型に暗黙的に変換します。この例では、幸いなことに、SQL Server はリテラルの型を列の型に変換するため、引き続きインデックス作成に効率的に依存できます。ただし、暗黙的な変換によってパフォーマンスが低下する場合があります。次のように、適切な形式を使用することをお勧めします。
SELECT empid, firstname, lastname
FROM HR.Employees
WHERE lastname = N'Davis';