প্রাথমিক কী হিসাবে বা ইউনিক কলাম হিসাবে এনভিচারার কলাম

11

আমি একটি এসকিউএল সার্ভার 2012 ডেটাবেস বিকাশ করছি এবং আমার প্রাথমিক কী হিসাবে এনভারচর কলামগুলি সম্পর্কে সন্দেহ আছে।

আমার এই টেবিলটি রয়েছে:

CREATE TABLE [dbo].[CODES]
(
    [ID_CODE] [bigint] IDENTITY(1,1) NOT NULL,
    [CODE_LEVEL] [tinyint] NOT NULL,
    [CODE] [nvarchar](20) NOT NULL,
    [FLAG] [tinyint] NOT NULL,
    [IS_TRANSMITTED] [bit] NOT NULL DEFAULT 0,
     CONSTRAINT [PK_CODES] PRIMARY KEY CLUSTERED 
    (
        [CODE_LEVEL] ASC,
        [CODE] ASC
    )
)

তবে এখন আমি [CODE]কলামটি প্রাথমিক কী হিসাবে ব্যবহার করতে এবং [ID_CODE]কলামটি সরাতে চাই ।

আমার NVARCHARযেমন কলাম আছে তেমন কোনও সমস্যা বা জরিমানা আছে PRIMARY KEY?

[CODE]কলাম মান অবশ্যই অনন্য হতে হবে, তাই আমি ভেবেছিলাম যে আমি UNIQUEthat কলামটিতে একটি সীমাবদ্ধতা সেট করতে পারি ।

আমার কি [CODE]প্রাথমিক কী হিসাবে ব্যবহার করতে হবে বা আমি কলামে কোনও UNIQUEসীমাবদ্ধতা সেট করলে এটি আরও ভাল [CODE]?

sql-server primary-key unique-constraint

— VansFannel
সূত্র

1

অত্যন্ত গুরুত্বপূর্ণ বিষয় বিবেচনা করে আপনার টেবিলে কয়টি সারি থাকবে?

— জেমস জেড

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

— ম্যাঙ্গো

@ মানঙ্গো, আপনার মন্তব্যের জন্য ধন্যবাদ হ্যাঁ, আমি সেভাবে করেছি: ID_CODE হল প্রাথমিক কী এবং কোডটি অনন্য।

— ভ্যানসফ্যানেল

13

হ্যাঁ, একেবারে প্রাথমিক কীতে সংখ্যার প্রকারের পরিবর্তে স্ট্রিং ব্যবহারের নেতিবাচক পরিণতি ঘটতে পারে এবং এরপরেও যদি সেই পিকে ক্লাস্টার করা হয় (যা প্রকৃতপক্ষে এটি আপনার ক্ষেত্রে রয়েছে)। তবে, আপনি যে ডিগ্রিতে স্ট্রিং ক্ষেত্রটি ব্যবহারের প্রভাব (গুলি) দেখছেন তা হ'ল ক) এই সারণীতে কতগুলি সারি রয়েছে এবং খ) অন্যান্য সারণীতে কত সারি এই পিকে বিদেশী রয়েছে। আপনার যদি এই টেবিলের মধ্যে কেবল 10 কে সারি এবং অন্য কয়েকটি টেবিলের 100k সারি থাকে যা সেই ক্ষেত্রের মাধ্যমে এই টেবিলের কাছে FK থাকে, তবে সম্ভবত এটি এতটা লক্ষণীয় হবে না। সারি সংখ্যা বাড়ার সাথে সাথে সেই প্রভাবগুলি আরও লক্ষণীয় হয়ে ওঠে।

আপনার বিবেচনা করা দরকার যে ক্লাস্টারড ইনডেক্সের ক্ষেত্রগুলি নন-ক্লাস্টারড ইনডেক্সগুলিতে প্রেরণ করা হয়েছে। সুতরাং আপনি কেবল প্রতি সারিতে 40 বাইট অবধি দেখছেন না, তবে (40 * কিছু_ সংখ্যা) বাইট। এবং যে কোনও এফকে টেবিলগুলিতে আপনার সারিগুলিতে একই 40 বাইট থাকে এবং প্রায়শই না হয় সেই ক্ষেত্রটিতে একটি নন-ক্লাস্টারড ইনডেক্স থাকবে কারণ এটি জিনগুলিতে ব্যবহৃত হচ্ছে, সুতরাং এখন কোনও টেবিলে এটি সত্যিই দ্বিগুণ হয়ে গেছে যে এফকে এইটা. যদি কেউ মনে করে যে 40 বাইট * 1 মিলিয়ন সারি * 10 কপি এটি নিয়ে উদ্বিগ্ন হবার কিছু নয়, দয়া করে আমার নিবন্ধটি দেখুন ডিস্ক সস্তা Cheap Orly? যা এই সিদ্ধান্ত দ্বারা প্রভাবিত সমস্ত জায়গার (বা কমপক্ষে সর্বাধিক) বিবরণ দেয়।

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

