আমার কি উদ্বিগ্ন হওয়া উচিত?
ঠিক আছে, এখানে কয়েকটি জিনিস রয়েছে যা সামান্য বিষয় সম্পর্কিত।
প্রথম: যদিও এটি সত্য যে একটি UNIQUEIDENTIFIER(অর্থাত্ Guid) হল একটি 16 বাইট বাইনারি মান, এটিও সত্য যে:
- সমস্ত ডেটা বাইনারি ফর্মে সংরক্ষণ করা যেতে পারে (যেমন
INTসঞ্চিত যেতে পারে BINARY(4), DATETIMEসংরক্ষণ করা যাবে BINARY(8)ইত্যাদি), অত: পর # 2 ↴
- নিছক সুবিধার বাইরে জিইউইডিগুলির জন্য পৃথক ডেটাটাইপ থাকার কারণ সম্ভবত রয়েছে (যেমন
sysnameএকটি উপাধি হিসাবে NVARCHAR(128))।
আমি যে তিনটি আচরণগত পার্থক্য খুঁজে পেতে পারি তা হ'ল:
UNIQUEIDENTIFIERএসকিউএল সার্ভারে মানগুলির তুলনা করা ভাল বা আরও খারাপের জন্য, BINARY(16)মানগুলির তুলনা করার মতোই আসলে করা হয় না । এসকিউএল সার্ভারে মানগুলির তুলনা করার সময় জিইউইডি এবং অনন্য পরিচয়কারী মানগুলির তুলনা করার জন্য এমএসডিএন পৃষ্ঠা অনুসারে UNIQUEIDENTIFIER:
একটি মানের সর্বশেষ ছয় বাইট সবচেয়ে তাৎপর্যপূর্ণ
যদিও এই মানগুলি প্রায়শই বাছাই করা হয় না, তবে এই দুটি ধরণের মধ্যে সামান্য পার্থক্য রয়েছে। অনন্য পরিচয়দাতার জন্য এমএসডিএন পৃষ্ঠা অনুসারে :
অর্ডার দুটি মানের বিট নিদর্শনগুলির সাথে তুলনা করে প্রয়োগ করা হয় না।
প্রদত্ত যে এসকিউএল সার্ভার এবং .NET ("উপরে লিঙ্ক করা" জিইউইডি এবং অনন্য পরিচয়কারী মানগুলির পৃষ্ঠার তুলনায় উল্লিখিত) এর মধ্যে জিইউডি মানগুলি কীভাবে পরিচালনা করা হয় তার মধ্যে পার্থক্য রয়েছে, এসকিউএল সার্ভারের বাইরে থাকা এই ডেটাটিকে অ্যাপ কোডে টানলে সঠিকভাবে মোকাবেলা করা হবে না অ্যাপ্লিকেশন কোডটি যদি এসকিউএল সার্ভারের তুলনা আচরণ অনুকরণ করার প্রয়োজন হয়। সেই আচরণটি একটি রূপান্তর করে অনুকরণ করা যেতে পারে SqlGuid, তবে কোনও বিকাশকারী এটি করতে জানেন?
দ্বিতীয়: নিম্নলিখিত বিবৃতি উপর ভিত্তি করে
এটি প্রাথমিক কীগুলি সহ সমস্ত কিছুর জন্য এটি করে।
আমি সিস্টেমের কর্মক্ষমতা জন্য সাধারণভাবে পিকেএস যেমন পরিবর্তে একটি ব্যবহার সহ বিকল্প কী হিসাবে GUIDs ব্যবহার করে সংশ্লিষ্ট হতে চান INTবা এমনকি BIGINTপি কে হিসাবে। আরও বেশি উদ্বিগ্ন যদি এই জিইউইডি পিকেগুলি ক্লাস্টারড ইনডেক্স হয়।
হালনাগাদ
@ রবের উত্তরে ওপি দ্বারা নিম্নলিখিত মন্তব্যটি একটি অতিরিক্ত উদ্বেগ এনেছে:
আমার মাইএসকিউএল থেকে এটি স্থানান্তরিত হয়েছিল
জিইউইডিগুলি 2 টি বিভিন্ন বাইনারি ফর্ম্যাটে সংরক্ষণ করা যায় । সুতরাং, এর উপর নির্ভর করে উদ্বেগের কারণ হতে পারে:
- কোন সিস্টেমে বাইনারি উপস্থাপনা তৈরি করা হয়েছিল, এবং
- যদি স্ট্রিংয়ের মানগুলি মূল সিস্টেমের বাইরে ব্যবহার করা হয় যেমন অ্যাপ্লিকেশন কোডে বা ক্লায়েন্টদের আমদানি ফাইলগুলিতে ব্যবহার করার জন্য ইত্যাদি etc.
বাইনারি উপস্থাপনা যেদিকে উত্পন্ন হয়েছিল তা ইস্যুতে 4 "ক্ষেত্রের" মধ্যে 3 টির আগে বাইট অর্ডার দেওয়া উচিত। আপনি যদি উইকিপিডিয়া নিবন্ধের উপরের লিঙ্কটি অনুসরণ করেন, আপনি দেখতে পাবেন যে আরএফসি 4122 সমস্ত 4 টি ক্ষেত্রে "বিগ এন্ডিয়ান" এনকোডিং ব্যবহার করার জন্য নির্দিষ্ট করে, তবুও মাইক্রোসফ্ট জিইউইডিগুলি "নেটিভ" এন্ডিয়ানস ব্যবহার করে নির্দিষ্ট করে। ওয়েল, ইন্টেল আর্কিটেকচারটি লিটল এন্ডিয়ান, সুতরাং আরএফসি অনুসরণকারী সিস্টেমগুলি (পাশাপাশি বিগ এন্ডিয়ান সিস্টেমগুলিতে উত্পন্ন মাইক্রোসফ্ট-স্টাইলের জিইউডি) থেকে প্রথম 3 ক্ষেত্রের বাইট ক্রমটি বিপরীত হয়। প্রথম ক্ষেত্র, "ডেটা 1", 4 বাইট। একটি এন্ডিয়ানিয়নেসে এটি (অনুমানক) হিসাবে উপস্থাপিত হবে 0x01020304। তবে অন্য এন্ডিয়নেসনে এটি হবে 0x04030201। সুতরাং যদি বর্তমান ডাটাবেস 'BINARY(16)আরএফসি অনুসরণ করে একটি সিস্টেমে বাইনারি প্রতিনিধিত্ব করা হয়েছিল, তারপরে বর্তমানে BINARY(16)ক্ষেত্রের ডেটাগুলিকে এক হিসাবে রূপান্তরিত করার UNIQUEIDENTIFIERফলে মূলত যা তৈরি হয়েছিল তার চেয়ে আলাদা জিইউইডি হবে। এই সত্যিই একটি সমস্যা জাহির করা না যদি মান কখনোই ডাটাবেসের ছেড়ে এবং মান শুধুমাত্র কখনও সমতার জন্য এবং ক্রম তুলনা করা হয়।
অর্ডার দেওয়ার সাথে উদ্বেগটি কেবল এই যে তারা রূপান্তর করার পরে একই ক্রমে থাকবে না UNIQUEIDENTIFIER। ভাগ্যক্রমে, যদি আসল সিস্টেমটি সত্যই মাইএসকিউএল হয় তবে মাইএসকিউএল কেবল ইউইউডি-র একটি স্ট্রিং প্রতিনিধিত্ব করার কারণে প্রথম স্থানে বাইনারি উপস্থাপনার উপর অর্ডার করা হয়নি ।
উইন্ডোজ / এসকিউএল সার্ভারের বাইরে যদি বাইনারি প্রতিনিধিত্ব করা হয় তবে ডাটাবেসের বাইরে স্ট্রিংয়ের মানগুলির সাথে উদ্বেগ আরও গুরুতর। যেহেতু বাইট ক্রমটি সম্ভাব্যভাবে আলাদা, তারপরে স্ট্রিং আকারে একই জিইউডি-র পরিবর্তিত স্থানটি নির্ভর করে 2 বিভিন্ন বাইনারি উপস্থাপনার ফলস্বরূপ। অ্যাপ্লিকেশন কোড বা গ্রাহকদের স্ট্রিং আকারে একটি GUID দেওয়া ছিল ABCএকটি বাইনারি ফর্মে থেকে আসছে 123 এবং বাইনারি উপস্থাপনা একটি সিস্টেম এ উৎপন্ন হয় বোঝায় যা RFC নিম্নলিখিত, তারপর একই বাইনারি উপস্থাপনা (অর্থাত যে 123) একটি স্ট্রিং ফর্ম অনুবাদ হবে DEFযখন রূপান্তরিত ক UNIQUEIDENTIFIER। তেমনি, এর মূল স্ট্রিং ফর্মটি যখন একটি তে রূপান্তরিত হয় তখন ABCবাইনারি আকারে 456রূপান্তরিত হয় UNIQUEIDENTIFIER।
সুতরাং, যদি জিইউইডিগুলি ডাটাবেসটি কখনও না ফেলে থাকে তবে অর্ডার দেওয়ার বাইরে নিয়ে উদ্বিগ্ন হওয়ার মতো খুব বেশি কিছু নেই। অথবা, যদি মাইএসকিউএল থেকে আমদানি স্ট্রিং ফর্মকে রূপান্তর করে (যেমন FCCEC3D8-22A0-4C8A-BF35-EC18227C9F40) করা হয়ে থাকে তবে এটি ঠিক আছে। অন্যথায়, যদি এই জিইউইডিগুলি গ্রাহকদের বা অ্যাপ কোডে দেওয়া হয়েছিল, তবে তারা কীভাবে একটি পেয়ে এবং রূপান্তর করে কীভাবে রূপান্তর করে তা পরীক্ষা করে SELECT CONVERT(UNIQUEIDENTIFIER, 'value found outside of the database');দেখতে পারেন এবং প্রত্যাশিত রেকর্ডটি খুঁজে পান কিনা তা দেখুন। আপনি যদি রেকর্ডগুলি মেলাতে না পারেন তবে আপনাকে ক্ষেত্রগুলি যেমন রাখতে হবে BINARY(16)।
সমস্ত সম্ভাবনায় কোনও সমস্যা হবে না, তবে আমি এটি উল্লেখ করছি কারণ সঠিক পরিস্থিতিতে একটি সমস্যা হতে পারে।
এবং কীভাবে নতুন জিআইডিগুলি sোকানো হবে? অ্যাপ কোড তৈরি করা হয়েছে?
আপডেট 2
অন্য সিস্টেমে উত্পন্ন জিইউডির বাইনারি উপস্থাপনা আমদান সম্পর্কিত সম্ভাব্য ইস্যুটির পূর্ববর্তী ব্যাখ্যাটি যদি কিছুটা বিভ্রান্তিকর হয়, তবে আশা করি নিম্নলিখিতটি আরও পরিষ্কার হবে:
DECLARE @GUID UNIQUEIDENTIFIER = NEWID();
SELECT @GUID AS [String], CONVERT(BINARY(16), @GUID) AS [Binary];
-- String = 5FED23BE-E52C-40EE-8F45-49664C9472FD
-- Binary = 0xBE23ED5F2CE5EE408F4549664C9472FD
-- BE23ED5F-2CE5-EE40-8F45-49664C9472FD
উপরের দেখানো আউটপুটে, "স্ট্রিং" এবং "বাইনারি" মানগুলি একই জিইউডি থেকে। "বাইনারি" লাইনের নীচের মানটি "বাইনারি" লাইনের সমান মান, তবে "স্ট্রিং" লাইন (যেমন "মুছে ফেলা" এবং চারটি ড্যাশ যুক্ত করা) হিসাবে একই স্টাইলে ফর্ম্যাট করা হয়েছে। প্রথম এবং তৃতীয় মানগুলির তুলনা করা, সেগুলি হুবহু এক নয় , তবে তারা খুব নিকটে: ডান-সর্বাধিক দুটি বিভাগ অভিন্ন, তবে বাম-সর্বাধিক তিনটি বিভাগ নয়। তবে আপনি যদি ঘনিষ্ঠভাবে তাকান, আপনি দেখতে পাচ্ছেন যে এটি তিনটি বিভাগের প্রত্যেকটিতে একই বাইটগুলি কেবল একটি পৃথক ক্রমে। আমি কেবলমাত্র প্রথম তিনটি বিভাগ দেখি এবং বাইটগুলি সংখ্যাটি দেখি তা আরও সহজেই দেখা যায় যাতে তাদের অর্ডার দুটি উপস্থাপনার মধ্যে কীভাবে আলাদা হয় তা আরও সহজে দেখা যায়:
স্ট্রিং = 1 5 এফ 2 ইডি 3 23 4 বিই - 5 ই 5 6 2 সি - 7 40 8 ই ই
বাইনারি = 4 বি 3 3 2 2 ইডি 1 5 এফ - 6 2 সি 5 ই 5 - 8 ইই 7 40 (উইন্ডোজ / এসকিউএল সার্ভারে)
সুতরাং প্রতিটি গ্রুপিংয়ের মধ্যে, বাইটগুলির ক্রমটি বিপরীত হয় তবে কেবল উইন্ডোজ এবং এসকিউএল সার্ভারের মধ্যে। তবে, যে সিস্টেমে আরএফসির সাথে সম্মতি রয়েছে, সেখানে বাইনারি উপস্থাপনা স্টিং প্রতিনিধিত্ব করবে কারণ বাইট ক্রমের কোনও বিপরীত হবে না।
কীভাবে ডেটা মাইএসকিউএল থেকে এসকিউএল সার্ভারে আনা হয়েছিল? এখানে কয়েকটি পছন্দ রয়েছে:
SELECT CONVERT(BINARY(16), '5FED23BE-E52C-40EE-8F45-49664C9472FD'),
CONVERT(BINARY(16), 0x5FED23BEE52C40EE8F4549664C9472FD),
CONVERT(BINARY(16), CONVERT(UNIQUEIDENTIFIER, '5FED23BE-E52C-40EE-8F45-49664C9472FD'));
রিটার্নস:
0x35464544323342452D453532432D3430
0x5FED23BEE52C40EE8F4549664C9472FD
0xBE23ED5F2CE5EE408F4549664C9472FD
ধরে নিলাম এটি সরাসরি বাইনারি-থেকে-বাইনারি ছিল (যেমন উপরে রূপান্তর # 2), তবে ফলস্বরূপ জিইউইডি, যদি প্রকৃত রূপান্তরিত হয় UNIQUEIDENTIFIER, তা হবে:
SELECT CONVERT(UNIQUEIDENTIFIER, 0x5FED23BEE52C40EE8F4549664C9472FD);
রিটার্নস:
BE23ED5F-2CE5-EE40-8F45-49664C9472FD
যা ভুল। এবং এটি আমাদের তিনটি প্রশ্ন রেখে যায়:
- কীভাবে এসকিউএল সার্ভারে ডেটা আমদানি করা হয়েছিল?
- অ্যাপ কোডটি কোন ভাষায় লেখা আছে?
- অ্যাপ কোডটি কোন প্লাটফর্মে চলছে?