এনভিআর্কার কলামের কোনও মান আসলে ইউনিকোড কিনা তা সনাক্ত করুন

14

আমি কিছু এসকিউএল সার্ভার ডাটাবেস উত্তরাধিকারসূত্রে পেয়েছি। এসকিউএল সার্ভার ২০১৪ স্ট্যান্ডার্ডে সোর্স ডাটাবেস থেকে (আমি "কিউ" কল করব) থেকে প্রায় ৮.7..7 মিলিয়ন সারি, এবং ৪১ টি কলাম প্রশস্ত সহ একটি টেবিল রয়েছে (এতে আমি "জি" বলব) এসকিউএল সার্ভার ২০০৮ আর 2 স্ট্যান্ডার্ডে একই টেবিলের নাম সহ একটি লক্ষ্য ডেটাবেস (আমি "পি" কল করব)।

যেমন [প্রশ্ন]। [জি] ---> [পি]। [জি]

সম্পাদনা: 3/20/2017: কিছু লোক জিজ্ঞাসা করেছে যে উত্স টেবিলটি কেবলমাত্র লক্ষ্য সারণির একমাত্র উত্স। হ্যাঁ, এটিই একমাত্র উত্স। ইটিএল যতদূর যায়, সেখানে প্রকৃত রূপান্তর ঘটেনি; এটি কার্যকরভাবে উত্স ডেটার 1: 1 অনুলিপি করার উদ্দেশ্যে is সুতরাং, এই লক্ষ্য সারণিতে অতিরিক্ত উত্স যুক্ত করার কোনও পরিকল্পনা নেই।