সুতরাং, এর মতো কিছু ব্যবহার করা CHAR(5)সম্ভবত একটি ক্লাস্টারড পিকে-র জন্য ঠিক আছে, তবে বেশিরভাগ ক্ষেত্রে যদি এটির সাথে সংজ্ঞাও দেওয়া হয় COLLATE Latin1_General_100_BIN2(বা এর মতো কিছু)।

এবং কি কখনও মূল্য [CODE]বদলাতে পারে? যদি হ্যাঁ হয় তবে এটি পিকে হিসাবে না ব্যবহার করার আরও বেশি কারণ (আপনি যদি এফকে সেট করে থাকেন তবেও ON UPDATE CASCADE)। যদি এটি পরিবর্তন করতে না পারে বা না পরিবর্তন করে তবে তা ঠিক আছে, তবে এখনও এটি ক্লাস্টারড পিকে হিসাবে ব্যবহার না করার জন্য যথেষ্ট কারণ রয়েছে।

অবশ্যই, প্রশ্নটি ভুলভাবে বর্ণিত হতে পারে কারণ দেখা যাচ্ছে যে ইতিমধ্যে আপনার পিকেতে ইতিমধ্যে আপনার এই ক্ষেত্রটি রয়েছে।

নির্বিশেষে, আপনার সেরা বিকল্পটি এখন পর্যন্ত [ID_CODE]ক্লাস্টারড পিকে হিসাবে ব্যবহার করা, সেই ক্ষেত্রটি এফকে হিসাবে সম্পর্কিত টেবিলগুলিতে ব্যবহার করা এবং [CODE]একটি হিসাবে রাখা UNIQUE INDEX(যার অর্থ এটি একটি "বিকল্প কী")।

এই উত্তরের মন্তব্যে এই প্রশ্নের উপর ভিত্তি করে আরও কিছু তথ্য আপডেট করুন:

[ID_CODE], প্রাইমারী কী হিসাবে, আমি যদি টেবিলটি সন্ধান করতে [কোড] কলামটি ব্যবহার করি তবে সবচেয়ে ভাল বিকল্প?

এটি সমস্ত একটি দুর্দান্ত অনেকগুলি বিষয়ের উপর নির্ভর করে, যার মধ্যে কয়েকটি আমি ইতিমধ্যে উল্লেখ করেছি তবে পুনরায় ফিরিয়ে আনব:

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

এখন পর্যন্ত আপনি আমাদের জানাননি যে [CODE]ক্ষেত্রটি সমস্ত কোণ থেকে সিস্টেমের সাথে কীভাবে খাপ খায়, এখনই উল্লেখ করা বাহিরে যে আপনি সারিগুলি কীভাবে দেখছেন, তবে এটি কি সমস্ত প্রশ্নের জন্য বা কেবল কিছু জন্য? অত: পর:

সংক্রান্ত [CODE]মান:
- কিভাবে এটি উত্পন্ন হয়?
- এটি কি বর্ধিত বা psuedo-এলোমেলো?
- এটি কি অভিন্ন দৈর্ঘ্য বা দৈর্ঘ্যের ভিন্নতা?
- কোন অক্ষর ব্যবহৃত হয়?
- যদি বর্ণানুক্রমিক অক্ষর ব্যবহার করা হয়: এটি কেস-সংবেদনশীল বা সংবেদনশীল?
- এটি everোকানোর পরে কি কখনও পরিবর্তন হতে পারে?
এই টেবিল সম্পর্কিত:
- এই টেবিলে অন্য কোনও টেবিল এফকে আছে? অথবা এই ক্ষেত্রগুলি ( [CODE]বা [ID_CODE]) অন্য টেবিলগুলিতে ব্যবহার করা হয়, এমনকি বিদেশী না করে স্পষ্টভাবে বলা হয়?
- যদি [CODE] একমাত্র ক্ষেত্র পৃথক সারি পেতে ব্যবহৃত হয়, তবে [ID_CODE]ক্ষেত্রটি কোন উদ্দেশ্যে কাজ করে? যদি এটি ব্যবহার না করা হয় তবে কেন এটি প্রথম স্থানে রয়েছে (যা " [CODE]ক্ষেত্রটি কি কখনও বদলে যেতে পারে ?") এর উত্তরের উপর নির্ভর করে ?
- এই সারণীতে কত সারি?
- যদি অন্য টেবিলগুলি এই টেবিলটি উল্লেখ করে, তাদের প্রত্যেকটিতে কতগুলি এবং কতগুলি সারি রয়েছে?
- এই টেবিলের জন্য সূচকগুলি কী কী?

এই সিদ্ধান্তটি নিখুঁতভাবে "এনভিচারার হ্যাঁ বা না?" প্রশ্নে করা যাবে না। আমি আবার বলব যে সাধারণভাবে বলতে গেলে আমি এটি একটি ভাল ধারণা বলে মনে করি না, তবে বেশিরভাগ সময় অবশ্যই এটি ঠিক থাকে। এই টেবিলের খুব কম ক্ষেত্র প্রদত্ত এটি সম্ভবত আর কোনও, বা কমপক্ষে অনেকগুলি নয়, সূচক রয়েছে is সুতরাং [CODE]ক্লাস্টারড সূচক হিসাবে আপনি যে কোনও উপায়ে থাকতে পারেন । এবং যদি অন্য কোনও টেবিলগুলি এই টেবিলটিকে উল্লেখ না করে তবে আপনি এটি পিকে করে তুলতেও পারেন। তবে, যদি অন্য টেবিলগুলি এই টেবিলটিকে রেফারেন্স দেয় তবে আমি [ID_CODE]ক্ষেত্রটিকে পিকে হিসাবে বেছে নেব , এমনকি যদি নন-ক্লাস্টারযুক্তও হয়।

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

অজ্ঞাতনামা ডাউনভোটার (যিনি @ নোডনথিসিস্টেমের উত্তরটিও নিচে ভোট দিয়েছেন বলে মনে হয়) কোনও গঠনমূলক সমালোচনা দেওয়ার বা কোনও ত্রুটিযুক্ত যুক্তি দেখানোর জন্য যত্ন নেবে?

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

আপনার উত্তরের জন্য ধন্যবাদ. আমি [ID_CODE]যেমন টেবিলটি দেখার PRIMARY KEYজন্য [CODE]কলামটি ব্যবহার করি তবে কি সেরা বিকল্প ?

— ভ্যানসফ্যানেল

@ ভ্যানফ্যানেল দয়া করে আমার আপডেট দেখুন। ধন্যবাদ।

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

আমি এই উত্তরটি আপভোট করতে এই ডিবিএ সম্প্রদায়টিতে যোগদান করেছি।

— আহমেট আরসলান

6

আপনাকে ধারণাগুলি পৃথক করতে হবে:

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

ক্লাস্টারড ইনডেক্স হতে প্রাথমিক কীটির প্রয়োজন হয় না। আপনার কাছে ID_CODEপিকে এবং (CODE_LEVEL, CODE)ক্লাস্টার কী হিসাবে থাকতে পারে । কাছাকাছি বা অন্যান্য উপায়.

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

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

প্রাথমিক কী পছন্দ হিসাবে, এটি কোনও সমস্যাও হওয়া উচিত নয়: আপনার ডেটা মডেল, আপনার অ্যাপ্লিকেশন যুক্তি, প্রাথমিক কীটি নির্দেশ করে।

বলা হচ্ছে যে, আমার 2C: NVARCHAR(20)হয় না ওয়াইড। এমনকি একটি বৃহত টেবিলের জন্য একটি নিখুঁতভাবে গ্রহণযোগ্য ক্লাস্টারযুক্ত কী আকার।

— রিমাস রুসানু
সূত্র

আপনার উত্তরের জন্য ধন্যবাদ. আমি [ID_CODE]যেমন টেবিলটি সন্ধান PRIMARY KEYকরতে [CODE]কলামটি (এবং সম্ভবত [CODE_LEVEL]) ব্যবহার করি তবে কি সেরা বিকল্প ?

— ভ্যানসফ্যানেল

শুধুমাত্র @VansFannel আপনি যে উত্তর দিতে পারেন।

— রিমাস রুসানু

তবে আপনার মতে ...

— ভ্যানসফ্যানেল

2

আমার মতামতটি পুরো টেবিল এবং সমস্ত সূচকের সঠিক ডিডিএল, বিদেশী কীগুলি এটি উল্লেখ করে, সারিগুলির আনুমানিক সংখ্যা, প্রত্যাশিত ক্যোয়ারির কাজের চাপ, অ্যাপ্লিকেশনটির প্রত্যাশা এসএলএস এবং হার্ডওয়্যার এবং লাইসেন্সিংয়ের জন্য অন্তত উপলব্ধ বাজেটে নয় consider

— রিমাস রুসানু

ধন্যবাদ। আমি [CODE]কলামটি প্রাথমিক কী হিসাবে ব্যবহার করব ।

— ভ্যানসফ্যানেল