[প্রশ্ন] -এর কলামগুলির অর্ধেকেরও বেশি [[জি] হ'ল ভ্রচার (উত্স সারণী):

কলামগুলির মধ্যে 13 টি ভর্চার (80)
কলামগুলির 9 টি ভ্রচার (30)
কলামগুলির মধ্যে দুটি হ'ল ভর্চার (8)।

একইভাবে, [পি] তে একই কলামগুলি [[জি] একই প্রস্থের সাথে একই # কলামের সাথে এনভিচারার (লক্ষ্য টেবিল)। (অন্য কথায়, একই দৈর্ঘ্য, তবে এনভিআর্কার)।

কলামগুলির মধ্যে 13 টি এনভিচারার (80)
কলামগুলির 9 টি এনভিচারার (30)
কলামগুলির মধ্যে দুটি হ'ল এনভিচারার (8)।

এটি আমার নকশা নয়।

আমি ALTER [পি] করতে চাই [[জি] (টার্গেট) কলামগুলি ডেভিডের ধরণগুলি এনভিচারার থেকে ভ্রচারে। আমি নিরাপদে এটি করতে চাই (রূপান্তর থেকে ডেটা ক্ষতি ছাড়াই)।

কলামটিতে আসলে কোনও ইউনিকোড ডেটা রয়েছে কি না তা নিশ্চিত করতে লক্ষ্য টেবিলের প্রতিটি এনভিসার্কার কলামের ডেটা মানগুলিকে আমি কীভাবে দেখতে পারি?

এমন একটি কোয়েরি (ডিএমভি?) যা প্রতিটি এনভিচারার কলামের প্রতিটি মান (একটি লুপে?) পরীক্ষা করতে পারে এবং আমাকে জানাতে হবে যে মানগুলির কোনওটিই প্রকৃত কিনা ইউনিকোড আদর্শ সমাধান হতে পারে, তবে অন্যান্য পদ্ধতিগুলি স্বাগত।

sql-server datatypes unicode

— জন জি হোহেনগার্টেন
সূত্র

2

প্রথমে আপনার প্রক্রিয়াটি এবং কীভাবে ডেটা ব্যবহৃত হয় তা বিবেচনা করুন। এতে থাকা ডেটাটি [G]ইটিএলড হয়ে গেছে [P]। যদি [G]হয় varchar, এবং ETL প্রক্রিয়াটি কেবলমাত্র ডাটাতে আসে [P], তবে প্রক্রিয়াটি সত্যিকারের ইউনিকোড অক্ষর যুক্ত না করা পর্যন্ত কোনও কিছু হওয়া উচিত নয়। যদি অন্যান্য প্রক্রিয়াগুলিতে ডেটা যুক্ত করে বা সংশোধন করে তবে [P]আপনার আরও সতর্ক হওয়া দরকার - কেবলমাত্র বর্তমান সমস্ত ডেটা এর varcharঅর্থ এই নয় যে nvarcharআগামীকাল ডেটা যুক্ত করা যায়নি। একইভাবে, এটি সম্ভব যে যা কিছু ডেটা গ্রাহ্য করে তাদের ডেটা [P]প্রয়োজন nvarchar।

— আরডিফোজ

10

মনে করুন আপনার কলামের একটিতে কোনও ইউনিকোড ডেটা নেই। আপনার প্রতিটি সারির কলাম মান পড়তে হবে তা যাচাই করতে। আপনার কলামে একটি সূচি না থাকলে, একটি রো স্টোর টেবিল সহ আপনাকে টেবিল থেকে প্রতিটি ডেটা পৃষ্ঠা পড়তে হবে। এই বিষয়টি মনে রেখে আমি মনে করি যে সমস্ত কলামের চেকগুলি টেবিলের বিপরীতে একক ক্যোয়ারিতে একত্রিত করতে অনেক অর্থবোধ হয়েছে। এইভাবে আপনি অনেকবার টেবিলের ডেটা পড়বেন না এবং আপনাকে কোনও কার্সার বা অন্য কোনও ধরণের লুপ কোড করতে হবে না।

একটি একক কলাম পরীক্ষা করতে বিশ্বাস করুন যে আপনি কেবল এটি করতে পারেন:

SELECT COLUMN_1
FROM [P].[Q]
WHERE CAST(COLUMN_1 AS VARCHAR(80)) <> CAST(COLUMN_1 AS NVARCHAR(80));

থেকে কাস্ট করা NVARCHARআপনাকে VARCHARইউনিকোড অক্ষর ব্যতীত একই ফল দেওয়া উচিত। ইউনিকোড অক্ষর রূপান্তরিত হবে ?। সুতরাং উপরের NULLকোডগুলি সঠিকভাবে কেসগুলি পরিচালনা করা উচিত । আপনার কাছে চেক করার জন্য 24 টি কলাম রয়েছে, সুতরাং আপনি স্কেলার সমষ্টিগুলি ব্যবহার করে একক ক্যোয়ারিতে প্রতিটি কলাম পরীক্ষা করে দেখুন। একটি বাস্তবায়ন নীচে:

SELECT 
  MAX(CASE WHEN CAST(COLUMN_1 AS VARCHAR(80)) <> CAST(COLUMN_1 AS NVARCHAR(80)) THEN 1 ELSE 0 END) COLUMN_1_RESULT
...
, MAX(CASE WHEN CAST(COLUMN_14 AS VARCHAR(30)) <> CAST(COLUMN_14 AS NVARCHAR(30)) THEN 1 ELSE 0 END) COLUMN_14_RESULT
...
, MAX(CASE WHEN CAST(COLUMN_23 AS VARCHAR(8)) <> CAST(COLUMN_23 AS NVARCHAR(8)) THEN 1 ELSE 0 END) COLUMN_23_RESULT
FROM [P].[Q];

প্রতিটি কলামের জন্য আপনি এর 1কোনও মানটিতে ইউনিকোড রয়েছে কিনা এর ফলাফল পাবেন । এর ফলে 0সমস্ত ডেটা নিরাপদে রূপান্তর করা যায়।

আমি দৃ strongly়ভাবে নতুন কলাম সংজ্ঞা সহ টেবিলের একটি অনুলিপি তৈরি করার এবং সেখানে আপনার ডেটা অনুলিপি করার পরামর্শ দিচ্ছি। আপনি যদি এটি জায়গায় রাখেন তবে আপনি ব্যয়বহুল রূপান্তরগুলি করতে চলেছেন তাই কোনও অনুলিপি তৈরি করা এত ধীর হতে পারে না। অনুলিপি থাকার অর্থ আপনি সহজেই যাচাই করতে পারেন যে সমস্ত ডেটা এখনও রয়েছে (এক উপায় হল এক্সেসপটি কীওয়ার্ডটি ব্যবহার করা ) এবং আপনি খুব সহজেই অপারেশনটি পূর্বাবস্থায় ফিরিয়ে আনতে পারেন।

এছাড়াও, সচেতন থাকুন যে আপনার কাছে কোনও ইউনিকোড ডেটা নাও থাকতে পারে এটি সম্ভবত ভবিষ্যতের ইটিএল আগের পরিষ্কার কলামে ইউনিকোড লোড করতে পারে। আপনার ইটিএল প্রক্রিয়াতে যদি এটির জন্য কোনও চেক না পাওয়া যায় তবে এই রূপান্তরটি করার আগে আপনার এটি যোগ করার বিষয়টি বিবেচনা করা উচিত।

— জো ওবিশ
সূত্র

যদিও @ শ্রুতজকির উত্তর এবং আলোচনা বেশ ভাল ছিল এবং সহায়ক তথ্য ছিল, জো আমাকে আমার প্রশ্নটি যা জিজ্ঞাসা করছিল তা দিয়েছিল: কলামের কোনও মান আসলে ইউনিকোড আছে কিনা তা আমাকে জিজ্ঞাসা করার জন্য একটি জিজ্ঞাসা। তাই আমি জোয়ের উত্তরটিকে গ্রহণযোগ্য উত্তর হিসাবে চিহ্নিত করেছি। অন্যান্য উত্তরগুলিও আমাকে সহায়তা করেছিল আমি আপ-ভোট দিয়েছি।

— জন জি হোহেনগার্টেন

@ জনজিহহেনগার্টেন এবং জো: এটি বেশ ভাল। আমি কোয়েরিটি উল্লেখ করিনি কারণ এটি উত্তর এবং স্কট এর মতো ছিল। আমি কেবল এটিই বলব যে NVARCHARকলামটি রূপান্তর করার দরকার নেই NVARCHARকারণ এটি ইতিমধ্যে ধরণের। এবং আপনি কী পরিবর্তন নাযোগ্য চরিত্রটি নির্ধারণ করেছেন তা নিশ্চিত নন, তবে আপনি VARBINARYইউটিএফ -16 বাইট সিকোয়েন্সগুলি পেতে কলামটি রূপান্তর করতে পারেন । এবং ইউটিএফ -16 হ'ল বিপরীত বাইট ক্রম, সুতরাং p= 0x7000এবং তারপরে আপনি কোড পয়েন্ট পেতে সেই দুটি বাইট বিপরীত করুন U+0070। তবে, যদি উত্সটি ভ্রচার হয়, তবে এটি কোনও ইউনিকোড চরিত্র হতে পারে না। অন্য কিছু চলছে। আরও তথ্য প্রয়োজন।

— সলোমন রুটজকি

@ শ্রুতজকি আমি ডেটা টাইপের অগ্রাধিকারের সমস্যাগুলি এড়াতে কাস্ট যুক্ত করেছি। আপনি সঠিক হতে পারেন যে এটি প্রয়োজন নেই। অন্য প্রশ্নের জন্য, আমি ইউনিকোড () এবং সাবস্ক্রিং () পরামর্শ দিয়েছি। যে পদ্ধতির কাজ করে?

— জো ওবিশ

@JohnGHohengarten এবং জো: ডাটা টাইপ প্রাধান্য একটি ইস্যু হিসেবে থাকা উচিত নয় VARCHARপরোক্ষভাবে রূপান্তরিত করবে NVARCHAR, কিন্তু তা করতে ভালো হতে পারে CONVERT(NVARCHAR(80), CONVERT(VARCHAR(80), column)) <> column। SUBSTRINGকখনও কখনও কাজ করে, তবে শেষ হয় না এমন কলিশ ব্যবহার করার সময় এটি পরিপূরক চরিত্রগুলির সাথে কাজ করে না _SC, এবং জন জন যেটি ব্যবহার করছেন তা তা ব্যবহার করে না, যদিও এখানে সম্ভবত কোনও সমস্যা নেই। তবে VARBINARY এ রূপান্তর করা সর্বদা কার্যকর হয়। এবং CONVERT(VARCHAR(10), CONVERT(NVARCHAR(10), '›'))ফলাফল হয় না ?, তাই আমি বাইটগুলি দেখতে চাই। ইটিএল প্রক্রিয়া এটি রূপান্তর করতে পারে।

— সলোমন রুটজকি

5

কিছু করার আগে দয়া করে @RDFozz দ্বারা উত্থাপিত প্রশ্নগুলিতে প্রশ্নের একটি মন্তব্যে বিবেচনা করুন, যথা:

এই টেবিলটি পপুলেশন করার পাশাপাশি কি অন্য কোনও উত্স আছে [Q].[G]?

যদি প্রতিক্রিয়াটি "আমি 100% নিশ্চিত যে এটি এই গন্তব্য সারণীর জন্য ডেটাগুলির একমাত্র উত্স " এর বাইরে কিছু থাকে তবে সারণীতে থাকা ডেটাটি পরিবর্তিত হতে পারে তা নির্বিশেষে কোনও পরিবর্তন করবেন না, তথ্য ক্ষতি
অদূর ভবিষ্যতে এই ডেটা জনপ্রিয় করার জন্য অতিরিক্ত উত্স যুক্ত করার সাথে সম্পর্কিত কোনও পরিকল্পনা / আলোচনা আছে ?

এবং আমি একটি সংশ্লিষ্ট প্রশ্ন যোগ হবে: সেখানে আছে বিদ্যুৎ উৎস টেবিল (অর্থাত মধ্যে একাধিক ভাষা সমর্থন প্রায় কোনো আলোচনা হয়েছে [Q].[G]রূপান্তর দ্বারা) এটা করার NVARCHAR?

এই সম্ভাবনাগুলি বোঝার জন্য আপনাকে প্রায় জিজ্ঞাসা করতে হবে। আমি ধরে নিলাম আপনাকে বর্তমানে এমন কিছু বলা হয়নি যা এই দিক নির্দেশ করবে অন্যথায় আপনি এই প্রশ্ন জিজ্ঞাসা করবেন না, তবে এই প্রশ্নগুলি যদি "না" হিসাবে ধরে নেওয়া হয়, তবে তাদের জিজ্ঞাসা করা দরকার এবং একটি জিজ্ঞাসা করা উচিত সর্বাধিক নির্ভুল / সম্পূর্ণ উত্তর পেতে প্রশস্ত শ্রোতা।

এখানে মূল ইস্যুটিতে ইউনিকোড কোড পয়েন্টগুলি এত বেশি নয় যা রূপান্তর করতে পারে না (কখনও), তবে আরও এমন কোড পয়েন্ট রয়েছে যা সমস্ত কোনও একক কোড পৃষ্ঠায় ফিট করে না। এটি ইউনিকোড সম্পর্কে দুর্দান্ত জিনিস: এটি সমস্ত কোড পৃষ্ঠা থেকে অক্ষর ধরে রাখতে পারে। আপনি যদি NVARCHARকোথা থেকে কোড পৃষ্ঠা সম্পর্কে চিন্তা করার দরকার নেই - এ থেকে রূপান্তর করেন VARCHARতবে আপনাকে অবশ্যই নিশ্চিত করতে হবে যে গন্তব্য কলামের সমাহারটি উত্স কলাম হিসাবে একই কোড পৃষ্ঠাটি ব্যবহার করছে। এটি ধরে নিয়েছে যে কোনও একটি উত্স, বা একই কোড পৃষ্ঠা ব্যবহার করে একাধিক উত্স রয়েছে (যদিও অগত্যা একই সমষ্টি নয়)। তবে যদি একাধিক কোড পৃষ্ঠাগুলি সহ একাধিক উত্স থাকে তবে আপনি নিম্নলিখিত সমস্যাটিতে সম্ভাব্যরূপে চলতে পারেন:

DECLARE @Reporting TABLE
(
  ID INT IDENTITY(1, 1) PRIMARY KEY,
  SourceSlovak VARCHAR(50) COLLATE Slovak_CI_AS,
  SourceHebrew VARCHAR(50) COLLATE Hebrew_CI_AS,
  Destination NVARCHAR(50) COLLATE Latin1_General_CI_AS,
  DestinationS VARCHAR(50) COLLATE Slovak_CI_AS,
  DestinationH VARCHAR(50) COLLATE Hebrew_CI_AS
);

INSERT INTO @Reporting ([SourceSlovak]) VALUES (0xDE20FA);
INSERT INTO @Reporting ([SourceHebrew]) VALUES (0xE820FA);

UPDATE @Reporting
SET    [Destination] = [SourceSlovak]
WHERE  [SourceSlovak] IS NOT NULL;

UPDATE @Reporting
SET    [Destination] = [SourceHebrew]
WHERE  [SourceHebrew] IS NOT NULL;

SELECT * FROM @Reporting;

UPDATE @Reporting
SET    [DestinationS] = [Destination],
       [DestinationH] = [Destination]

SELECT * FROM @Reporting;

রিটার্ন (দ্বিতীয় ফলাফল সেট):

ID    SourceSlovak    SourceHebrew    Destination    DestinationS    DestinationH
1     Ţ ú             NULL            Ţ ú            Ţ ú             ? ?
2     NULL            ט ת             ? ?            ט ת             ט ת

যেহেতু আপনি দেখতে পারেন, যারা অক্ষরের সব করতে রূপান্তর VARCHARঠিক একই নয়, VARCHARকলাম।

আপনার উত্স সারণীর প্রতিটি কলামের জন্য কোড পৃষ্ঠাটি কী তা নির্ধারণ করতে নিম্নলিখিত কোয়েরিটি ব্যবহার করুন:

SELECT OBJECT_NAME(sc.[object_id]) AS [TableName],
       COLLATIONPROPERTY(sc.[collation_name], 'CodePage') AS [CodePage],
       sc.*
FROM   sys.columns sc
WHERE  OBJECT_NAME(sc.[object_id]) = N'source_table_name';

বলা হচ্ছে যে....

আপনি এসকিউএল সার্ভার ২০০৮ আর ২, বিউটিতে থাকার কথা বলেছেন, তবে সংস্করণটি কী বলেননি। যদি আপনি এন্টারপ্রাইজ সংস্করণে উপস্থিত হয়ে থাকেন তবে এই সমস্ত রূপান্তরকরণের জিনিসটি ভুলে যান (যেহেতু আপনি সম্ভবত এটি কেবল স্থান বাঁচানোর জন্য করছেন), এবং ডেটা সংক্ষেপণ সক্ষম করুন:

ইউনিকোড সংক্ষেপণ বাস্তবায়ন

যদি স্ট্যান্ডার্ড সংস্করণ ব্যবহার করা হয় (এবং এটি এখন মনে হয় যে আপনি then) তবে আরও একটি লুওং-শট সম্ভাবনা রয়েছে: এসকিউএল সার্ভার ২০১ to-তে আপগ্রেড করার কারণে এসপিএল সমস্ত সংস্করণে ডেটা সংক্ষেপণ ব্যবহারের ক্ষমতা অন্তর্ভুক্ত করেছে (মনে রাখবেন, আমি "লং-শট" বলেছিলাম "😉)।

অবশ্যই, এখন এটি কেবল স্পষ্ট করে দেওয়া হয়েছে যে ডেটাগুলির জন্য কেবল একটি উত্স রয়েছে, তবে উত্সটিতে কোনও ইউনিকোড-অক্ষর বা নির্দিষ্ট কোডের বাইরে অক্ষর থাকতে পারে না বলে আপনার উদ্বেগের কিছু নেই since পাতা। সেক্ষেত্রে আপনার উত্সাহের একমাত্র বিষয়টি উত্স কলামের মতো একই কোলেশন ব্যবহার করা বা কমপক্ষে একটি যা একই কোড পৃষ্ঠা ব্যবহার করছে তা ব্যবহার করা। অর্থ, যদি উত্স কলামটি ব্যবহার করে থাকে SQL_Latin1_General_CP1_CI_ASতবে আপনি Latin1_General_100_CI_ASগন্তব্যে ব্যবহার করতে পারেন ।

কোলেশন কী ব্যবহার করতে হবে তা একবার আপনি জানতে পারলে আপনিও পারেন:

ALTER TABLE ... ALTER COLUMN ...হতে VARCHAR(বর্তমান NULL/ NOT NULLসেটিংস নির্দিষ্ট করে দেওয়ার বিষয়ে নিশ্চিত হন ), যার জন্য 87৩ মিলিয়ন সারিগুলির জন্য কিছুটা সময় এবং প্রচুর লেনদেনের লগ স্পেস প্রয়োজন, বা
প্রত্যেকের জন্য নতুন "ColumnName_tmp" কলাম তৈরি করুন এবং ধীরে ধীরে মাধ্যমে পূরণ UPDATEকরছেন TOP (1000) ... WHERE new_column IS NULL। সমস্ত সারি একবার জনবসতিযুক্ত হয়ে যায় (এবং যাচাই করা হয় যে সেগুলি সমস্তগুলি সঠিকভাবে অনুলিপি করেছে! আপনার আপডেটগুলি হ্যান্ডেল করার জন্য একটি ট্রিগারের প্রয়োজন হতে পারে, যদি থাকে তবে) "স্পষ্ট" লেনদেনে, sp_rename"বর্তমান" কলামগুলির কলামের নামগুলি অদলবদল করতে ব্যবহার করুন " _ পুরানো "এবং তারপরে নতুন" _tmp "কলামগুলি নামগুলি থেকে কেবল" _tmp "সরাতে। তারপরে sp_reconfigureসারণীটি উল্লেখ করে কোনও ক্যাশেড পরিকল্পনা অকার্যকর করতে টেবিলের উপর কল করুন এবং সারণীতে রেফারেন্সিংয়ের কোনও মতামত থাকলে আপনাকে কল করতে হবে sp_refreshview(বা এর মতো কিছু)। একবার আপনি অ্যাপ্লিকেশনটি যাচাই করে নিলে এবং ইটিএল এটির সাথে সঠিকভাবে কাজ করছে, তারপরে আপনি কলামগুলি বাদ দিতে পারেন।

— সলোমন রুটজকি
সূত্র

আপনার উত্স এবং লক্ষ্য উভয় ক্ষেত্রেই সরবরাহ করা কোডপেজ ক্যোয়ারীটি আমি চালিয়েছি এবং কোডপেজটি 1252 এবং কোলেশন_নাম দুটি উত্স এবং লক্ষ্যবস্তুতে এসকিউএল_ল্যাটিন 1_ জেনারাল_সিপি 1_সিআই_এএস হয়।

— জন জি হোহেনগার্টেন

@ জনজিহহেনগার্টেন আমি ঠিক আবার আপডেট করেছি, নীচে। সহজ হওয়ার জন্য আপনি একই কোলেশন রাখতে পারবেন, যদিও Latin1_General_100_CI_ASআপনি ব্যবহার করছেন তার চেয়ে অনেক ভাল is সহজ অর্থ যে বাছাই এবং তুলনা আচরণটি তাদের মধ্যে একই রকম হবে, যদিও আমি সবেমাত্র উল্লেখ করেছি এমন নতুন কলেজের মতো ভাল না।

— সলোমন রুটজকি

4

আমার যখন আসল কাজ ছিল তখন থেকে আমার এটির সাথে কিছু অভিজ্ঞতা আছে। যেহেতু আমি বেস ডেটা সংরক্ষণ করতে চেয়েছিলাম, এবং আমাকে নতুন ডেটার জন্যও অ্যাকাউন্ট করতে হয়েছিল যার মধ্যে সম্ভবত এমন অক্ষর থাকতে পারে যা এলোমেলো হয়ে যায়, তাই আমি একটি অ-স্থায়ী গণিত কলাম দিয়ে গিয়েছিলাম।

এখানে থেকে সুপার ইউজার ডাটাবেসের একটি কপি ব্যবহার করে একটি দ্রুত উদাহরণ তাই তথ্য ডাম্প ।

আমরা ব্যাট থেকে ডানদিকে দেখতে পাচ্ছি যে ইউনিকোড অক্ষরগুলির প্রদর্শন নাম রয়েছে:

সুতরাং আসুন একটি গণনা কলাম যুক্ত করা যাক কত খুঁজে বের করতে! প্রদর্শন নাম কলামটি হ'ল NVARCHAR(40)।

USE SUPERUSER

ALTER TABLE dbo.Users
ADD DisplayNameStandard AS CONVERT(VARCHAR(40), DisplayName)

SELECT COUNT_BIG(*)
FROM dbo.Users AS u
WHERE u.DisplayName <> u.DisplayNameStandard

গণনাটি 3000 ডলার সারি দেয়

যদিও কার্যকর করার পরিকল্পনাটি কিছুটা টেনে আনুন। ক্যোয়ারী দ্রুত শেষ হয়েছে, তবে এই ডেটা সেটটি ভীষণ বড় নয়।

যেহেতু গণনা করা কলামগুলিকে একটি সূচক যুক্ত করার জন্য অধ্যবসায় করা উচিত নয়, আমরা এর মধ্যে একটি করতে পারি:

CREATE UNIQUE NONCLUSTERED INDEX ix_helper
ON dbo.Users(DisplayName, DisplayNameStandard, Id)

যা আমাদের সামান্য পরিপাটি পরিকল্পনা দেয়:

আমি বুঝতে পারি যে এটি উত্তর না হলে এটি আর্কিটেকচারাল পরিবর্তনগুলি জড়িত, তবে তথ্যের আকার বিবেচনা করে আপনি সম্ভবত টেবিলে নিজেরাই যোগ হওয়া প্রশ্নের মোকাবিলার জন্য সূচিপত্র যুক্ত করার দিকে তাকিয়ে আছেন।

আশাকরি এটা সাহায্য করবে!

— এরিক ডার্লিং
সূত্র

1

ক্ষেত্রটিতে ইউনিকোড ডেটা রয়েছে কিনা তা যাচাই করার উদাহরণ ব্যবহার করে আপনি প্রতিটি কলামে ডেটা পড়তে CASTএবং নীচে চেক করতে পারেন:

--Test 1:
DECLARE @text NVARCHAR(100)
SET @text = N'This is non-Unicode text, in Unicode'
IF CAST(@text AS VARCHAR(MAX)) <> @text
PRINT 'Contains Unicode characters'
ELSE
PRINT 'No Unicode characters'
GO

--Test 2:
DECLARE @text NVARCHAR(100)
SET @text = N'This is Unicode (字) text, in Unicode'
IF CAST(@text AS VARCHAR(MAX)) <> @text
PRINT 'Contains Unicode characters'
ELSE
PRINT 'No Unicode characters'

GO

— স্কট হজগিন
সূত্র