4

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

এছাড়াও, আপনি কি বুঝতে পেরেছেন যে 'বিগিন্ট আইডেন্টিটি (1,1)' 9,223,372,036,854,775,807 পর্যন্ত বৃদ্ধি করতে পারে?

[ID_CODE] [bigint] IDENTITY(1,1)

আপনি যদি গুগলের জন্য এই ডাটাবেসটি তৈরি না int identity (1,1)করেন, তবে 2 বিলিয়ন এর বেশি সীমাবদ্ধ হওয়া কি কোনও স্বাভাবিক নয় ?

— এই সিস্টেমে কোনও আইডি নেই
সূত্র

এসকিউএল-তে 4 বাইট, যা আপনাকে -২.১ বিলিয়ন + ২.১ বিলিয়ন দেয়।

— ডেটাগোড

@ ডাটাগোড, হ্যাঁ ধন্যবাদ, এতগুলি সংখ্যাকে আমি ভুল বলেছি!

— এই সিস্টেমে কোনও আইডি নেই

আপনার উত্তরের জন্য ধন্যবাদ. আমি [ID_CODE]যেমন টেবিলটি দেখার PRIMARY KEYজন্য [CODE]কলামটি ব্যবহার করি তবে কি সেরা বিকল্প ? ধন্যবাদ।

— ভ্যানসফ্যানেল

আমার ডিবিতে ডেটা / ব্যবহারকারীর পূর্বাভাস দেওয়ার জন্য আমার "ইনট" এর ক্রমিক প্রকৃতিটি ব্যবহার না করা এবং আমার যা কিছু ছিল তার বেশিরভাগ ফসল কাটা পর্যন্ত আমি এই নৌকায় থাকতাম। কখনও না. জনগণের মুখোমুখি ডিবি-র তথ্য বের করা আরও কিছুটা জটিল হতে হবে।

— ডাবলু

3

সচেতন না হলে এনভারচার / বার্চার ব্যবহার করার সময় প্রশস্ত কীগুলি ব্যবহার করার ঝুঁকি ছাড়া অন্য কোনও সহজাত / লক্ষণীয় জরিমানা থাকা উচিত নয়। বিশেষত যদি আপনি তাদের সম্মিলিত কীগুলিতে সংযুক্ত করতে শুরু করেন।

তবে আপনার (20) দৈর্ঘ্যের উদাহরণে আপনার ভাল হওয়া উচিত এবং আমি এটি সম্পর্কে খুব বেশি চিন্তা করব না। কারণ যদি CODE হয় কীভাবে আপনি মূলত আপনার ডেটাটিকে জিজ্ঞাসা করেন - এতে একটি ক্লাস্টারড সূচকটি খুব বুদ্ধিমান মনে হয়।

যাইহোক, আপনি এটি প্রাথমিক কী বা কেবল একটি অনন্য (ক্লাস্টারড) সূচক হিসাবে চান তা বিবেচনা করা উচিত। ক্লাস্টারড ইনডেক্স এবং প্রাইমারি কী (মূলত - প্রাথমিক কী আপনার ডেটা সনাক্ত করে তবে সূচিটি কীভাবে আপনি ডেটা ক্যোয়ারী করেন) এর মধ্যে একটি (ছোট) পার্থক্য রয়েছে, তাই আপনি যদি চান তবে আপনি সহজেই আপনার আইডি_কোডকে একটি প্রাথমিক কী হিসাবে তৈরি করতে পারতেন এবং কোডের উপর একটি অনন্য ক্লাস্টারড ইনডেক্স তৈরি করুন। (বিজ্ঞপ্তি: এসকিউএল সার্ভার স্বয়ংক্রিয়ভাবে আপনার প্রাথমিক কীটিকে একটি ক্লাস্টারড ইনডেক্সে পরিণত করবে, যদি না আপনি নিজে নিজে নিজেই ক্লাস্টারড সূচক তৈরি করেন)

আপনার আসলে আইডি_ কোড দরকার কিনা তা বিবেচনা করুন এখন আপনার কাছে একটি অনন্য কোড আছে।

— অ্যালান এস হানসেন
সূত্র

2

আসলে, NVARCHAR(20)হয় 40 আকার (সর্বোচ্চ) বাইট এবং যেহেতু এটা পরিবর্তনশীল দৈর্ঘ্যের কলাম, এটা সত্যিই ক্লাস্টার সূচক জন্য সবচেয়ে ভাল পছন্দ নয়। ID_CODEএকটি হচ্ছে BIGINT IDENTITYহবে অনেক ভালো এখানে পছন্দ!

— marc_s

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

— অ্যালান এস S. হানসেন

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

— অ্যালান এস হানসেন