সর্বদা একটি স্বয়ংসোধক পূর্ণসংখ্যার প্রাথমিক কীটি রাখা ভাল অনুশীলন?

Question

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

এটি কি একটি খারাপ ধারণা হিসাবে বিবেচিত? এইভাবে এটি করতে কোনও অসুবিধা আছে? কখনও কখনও আমার একাধিক সূচক থাকবে যেমন অনন্য শনাক্তকারী id, profile_id, subscriptionsকোথায় id, কোনও টেবিলের profile_idবিদেশের লিঙ্কগুলি ইত্যাদি haveidProfile

বা এমন কোনও দৃশ্য আছে যেখানে আপনি এই জাতীয় ক্ষেত্রটি যুক্ত করতে চান না?

Comments

উদাহরণস্বরূপ জার্মান ট্যাঙ্ক সমস্যার দিকে নজর দিন যেখানে একটি সরল স্বতঃবৃদ্ধি সনাক্তকারী একটি সমস্যা problem অবশ্যই আপনি যদি আপনার আইডিগুলি সর্বজনীনভাবে ব্যবহার করছেন তবে এটি কেবলমাত্র গুরুত্বপূর্ণ।

— বার্গি

@ অরুকাজে মুল বক্তব্যটি হ'ল এটি সিস্টেম সম্পর্কে কিছু তথ্য ফাঁস করে। উদাহরণস্বরূপ, ধরুন ডাটাবেসটিতে ব্যবহারকারী-লিখিত পোস্ট রয়েছে, যার প্রতিটি ক্রমিক আইডি পায়। বলুন আপনি চারটি পোস্ট করেছেন, যার প্রত্যেকটির একটি আইডি পেয়েছে: সকাল 4 টা (20), সকাল 5 টা (25), রাত 8 টা (100) এবং রাত 9 টা (200)। এইডসটি দেখে আপনি দেখতে পাবেন যে কেবলমাত্র 5 টি পোস্ট সকাল 4 টা থেকে 5 টা পর্যন্ত যুক্ত করা হয়েছে, এবং 100 টি রাত 8 টা থেকে 9 টার মধ্যে যুক্ত করা হয়েছিল। আপনি যদি সার্ভিস আক্রমণকে অস্বীকার করার জন্য সময়টি বেছে নেওয়ার চেষ্টা করছেন, তবে এটি মূল্যবান তথ্য হতে পারে।

— জোশুয়া টেলর

"জার্মান ট্যাঙ্ক সমস্যা" সম্পর্কে অভিযোগকারী প্রত্যেকের কাছে .... যদি কেবল তথ্যটি কাউকে অ্যাক্সেস করা থেকে বিরত রাখা হয় তবে আপনার ইউআরএল এর মূল কী নয় ... আপনার জিইউডি বনাম অটো আইএনটির চেয়ে বড় সমস্যা রয়েছে।

— ম্যাথু হোয়াইট

@ ম্যাথিউহাইটেড এটি কেবলমাত্র একটি ইউআরএলে প্যারামিটারগুলি অদলবদল করার বিষয়ে নয়। মনে করুন আপনি কোনও সাইট ব্যবহার করেন এবং আপনি সময়ে সম্পদ 100 এবং সময়ে t120 সম্পদ তৈরি করেন t + 60। আপনি যদি উভয় আইডি (100 এবং 120) অবিচ্ছিন্ন আকারে দেখতে পান তবে এখন আপনি যে সম্পদের উপস্থিতি এবং সেই সাথে তারা যে হারে তৈরি করেছেন তার মোট সংখ্যা জানেন। এটি তথ্য ফাঁস। এটি নিখুঁত অনুমানমূলক নয়।

— ক্রিস হেইস

" সর্বদা এটি কি ভাল অনুশীলন ..." না

— ব্রায়ান_আগস্ট

Answer 1

গ্যারান্টিযুক্ত অনন্য সারি শনাক্তকারী থাকা কখনও খারাপ ধারণা নয়। আমার মনে হয় আমার কখনই বলা উচিত নয় - তবে আসুন এটি একটি ভাল ধারণা।

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

Comments

এটা যা আমি করি. বেশিরভাগ লোকেরা হয় 'আইডি' বা 'টেবিলনাম_আইডি' (যেমন ব্যবহারকারী_আইডি) ব্যবহার করেন। কলামটির প্রয়োজন হলে আর্গুমেন্টটি সাধারণত হয় না তবে এটি নামকরণের উপায়।

— গ্র্যান্ডমাস্টারবি

ব্যক্তিগতভাবে আমি মনে করি টেবিলের নামটি বিশ্রামটি বোঝায়। TableName.idএর বিপরীতে TableName.TableName_id, কারণ আর কী idউল্লেখ করা যাচ্ছে? আমার যদি টেবিলে অন্য আইডি ক্ষেত্র থাকে তবে আমি এটি অন্য কোনও টেবিলের উল্লেখ করলে এটি একটি টেবিলের নাম দিয়ে উপসর্গ করব

— এজেজে

@ অরুকাজে আপনি উল্লেখ করেছেন আপনি এসকিউএলাইট ব্যবহার করছেন। এটি আসলে একটি বিশেষ ক্ষেত্রে কিছুটা, কারণ এটি সর্বদা এই জাতীয় কলামকে 'হুডের নীচে' করে তোলে। সুতরাং আপনি এমনকি কোনও অতিরিক্ত স্থান ব্যবহার করছেন না কারণ আপনি এটি চান কিনা তা আপনি পেয়ে যান। এছাড়াও, এসকিউএলাইটের রোউইড সর্বদা একটি 64 বিট পূর্ণসংখ্যা হয়। যদি আমার এটির সঠিক বোঝা হয়, আপনি যদি একটি স্বয়ং-বর্ধনকারী সারিটি সংজ্ঞায়িত করেন তবে এটি অভ্যন্তরীণ রোউইডের একটি উপাধি হবে। সুতরাং আপনি ভাল সবসময় এটি করতে পারে! Sqlite.org/autoinc.html

— গ্র্যান্ডমাস্টারবি

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

— হামহ্যামজে

@ গ্র্যান্ডমাস্টারবি: এসকিউএলাইটের বর্তমান সংস্করণটি অপ্টিমাইজেশন হিসাবে WITHOUT ROWIDটেবিলগুলি (একটি স্পষ্ট করে PRIMARY KEY) তৈরি করার অনুমতি দেয় । তবে অন্যথায়, একটি INTEGER PRIMARY KEYকলামটি রোউইডের জন্য একটি নাম।

— dan04

Answer 2

আমি এর আগে সমস্ত উত্তরগুলির সাথে একমত নই। সমস্ত টেবিলগুলিতে একটি স্বয়ংক্রিয় বর্ধিত ক্ষেত্র যুক্ত করা খারাপ ধারণা হবার অনেকগুলি কারণ রয়েছে।

আপনার যদি এমন কোনও টেবিল থাকে যেখানে কোনও সুস্পষ্ট কী নেই, তবে একটি স্বয়ংক্রিয়-বৃদ্ধি ক্ষেত্রটি একটি ভাল ধারণা বলে মনে হচ্ছে। সর্বোপরি, আপনি চান না select * from blog where body = '[10000 character string]'। আপনি বরং select * from blog where id = 42। আমি যুক্তি দিয়েছি যে এর বেশিরভাগ ক্ষেত্রেই আপনি যা চান তা একটি অনন্য সনাক্তকারী; অনুক্রমিক অনন্য সনাক্তকারী নয়। পরিবর্তে আপনি সম্ভবত সর্বজনীন অনন্য সনাক্তকারী ব্যবহার করতে চান।

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

এটি আক্রমণকারীদের url এর পৃষ্ঠাগুলিতে অনুমান করা উচিত যাতে তাদের অ্যাক্সেস না করা উচিত। যদি সেখানে https://example.com/user/1263থাকে তবে খুব সম্ভবত আছে https://example.com/user/1262। এটি ব্যবহারকারীর প্রোফাইল পৃষ্ঠায় কোনও সুরক্ষার শোষণের অটোমেশনের অনুমতি দিতে পারে।

এমন অনেকগুলি মামলা রয়েছে যেখানে ইউইড কলামটি অকেজো বা এমনকি ক্ষতিকারক। ধরা যাক আপনার একটি সামাজিক নেটওয়ার্ক রয়েছে। একটি usersটেবিল এবং একটি friendsটেবিল আছে। বন্ধু সারণীতে দুটি ইউজারিড কলাম এবং একটি স্ব-বৃদ্ধি ক্ষেত্র রয়েছে। আপনি এর 3সাথে বন্ধু হতে চান 5, তাই আপনি 3,5ডাটাবেসে প্রবেশ করুন। ডাটাবেসটিতে একটি অটো-ইনক্রিমেন্ট আইডি এবং স্টোর যুক্ত হয় 1,3,5। কোনওভাবে, ব্যবহারকারী 3আবার "বন্ধু যুক্ত করুন" -তে বাটন ক্লিক করে। আপনি 3,5আবার ডাটাবেসে sertোকান, ডাটাবেসটি একটি স্ব-বৃদ্ধি আইডি এবং সন্নিবেশ যুক্ত করে 2,3,5। তবে এখন 3এবং 5দু'বার একে অপরের সাথে বন্ধু! এটি স্থানের অপচয়, এবং যদি আপনি এটির বিষয়ে চিন্তা করেন তবে স্বয়ংক্রিয়-বৃদ্ধি কলামও column সমস্ত কিনা তা দেখতে প্রয়োজন aএবংbবন্ধু হ'ল এই দুটি মান সহ সারির জন্য নির্বাচন করা। তারা একসাথে একটি অনন্য সারি শনাক্তকারী। (আপনি সম্ভবত কিছু যুক্তি রচনা করতে চান তা নিশ্চিত করতে 3,5এবং 5,3নকল হয়ে গেছে))

এখনও এমন কিছু ক্ষেত্রে রয়েছে যেখানে সিক্যুয়াল আইডি কার্যকর হতে পারে যেমন একটি ইউআরএল-শর্টনার তৈরি করার সময়, তবে বেশিরভাগ (এবং এমনকি ইউআরএল সংক্ষিপ্তর দিয়েও) একটি এলোমেলোভাবে উত্পন্ন ইউনিক আইডি হ'ল আপনি আসলে এর পরিবর্তে ব্যবহার করতে চান।

টিএল; ডিআর: আপনার কাছে ইতিমধ্যে প্রতিটি সারি চিহ্নিত করার কোনও অনন্য উপায় না থাকলে স্বয়ংক্রিয়ভাবে বৃদ্ধির পরিবর্তে ইউআইডি'র ব্যবহার করুন।

Comments

ইউআইডি গুলির সমস্যা হ'ল তারা বেশিরভাগ টেবিলের জন্য খুব বেশি জায়গা নেয়। প্রতিটি টেবিলের জন্য সঠিক অনন্য সনাক্তকারী ব্যবহার করুন।

— স্টিফেন

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

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

— yurez

"ইউআরএল অনুমান" পয়েন্টে, একটি অনন্য আইডি (ক্রমানুসারে বা অন্যথায়) থাকা মানে অ্যাপ্লিকেশন ব্যবহারকারীদের কাছে সেই আইডি প্রকাশ করা বোঝায় না।

— ডেভ শেরোহমান

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

— মাতাল কোড বানর

Answer 3

স্বতঃসংশ্লিষ্ট কীগুলির বেশিরভাগ সুবিধা রয়েছে।

তবে কিছু সম্ভাব্য ত্রুটিগুলি হ'ল:

• আপনার যদি ব্যবসায়ের কী থাকে তবে ব্যবসায়ের বিধি প্রয়োগ করার জন্য আপনাকে সেই কলামেও একটি অনন্য সূচি যুক্ত করতে হবে।
• দুটি ডাটাবেসের মধ্যে ডেটা স্থানান্তর করার সময়, বিশেষত যখন ডেটা একাধিক টেবিলের (যেমন মাস্টার / বিস্তারিত) থাকে তখন এটি সরাসরি-অগ্রসর হয় না কারণ ডাটাবেসগুলির মধ্যে ক্রমগুলি সিঙ্ক হয় না এবং আপনাকে প্রথমে একটি সমতা টেবিল তৈরি করতে হবে মূল ডেটাবেস থেকে কোন আইডি লক্ষ্য ডাটাবেসে কোন আইডিটির সাথে মিল রয়েছে তা জানতে মিল হিসাবে ব্যবসায়ের কী। যদিও বিচ্ছিন্ন টেবিলগুলিতে / থেকে ডেটা স্থানান্তর করার সময় কোনও সমস্যা হওয়া উচিত নয়।
• অনেক উদ্যোগের অ্যাড-হক, গ্রাফিকাল, পয়েন্ট-এ-ক্লিক, ড্রাগ-এন্ড ড্রপ রিপোর্টিং সরঞ্জাম রয়েছে। যেহেতু স্বতঃসংশোধক আইডি অর্থহীন, তাই এই ধরণের ব্যবহারকারীরা "অ্যাপ্লিকেশন" এর বাইরে থাকা ডেটা বোধ করতে অসুবিধে হবে।
• আপনি যদি দুর্ঘটনাক্রমে ব্যবসায় কীটি সংশোধন করেন তবে সম্ভাবনা হ'ল আপনি কখনই সেই সারিটি পুনরুদ্ধার করতে পারবেন না কারণ মানুষের কাছে এটি সনাক্ত করার মতো আর কিছু নেই। যা একবারে বিটকয়েন প্ল্যাটফর্মে ত্রুটি ঘটায় ।
• কিছু ডিজাইনার দুটি টেবিলের মধ্যে একটি জোড় টেবিলে একটি আইডি যুক্ত করেন, যখন পিকে কেবল দুটি বিদেশী আইডি সমন্বিত থাকে। স্পষ্টতই যদি যোগদানের টেবিলটি তিন বা ততোধিক টেবিলের মধ্যে থাকে তবে একটি স্বয়ংসোধমূলক আইডিটি বোঝায় তবে আপনি যখন বিধি বিধান প্রয়োগ করতে এফকে সংমিশ্রণে প্রয়োগ করেন তখন আপনাকে একটি অনন্য কী যুক্ত করতে হবে।

সুরোগেট কীগুলির অসুবিধাগুলি সম্পর্কে এখানে একটি উইকিপিডিয়া নিবন্ধ বিভাগ রয়েছে।

Comments

সরোগেট কীগুলিতে mt.gox ত্রুটি দোষারোপ করা সন্দেহজনক বলে মনে হচ্ছে। সমস্যাটি হ'ল তারা সমস্ত ক্ষেত্রগুলিকে তাদের যৌগিক কীতে, এমনকি পরিবর্তনীয় / ম্যালেবলযোগ্য ক্ষেত্রগুলিতে অন্তর্ভুক্ত করেছিল।

— কোডসইনচওস

অটো-ইনক্রিমেন্ট কীগুলি ব্যবহার করার একটি "সামাজিক" অসুবিধাটি হ'ল কখনও কখনও "ব্যবসায়" ধরে নেয় যে কোনও ব্যর্থতা থাকতে হবে না এবং একটি ব্যর্থ সন্নিবেশ ঘটলে (লেনদেনের রোলব্যাক) ঘটে গেলে যে নিখোঁজ সারিগুলি ঘটেছিল তার কী ঘটেছিল তা জানতে চাওয়া হবে না।

— রিক রাইকার

আরেকটি অসুবিধা হ'ল যদি সিস্টেমটি এত বড় হয়ে যায় যে আপনাকে ডাটাবেসটি তীক্ষ্ণ করতে হবে, আপনি আর বিশ্বব্যাপী অনন্য কী তৈরি করতে স্বতঃআগ্রহ ব্যবহার করতে পারবেন না। আপনি যখন এই বিন্দুতে পৌঁছবেন, তখন আপনার সেই ধারণার উপর নির্ভর করে প্রচুর কোড থাকতে পারে। একটি অনন্য শনাক্তকারী উত্পাদন করার অন্যান্য উপায় রয়েছে যা ডাটাবেসটি তীক্ষ্ণ করা হলে কাজ চালিয়ে যাবে।

— ক্যাস্পারড

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

— ক্যাস্পার্ড

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

— ক্যাস্পার্ড

Answer 4

ঠিক এর বিপরীতে, না, আপনার সর্বদা একটি সংখ্যার অটোইঙ্ক পিকে লাগবে না।

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

তবে এটির উদ্ভব, আপনার যদি ইতিমধ্যে কোনও অনন্য শনাক্তকারী থাকে তবে এটি ব্যবহার করুন। দ্বিতীয়, অর্থহীন প্রাথমিক কী তৈরি করবেন না; এটি অপব্যয় এবং ত্রুটি হতে পারে।

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

অপেক্ষাকৃত স্থিতিশীল মানগুলির মধ্যে যখন আপনার সংখ্যার সংখ্যা থাকে, তখন সিস্টেম ব্যবহারকারীর জন্য মূল্যবোধগুলি উপলব্ধি করে। এল, সি, এইচ যেখানে এল, এইচ এবং সি একটি বীমা "পলিসি টাইপ" প্রসঙ্গে জীবন, গাড়ি এবং বাড়ির প্রতিনিধিত্ব করেন বা ভিআইএন উদাহরণে ফিরে আসেন, কীভাবে "টো" ব্যবহার করবেন সে সম্পর্কে কেন আপনি 1,2,3 ব্যবহার করবেন? "টয়োটার জন্য? সমস্ত টয়োটা গাড়ীর একটি ভিআইএন রয়েছে যা "টু" শুরু করে ব্যবহারকারীদের মনে রাখা এটি একটি কম জিনিস, তাদের পক্ষে প্রোগ্রামিং এবং ব্যবহারকারীর ত্রুটিগুলি প্রবর্তন করার পক্ষে কম সম্ভাবনা তৈরি করে এবং এমনকি ম্যানেজমেন্ট রিপোর্টগুলিতে পুরো বিবরণের জন্য ব্যবহারিক সরোজেটও হতে পারে রিপোর্টগুলি সহজতর করে তোলে লিখতে এবং দ্রুত উত্পন্ন করতে।

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

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

অন্য একটি গুরুত্বপূর্ণ কেস সম্পাদনা করুন যেখানে আপনাকে অটোজেনারেটেড পিকে প্রয়োজন হয় না তা হ'ল টেবিলগুলির ক্ষেত্রে এটি অন্য দুটি টেবিলের ছেদকে প্রতিনিধিত্ব করে। গাড়ির সাদৃশ্যটি ধরে রাখতে, একটি গাড়িতে 0..n এক্সেসরি রয়েছে, প্রতিটি আনুষাঙ্গিক অনেক গাড়িতে পাওয়া যায়। সুতরাং এটি উপস্থাপন করার জন্য আপনি গাড়ী এবং অ্যাকসেসরি থেকে PKs এবং লিঙ্কের তারিখগুলি সম্পর্কিত অন্যান্য সম্পর্কিত তথ্য সম্বলিত একটি Car_Accessory সারণী তৈরি করেন

আপনার যা প্রয়োজন (সাধারণত) প্রয়োজন হয় না তা এই টেবিলের একটি অটোইঙ্ক পিকে - এটি কেবল গাড়ীর মাধ্যমে অ্যাক্সেস করা হবে "আমাকে এই গাড়িতে কী আনুষাঙ্গিক রয়েছে তা বলুন" বা অ্যাকসেসরি থেকে "গাড়িগুলিতে এই আনুষাঙ্গিকগুলি কী আছে তা বলুন"

Comments

> সমস্ত টয়োটা গাড়ির একটি ভিআইএন থাকে যা "TO" থেকে শুরু হয় এটি ঠিক সত্য নয়। তারা জাপানে তৈরি হলে "জেটি" দিয়ে শুরু করে। আমেরিকান-নির্মিত টয়োটাতে

— মন্টি হার্ডার

Don't create a second, meaningless primary key; it's wasteful and may cause errors.যাইহোক, আপনি যদি কোনও রেকর্ডের জন্য স্বতন্ত্রতা স্থাপন করেন তা 6 টি কলামের সংমিশ্রণ হয় তবে সমস্ত সময়ে সমস্ত সময়ে যোগদান করা নিজের পক্ষে খুব ত্রুটিযুক্ত। প্রাকৃতিকভাবে ডেটাতে একটি পিকে থাকে তবে আপনি id6 টি কলামে একটি কলাম এবং একটি অনন্য সীমাবদ্ধতা ব্যবহার করা ভাল ।

— ব্র্যাড

আমি স্বীকার করি যে এই পরামর্শগুলি আমার কাছে কিছুটা দূরে নিয়েছে। হ্যাঁ, বাস্তববাদী হওয়া ভাল, তবে কেউ তার প্রথমজাতের জীবনে কতবার শপথ করে বলেছিলেন যে ডোমেনের বাইরে থাকা কিছু বৈশিষ্ট্য বাকি দিনগুলিতে অনন্য থাকবে I ভাল, সাধারণত যেগুলি প্রথম ডুপ্লিকেটগুলি পরিণত হয়েছিল, সরাসরি লাইভ হওয়ার পরে দ্বিতীয় সপ্তাহ পর্যন্ত ভাল কাজ করেছিল। ;) পিকে হিসাবে "বিবরণ" ব্যবহার করা খুব দূরে।

— AnoE

@ মন্টি, আমার খারাপ, আপনি ঠিক বলেছেন। ভ্রমনযোগ্য স্মৃতি, আমি বহর ব্যবস্থাপনার সিস্টেমগুলি আর্কিটেকড করার 20 বছর পরে। কোনও ভিআইএন প্রাথমিক কী ছিল না :) আমি একটি অটোইঙ্ক সম্পদ_আইডি আইআইআরসি ব্যবহার করেছি যা কিছু ভুলে যাওয়ার দিকে নিয়ে যায়। যে টেবিলগুলি বহু-বহু সম্পর্কের জন্য লিংকার যেখানে আপনি যুক্ত হন, বলুন, গাড়ি থেকে আনুষাঙ্গিক (যেমন সানরূফ) অনেকগুলি গাড়ীর অনেকগুলি আনুষাঙ্গিক থাকে তাই আপনার একটি "কার_অ্যাকসেসরি" টেবিলের প্রয়োজন যেখানে Car_ID এবং অ্যাকসেসরি_আইডি রয়েছে তবে একেবারে Car_Accesory_ID এর দরকার নেই একটি স্বতঃসিঙ্ক পিকে।

— ম্যাকটল

এটি সত্যই আশ্চর্যজনক যে সেখানে কতগুলি প্রকৃত অপরিবর্তনীয় "প্রাকৃতিক কী" রয়েছে। এসএসএন এর? না, তারা পরিবর্তন করতে পারে। এটি বিরল, তবে এটি ঘটতে পারে। ব্যবহারকারীর নাম? নাঃ। অবশেষে কারও কাছে পরিবর্তনের একটি বৈধ ব্যবসায়ের কারণ থাকবে। ভিআইএন প্রায়শই একটি পাঠ্যপুস্তকের উদাহরণ, তবে অন্য অনেকগুলি নেই। এমনকি রাস্তার নামকরণের পরিবর্তে বাড়ির ঠিকানাগুলিও পরিবর্তিত হতে পারে।

— এরিক ফানকেনবাশ

Answer 5

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

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

Comments

আপনার যদি কেবলমাত্র "প্রাকৃতিক" আইডিগুলি প্রাথমিক কী হিসাবে ব্যবহার না করা হয় তবে সেগুলি কখনই পরিবর্তিত না হওয়ার নিশ্চয়তা থাকে? উদাহরণস্বরূপ, আপনার চালকের লাইসেন্স নম্বরটি প্রাথমিক কী হিসাবে ব্যবহার করা উচিত নয়, কারণ কোনও ব্যক্তি যদি নতুন চালকের লাইসেন্স পান তবে আপনাকে কেবলমাত্র সেই টেবিলটিই আপডেট করতে হবে না তবে বিদেশী চাবিযুক্ত কোনও টেবিলটি এটি উল্লেখ করতে হবে!

— একলিস

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

— ব্র্যাড টমাস

ঠিক আছে, আমার ধারণা আমি তখন প্রাকৃতিক আইডির সংজ্ঞাটি ভুল বুঝেছিলাম; আমি ভেবেছিলাম এটি কেবল ব্যবসায়ের নিয়ম দ্বারা সংজ্ঞায়িত একটি আইডি, এটি আসলে অপরিবর্তনীয় হওয়ার গ্যারান্টিযুক্ত কিনা whether

— একলিস

Answer 6

বৃহত্তর সিস্টেমে, আইডি দৃঢ়তা সহায়তাকারী, এটা ব্যবহার করেন প্রায় যে কোন জায়গায়। এই প্রসঙ্গে, পৃথক প্রাথমিক কীগুলি সুপারিশ করা হয় না, তারা নীচের লাইনে ব্যয়বহুল (কেন পড়ুন)।

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

এখানে অনেক উত্তর প্রস্তাব দেয় যে বিদ্যমান অনন্য কী নেওয়া উচিত। আচ্ছা এরও যদি দেড়শ অক্ষর থাকে? আমি তাই মনে করি না.

এখন আমার মূল বিষয়:

দেখে মনে হচ্ছে স্বতঃআগ্রহ পূর্ণসংখ্যার আইডি বিরোধী 20 টি সারণী সহ ছোট ডাটাবেসগুলির বিষয়ে কথা বলছেন। সেখানে তারা প্রতিটি টেবিলে স্বতন্ত্র পন্থা নিতে পারে।

তবে একবার আপনার 400+ টেবিল সহ একটি ইআরপি পরে, কোথাও পূর্ণসংখ্যার স্বয়ংসোধ আইডি থাকা (উপরে বর্ণিত মামলাগুলি ব্যতীত) কেবল দুর্দান্ত তা বোঝায়। আপনি অন্য অনন্য ক্ষেত্রগুলিতে নির্ভর করেন না এমনকি যদি তারা উপস্থিত থাকে এবং স্বতন্ত্রতার জন্য সুরক্ষিত থাকে।

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

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

Comments

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

— মাতাল কোড বানর

Answer 7

অতিমাত্রায় নকশাগুলি করা ভাল অনুশীলন নয়। অর্থাত্ - যখন কোনও প্রয়োজন হয় না তখন সর্বদা একটি স্বয়ংবৃদ্ধিপূর্ব প্রাথমিক কী রাখা ভাল অনুশীলন নয়।

আসুন একটি উদাহরণ দেখুন যেখানে একটির প্রয়োজন হয় না।

আপনার নিবন্ধগুলির জন্য একটি সারণী রয়েছে – idএটিতে একটি প্রাথমিক প্রাথমিক কী এবং নামযুক্ত একটি ভারচার কলাম রয়েছে title।

আপনার কাছে প্রবন্ধের বিভাগগুলি সহ পূর্ণ টেবিল রয়েছে have idপ্রাথমিক প্রাথমিক কী, বার্চর name।

নিবন্ধ সারণির এক সারিতে id5 টি রয়েছে এবং একটি title "মাখন দিয়ে গোস কীভাবে রান্না করা যায়"। আপনি এই বিভাগটি আপনার বিভাগের সারণিতে নিম্নলিখিত সারিগুলির সাথে যুক্ত করতে চান: "পাখি" ( আইডি : 20), "গুজ" ( আইডি : 12), "রান্না" ( আইডি : 2), "বাটার" (আইডি: 9) ।

এখন, আপনার কাছে দুটি টেবিল রয়েছে: নিবন্ধ এবং বিভাগগুলি। কীভাবে দুজনের মধ্যে সম্পর্ক তৈরি করবেন?

আপনার কাছে 3 টি কলাম সহ একটি টেবিল থাকতে পারে: আইডি (প্রাথমিক কী), নিবন্ধ_আইডি (বিদেশী কী), বিভাগ_আইডি (বিদেশী কী)। তবে এখন আপনার মতো কিছু রয়েছে:

| আইডি | a_id | সি_আইডি |
| 1 | 5 | 20 |
| 2 | 5 | 12 |
| 3 | 5 | 2 |

আরও ভাল সমাধানের মধ্যে একটি প্রাথমিক কী রয়েছে যা 2 টি কলাম দিয়ে তৈরি।

| a_id | সি_আইডি |
| 5 | 20 |
| 5 | 12 |
| 5 | 2 |

এটি করে সম্পাদন করা যেতে পারে:

create table articles_categories (
  article_id bigint,
  category_id bigint,
  primary key (article_id, category_id)
) engine=InnoDB;

একটি অটো ইনক্রিমেন্ট পূর্ণসংখ্যার ব্যবহার না করার আরেকটি কারণ হ'ল যদি আপনি আপনার প্রাথমিক কীটির জন্য ইউআইডি ব্যবহার করছেন।

ইউআইডিগুলি তাদের সংজ্ঞা অনুসারে অনন্য, যা অনন্য পূর্ণসংখ্যার ব্যবহারের মতো একই কাজ সম্পাদন করে। পূর্ণসংখ্যার তুলনায় তাদের নিজস্ব যুক্ত সুবিধা (এবং কনস) রয়েছে। উদাহরণস্বরূপ, একটি ইউইউডি সহ, আপনি জানেন যে অনন্য স্ট্রিং আপনি নির্দিষ্ট ডেটা রেকর্ডের দিকে নির্দেশ করছেন; আপনার ক্ষেত্রে 1 টি কেন্দ্রীয় ডাটাবেস নেই বা যেখানে অ্যাপ্লিকেশনগুলিতে অফলাইনে ডেটা রেকর্ড তৈরি করার ক্ষমতা রয়েছে সে ক্ষেত্রে এটি কার্যকর হয় (তারপরে পরবর্তী সময়ে এগুলি ডাটাবেসে আপলোড করুন)।

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

Answer 8

বা এমন কোনও দৃশ্য আছে যেখানে আপনি এই জাতীয় ক্ষেত্রটি যুক্ত করতে চান না?

অবশ্যই।

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

আরও গুরুত্বপূর্ণ বিষয়, কি আইডি আসলে আমার মনে হয় হয় - এটা আপনার ডেটার জন্য একটি প্রাথমিক চাবিকাঠি। আপনার যদি আলাদা আলাদা প্রাথমিক কী সহ একটি টেবিল থাকে, তবে আপনার কোনও আইডি লাগবে না এবং এটির একটিও থাকা উচিত নয়। উদাহরণস্বরূপ, একটি সারণীতে (EMPLOYEE_ID, TEAM_ID)(যেখানে প্রতিটি কর্মচারী একযোগে বেশ কয়েকটি দলে থাকতে পারে) সেই দুটি আইডি সমন্বিত একটি স্পষ্টভাবে সংজ্ঞায়িত প্রাথমিক কী রয়েছে। একটি স্বতঃসংশোধক IDকলাম যুক্ত করা, যা এই টেবিলের জন্য একটি প্রাথমিক কী এটি কোনও অর্থহীন নয়। এখন আপনি দুটি প্রাথমিক কী চারপাশে লগ করছেন এবং "প্রাথমিক কী" এর প্রথম শব্দটি আপনাকে একটি ইঙ্গিত দিতে হবে যা আপনার সত্যিই কেবল একটি থাকতে হবে।

Comments

(কোনও ওরাকল ব্যবহারকারী নয় তাই প্রশ্নটি ক্ষমা করুন) তবে কী ওরাکل সিকোয়েন্সকে অন্যরা স্বতঃআগ্রহ / পরিচয় ব্যবহার করে না? বলছেন যে ওরাকল একটি স্বতঃআগ্রহ ডেটা টাইপ নেই সত্যিই কেবল একটি sematic যুক্তি?

— ব্র্যাড

ঠিক আছে, এটি ছিল একটি ছোট পয়েন্ট; মূল অংশটি হ'ল চলমান আইডি প্রতিটি টেবিলের জন্য উপযুক্ত নয়, সুতরাং প্রতিটি টেবিলে কেবল একটি অটো-আইডি চাপড়ানোর অভ্যাস করা বুদ্ধিমানের কাজ নাও হতে পারে।

— আনোই

দুটি প্রাথমিক কী নেই, কেবল একটি প্রাথমিক কী রয়েছে এবং বাকিরা প্রার্থী কী হিসাবে ডাকা হয় যদি তারা প্রাথমিক কী হিসাবেও কাজ করতে পারে তবে ..

— রাহুল তায়াগি

Answer 9

আমি "দীর্ঘকালীন" ডেটা (নতুন রেকর্ডগুলি একবার সন্নিবেশ করানোর এবং অনির্দিষ্টকালের জন্য আশেপাশে রাখার প্রত্যাশা করি এমনকি যদি কিছুটা ক্ষেত্র সেট করে "যুক্তিযুক্তভাবে মুছে ফেলা" হয় তবে আমি অবশ্যই "পরিচয়" কলাম (স্বতঃবৃদ্ধিযোগ্য পূর্ণসংখ্যার) ব্যবহার করি )।

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

• যখন ইনক্রিমেন্টাল আইডিগুলি কোনও সম্ভাব্য আক্রমণকারীর জন্য খুব বেশি তথ্য হতে পারে। "জন-মুখোমুখি" ডেটা পরিষেবাদির জন্য একটি পরিচয় কলামের ব্যবহার আপনাকে "জার্মান ট্যাঙ্ক সমস্যা" এর জন্য দুর্বল করে তোলে; যদি রেকর্ড আইডি 10234 উপস্থিত থাকে তবে এটি রেকর্ড 10233, 10232 ইত্যাদির কারণ হিসাবে দাঁড়ায়, কমপক্ষে রেকর্ড 10001 এ ফিরে আসে এবং তারপরে আপনার পরিচয় কলামটি কোথায় শুরু হয়েছিল তা রেকর্ড 1001, 101 এবং 1 রেকর্ড করা সহজ। মূলত এলোমেলো তথ্যের সমন্বয়ে গঠিত ভি 4 জিইউইডগুলি ডিজাইন অনুসারে এই বর্ধিত আচরণকে ভেঙে দেয়, যাতে কেবল একজন জিআইডির উপস্থিতি থাকে, জিইউইডির বাইট বাড়ানো বা হ্রাস করে তৈরি করা একটি জিইউডির অস্তিত্বই থাকে না, আক্রমণকারীর পক্ষে পরিষেবাটি ব্যবহার করা শক্ততর করে তোলে ডাম্প সরঞ্জাম হিসাবে একক রেকর্ড পুনরুদ্ধারের জন্য। অন্যান্য সুরক্ষা ব্যবস্থা রয়েছে যা অ্যাক্সেসকে আরও ভালভাবে সীমাবদ্ধ করতে পারে তবে এটি সহায়তা করে।
• এম তে: এম ক্রস-রেফারেন্স সারণী। এটি এক ধরণের ধূর্ততা কিন্তু আমি এটি আগেও দেখেছি। আপনার ডাটাবেসে দুটি টেবিলের মধ্যে যদি আপনার একাধিক থেকে অনেকের সম্পর্ক থাকে তবে গো-টু সলিউশন হ'ল একটি ক্রস-রেফারেন্স টেবিল যা বিদেশি কী কলামগুলিতে প্রতিটি টেবিলের পিকে উল্লেখ করে containing অন্তর্নির্মিত সূচকের আচরণ পেতে এবং উল্লেখগুলির স্বতন্ত্রতা নিশ্চিত করার জন্য এই টেবিলটির পিকে কার্যত সবসময় দুটি বিদেশী কীগুলির একটি যৌগিক কী হওয়া উচিত।
• আপনি যখন এই টেবিলটিতে প্রচুর পরিমাণে সন্নিবেশ করা এবং মোছার পরিকল্পনা করছেন। সম্ভবত পরিচয় কলামগুলির সবচেয়ে বড় অসুবিধা হ'ল অন্য টেবিল বা কোয়েরি থেকে সারি সন্নিবেশ করানোর সময় আপনাকে যে অতিরিক্ত হুপলাটি করতে হবে, সেখানে আপনি মূল টেবিলের মূল মানগুলি বজায় রাখতে চান। আপনাকে "আইডেন্টিটি সন্নিবেশ" চালু করতে হবে (তবে এটি আপনার ডিবিএমএস-এ হয়ে গেছে), তারপরে ম্যানুয়ালি নিশ্চিত করুন যে আপনি কীগুলি সন্নিবেশ করিয়েছেন সেটি অনন্য এবং তারপরে আপনি যখন আমদানিটি সম্পন্ন করবেন তখন আপনাকে পরিচয় কাউন্টারে সেট করতে হবে সর্বাধিক মান উপস্থিত টেবিলের মেটাডেটা। যদি এই টেবিলটিতে এই অপারেশনটি অনেক কিছু ঘটে, তবে একটি আলাদা পিকে স্কিম বিবেচনা করুন।
• বিতরণ টেবিলের জন্য।পরিচয় কলামগুলি একক-উদাহরণস ডাটাবেস, ফেইলওভার পেয়ার এবং অন্যান্য পরিস্থিতিতে খুব ভাল কাজ করে যেখানে কোনও ডাটাবেস উদাহরণ কোনও নির্দিষ্ট সময়ে সম্পূর্ণ ডেটা স্কিমায় একমাত্র কর্তৃত্ব is যাইহোক, কেবলমাত্র এত বড় আপনি যেতে পারেন এবং এখনও একটি কম্পিউটার পর্যাপ্ত দ্রুত হতে পারে। প্রতিলিপি বা লেনদেনের লগ শিপিং আপনাকে অতিরিক্ত পঠনযোগ্য অনুলিপিগুলি পেতে পারে তবে সমাধানের স্কেলেরও সীমা রয়েছে। যত তাড়াতাড়ি বা পরে আপনার দুটি বা আরও সার্ভারের উদাহরণগুলির প্রয়োজন হবে ডেটার সন্নিবেশগুলি পরিচালনা করা এবং তারপরে একে অপরের সাথে সিঙ্ক্রোনাইজ করা। যখন পরিস্থিতি আসে, আপনি একটি বর্ধিত ক্ষেত্রের পরিবর্তে একটি জিইউইডি ফিল্ড চাইবেন, কারণ বেশিরভাগ ডিবিএমএস জিআইইডিগুলির একটি অংশকে উদাহরণ-নির্দিষ্ট সনাক্তকারী হিসাবে তৈরি করার জন্য প্রাক-কনফিগার করা হয়, তারপরে বাকী সনাক্তকারীকে এলোমেলোভাবে জেনারেট করুন বা ক্রমবর্ধমান। উভয় ক্ষেত্রে,
• যখন আপনাকে ডিবিতে একাধিক টেবিল জুড়ে স্বতন্ত্রতা প্রয়োগ করতে হবে।উদাহরণস্বরূপ, অ্যাকাউন্টিং সিস্টেমে জেনারেল লেজার পরিচালনা করা (প্রতিটি অ্যাকাউন্টের প্রতিটি ক্রেডিট বা ডেবিট যা কখনও ঘটেছিল তা পরিচালনা করে, সুতরাং এটি খুব তাড়াতাড়ি বড় হয়ে যায়) প্রতিটি সারণী অনুসারে প্রতিটি এক ক্যালেন্ডার মাসে প্রতিনিধিত্ব করে / বছর। এরপরে দেখার জন্য তাদের একসাথে দেখার জন্য তৈরি করা যেতে পারে। যৌক্তিকভাবে, এটি একটি খুব বড় টেবিল, তবে এটি কেটে ফেলা ডিবির রক্ষণাবেক্ষণ কাজ সহজ করে তোলে। তবে এটি কীভাবে একাধিক টেবিলগুলিতে সন্নিবেশগুলি পরিচালনা করতে পারে (কীভাবে নকল কীগুলি শেষ না করেই পরবর্তী মাসে আপনার লগ ইন লেনদেন শুরু করার অনুমতি দেয়) d আবার, সনাক্তকরণের পূর্ণসংখ্যার কলামগুলির পরিবর্তে জিইউইডিগুলি হ'ল সমাধানের সমাধান, কারণ ডিবিএমএস এগুলি সত্যই অনন্য উপায়ে তৈরি করার জন্য তৈরি করা হয়েছে,

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

Comments

ID, ID_M, ID_Nআপনার এম: এন সম্পর্কের উদাহরণগুলিতে বৈশিষ্ট্য সংযুক্ত করার কারণে আপনার এখনও এম: এন টেবিলগুলিতে (কলাম ব্যবহার করে ) আইডি লাগাতে পারে cases

— মিরোক্লাভ

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

— ভু

@ এমিরক্স্লাভ - আমি দৃ would়ভাবে বলব যে যদি কোনও টেবিলে সম্পর্কের বিষয়ে পর্যাপ্ত অতিরিক্ত মেটাডেটা থাকে যে দুটি এফকে-র বাইরে আলাদা আলাদা পিকে রাখা ভাল ধারণা, এটি আসলে কোনও ক্রস-রেফারেন্স টেবিল নয়; এটি তার নিজস্ব সত্তা যা অন্য দুজনকে রেফারেন্স করার জন্য ঘটে।

— কিথস

@ ভু - আপনি ঠিক বলেছেন, ভি 4 জিইউইডিগুলি ক্রিপ্টোগ্রাফিকভাবে এলোমেলোভাবে গ্যারান্টিযুক্ত নয়, কেবল অনন্য (সমস্ত জিইউইডি হ'ল)। যাইহোক, মার্কিন জেট যোদ্ধাদের টেল সংখ্যা ক্রিপ্টোগ্রাফিকভাবে এলোমেলো বীজ ডেটা / অ্যালগরিদম থেকে উত্পন্ন হয় না। আপনি যা খুঁজছেন তা হ'ল একটি অল্প-জনবহুল ডোমেন; একটি ভি 4 জিইউডির 112 বাইট র্যান্ডম ডেটা রয়েছে, 5e33 রেকর্ড স্বতন্ত্রভাবে সনাক্ত করতে সক্ষম।

— কিথস

দৃষ্টিভঙ্গি যে সংখ্যা করা, প্রতিটি মানুষের, নারী ও গ্রহে শিশু (7 বিলিয়ন) 741 হতে পারে ট্রিলিয়ন স্বতন্ত্রভাবে cataloged এবং আমাদের ডিবি ডাটা পয়েন্ট IDed, এবং যারা এখনও শুধুমাত্র প্রতি এক GUID মান ব্যবহার করা চাই বিলিয়ন পাওয়া যায়। বিগ ডেটা, বিশ্বব্যাপী শিল্প হিসাবে, জ্ঞানের এই স্কেলটির খুব কাছেও নেই। এমনকি জিইউইডি জেনারেশনকে একটি প্যাটার্ন দেওয়া হলেও, এনট্রপির অন্যান্য উত্সগুলিও জড়িত রয়েছে, যেমন ক্রমে ডেটা সিস্টেমে প্রবেশ করে এবং একটি জিইউইডি নির্ধারিত হয়।

— কিথস

Answer 10

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

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

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

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

Answer 11

যেহেতু অন্যান্য লোকেরা বর্ধিত প্রাথমিক কীটির জন্য মামলা করেছে আমি একটি জিইউইডির জন্য এটি করব:

• এটি অনন্য হওয়ার গ্যারান্টিযুক্ত
• আপনার অ্যাপ্লিকেশনটিতে ডেটার জন্য আপনার ডাটাবেসে আরও একটি ট্রিপ থাকতে পারে। (উদাহরণস্বরূপ কোনও ধরণের টেবিলের জন্য আপনি অ্যাপ্লিকেশনটিতে জিইউডিটি সঞ্চয় করতে পারেন এবং এটি রেকর্ডটি পুনরুদ্ধার করতে পারেন। এবং পরে সম্পূর্ণ বিশদ জানতে এটি আবার জিজ্ঞাসা করে)।
• এটি তথ্য গোপনের জন্য দরকারী। www.domain.com/Article/2 আমাকে জানতে দেয় আপনার কাছে কেবল দুটি নিবন্ধ রয়েছে তবে www.domain.com/article/b08a91c5-67fc-449f-8a50-ffdf2403444a আমাকে কিছুই বলেনি।
• আপনি সহজেই বিভিন্ন ডাটাবেস থেকে রেকর্ড একত্রিত করতে পারেন।
• এমএসএফটি পরিচয়ের জন্য জিইউইডিএস ব্যবহার করে।

সম্পাদনা: সদৃশ পয়েন্ট

Comments

-1। একটি জিইউইডি / ইউইউডি অনন্য হওয়ার গ্যারান্টিযুক্ত নয় এবং এটি 100% অনন্যও নয়। একটি জিইউডি এখনও সীমাবদ্ধ দৈর্ঘ্য, তাই কোনও সময়ে আপনি নকল পাওয়ার ঝুঁকি নিতে পারেন, যদিও এটি অত্যন্ত সম্ভাবনা নয়। ডাটাবেসটিতে কম ট্রিপ সম্পর্কে আপনার বক্তব্যটিও অবৈধ - আপনি জিআইইডি কী দিয়ে আপনি কেন প্রাথমিক অ্যাপ্লিকেশনটিতে প্রাথমিক আইডি সঞ্চয় করতে পারবেন না?

— নিক্লাস এইচ

জেফ অ্যাটউড এটি আমার চেয়ে অনেক ভাল বলেছিলেন। blog.codinghorror.com/primary-keys-ids-versus-guids

— তিনটি মান যুক্তি

কেন আপনি আপনার অ্যাপ্লিকেশনটিতে প্রাথমিক আইডি সঞ্চয় করতে পারবেন না? কারণ এটি ডাটাবেস তৈরি করে। আপনি যদি খালি ডেটাবেসে আপনার বীজ চালান তবে আপনি ধরে নিতে পারেন যে আইডিটি 1 হবে you আপনি যদি কোনও ডাটাবেজে একই স্ক্রিপ্টটিতে ডেটা সহ চালনা করেন তবে কী হবে? আইডিটি 1 হবে না

— তিনটি মান যুক্তি

আপনি অ্যাপ্লিকেশনটিতে আইডি তৈরির বিষয়ে কিছু বলেননি - আপনি কেবল "স্টোরিং" লিখেছেন। তবে যদি ডাটাবেসের বাইরে আইডি তৈরি করা প্রয়োজন হয়, তবে হ্যাঁ, একটি জিইউডি উত্তর হতে পারে।

— নিক্লাস এইচ

আমি তারা আরও ভাল স্কেল যোগ করা হবে। ক্যাসান্দ্রার মতো বড় ডেটা নোএসকিউএল ডেটাবেস এমনকি অটো-ইনক্রিমেন্ট কীগুলি সমর্থন করে না।

— কার্ল বিলেফেল্ড

Answer 12

ভাল ডিজাইনের নীতি হিসাবে, প্রতিটি টেবিলের অনন্যভাবে একটি সারি চিহ্নিত করার একটি নির্ভরযোগ্য উপায় থাকতে হবে have যদিও এটি একটি প্রাথমিক কী এর জন্য, তবে এটি সর্বদা প্রাথমিক কী এর অস্তিত্বের প্রয়োজন হয় না। প্রতিটি সারণীতে একটি প্রাথমিক কী যুক্ত করা কোনও অভ্যাস নয় কারণ এটি অনন্য সারি সনাক্তকরণের জন্য সরবরাহ করে তবে এটি অপ্রয়োজনীয় হতে পারে।

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

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

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

Answer 13

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

বিটিডাব্লু: আসুন আমরা সংজ্ঞায়িত এবং অনর্থক শব্দ প্রাথমিক কী ব্যবহার করা এড়ানো যাক । এটি প্রাক-সম্পর্কযুক্ত ডেটা মডেলগুলির একটি নিদর্শন যা প্রথমে রিলেশনাল মডেলটিতে কো-অপ্ট (অনর্থকভাবে) তৈরি হয়েছিল এবং তারপরে বিভিন্ন আরডিবিএমএস বিক্রেতারা ফিজিকাল ডোমেনটিতে ফিরে এসেছিলেন। এর ব্যবহার কেবল শব্দার্থকে বিভ্রান্ত করার জন্য কাজ করে।

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

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

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

মোট কথা, সমস্ত টেবিলের জন্য কোনও সারোগেট কী (কোনও প্রকারের) প্রয়োজন হবে না ; বিবেচনাধীন টেবিলের কার্য সম্পাদনের জন্য প্রয়োজনীয় বিবেচিত হলে এগুলি ব্যবহার করা উচিত। আপনি যে সাধারণ সরোগেট কী প্রযুক্তি পছন্দ করেন না কেন, কোনও পছন্দ করার আগে সারণীর প্রকৃত প্রয়োজনীয়তা সম্পর্কে সাবধানতার সাথে চিন্তা করুন; টেবিলের জন্য সার্গেট কী প্রযুক্তির পছন্দ পরিবর্তন করা ক্লান্তিকর কাজ হবে। আপনার টেবিলের জন্য মূল কার্য সম্পাদন মেট্রিক নথি করুন যাতে আপনার উত্তরসূরিরা করা পছন্দগুলি বুঝতে পারে।

বিশেষ ক্ষেত্রে

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

2. যদি আপনার টেবিলটি প্রায় একশো সারি এর বেশি না হয় তবে সূচকের উচ্চতা অপ্রাসঙ্গিক; প্রতিটি অ্যাক্সেস একটি টেবিল স্ক্যান দ্বারা হবে। তবে দীর্ঘ স্ট্রিংয়ের সাথে স্ট্রিং তুলনাগুলি 4-বাইট সংখ্যার পূর্ণসংখ্যার তুলনায় অনেক বেশি ব্যয়বহুল এবং জিইউডির তুলনায় বেশি ব্যয়বহুল হবে।

3. একটি চর (4) কোড ক্ষেত্র দ্বারা চিহ্নিত কোড মানগুলির একটি সারণী 4-বাইট পূর্ণসংখ্যা সহকারে পারফরম্যান্স হওয়া উচিত। যদিও আমার কাছে এর কোনও প্রমাণ নেই তবে আমি অনুমিতিটি ঘন ঘন ব্যবহার করি এবং কখনই এটির কারণ হওয়ার কারণ নেই।

Answer 14

কেবল এটিই ভাল অনুশীলন নয়, বাস্তবে এটিকে বিল কারভিনের এসকিউএল অ্যান্টিপ্যাটার্নস বইতে একটি অ্যান্টি-প্যাটার্ন হিসাবে বর্ণনা করা হয়েছে।

প্রতিটি টেবিলের জন্য ছদ্মোকির প্রয়োজন হয় না - একটি স্বেচ্ছাসেবী মান সহ একটি প্রাথমিক কী, এমন কোনও মডেলের জন্য অর্থ মূল্য নেই - এবং সর্বদা এটি কল করার কোনও কারণ নেই id।

Comments

এই কিছু সারগর্ভ প্রস্তাব উপর পয়েন্ট হয়েছে এবং পূর্বে 9 উত্তর ব্যাখ্যা বলে মনে হচ্ছে না

— মশা

এবং কেন এটি গুরুত্বপূর্ণ হতে পারে?

— gnat

@gnat কারণ এটি সর্বোত্তম অনুশীলনের উপর একটি বই, যা সরাসরি প্রশ্নটিকে সম্বোধন করে। এটা কি প্রকট নয়?

— পেড্রো ওয়ার্নেক

সামান্যতম না। "বুক SQL সর্বোত্তম কার্যাভ্যাস" এর জন্য Google অনুসন্ধান আমায় 900K সম্পর্কে সংযোগগুলি দেখায়, কেন এই এক বিশেষ করে যোগ্য হতে হবে

— মশা

@gnat আমি সারা দিন তর্ক করব না। আপনি উত্তরটি পছন্দ করেন না, এটিই ডাউনভোটস ot

— পেড্রো ওয়ার্নেক

Answer 15

এটি বেশ সর্বজনীন - অন্যথায় আপনাকে কীটি আসলে অনন্য বলে প্রমাণ করতে হবে। এটি অন্যান্য কীগুলি সমস্ত দেখে দেখে সম্পন্ন হবে ... যা সময় সাপেক্ষ হবে। আপনার রেকর্ড নম্বরটি কী ওভারফ্লো মানটি নিকটে আসায় একটি বর্ধিত কী থাকা ব্যয়বহুল হয়ে যায়।

আমি সাধারণত পয়েন্টারগুলিকে আরও সুস্পষ্ট ক্ষেত্রের নামগুলি পছন্দ করি ref_{table}বা অনুরূপ ধারণা করি।

যদি বাহ্যিকভাবে কোনও রেকর্ডে নির্দেশ করা প্রয়োজন না হয় তবে আপনার কোনও আইডি লাগবে না।

Comments

কী রোলওভারের মান?

— এজেজে

1 যোগ করার আগে একটি স্বাক্ষরযুক্ত পূর্ণসংখ্যার সর্বাধিক মান হয় 4294967295 এর মধ্যে 0 টি রোল হবে Remember মনে রাখবেন আপনি যদি কোনও রেকর্ড যোগ করেন তবে এটি মুছুন, কাউন্টারটি এখনও বাড়ানো হয়েছে। আপনি unsigned intক্ষেত্রের ধরণের জন্য নিশ্চিত হন তা নিশ্চিত করুন নইলে সীমাটি এই সংখ্যার অর্ধেক।

— জনি ভি

পূর্ণসংখ্যা ওভারফ্লো - en.wikedia.org/wiki/Integer_overflow

— জনি ভি

আপনি প্রচুর সারি যুক্ত / সরিয়ে ফেললে অটো ইনক্রিমেন্ট কাউন্টারটি শেষ পর্যন্ত উপচে পড়বে।

— জনি ভি

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

— এজেজে

Answer 16

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

Answer 17

প্রাথমিক কী এর জন্য একটি স্বয়ংবৃদ্ধি কাউন্টার ভাল ধারণা নয়। এটি কারণ আপনার ডাটা সন্নিবেশ করার আগে আপনার পরবর্তী কী এবং বর্ধিতকরণ অনুসন্ধান করতে ডাটাবেসে ফিরে যেতে হবে।

বলা হচ্ছে যে আমি সাধারণত ডাটাবেসটিকে অ্যাপ্লিকেশনটির অংশ হিসাবে রাখার পরিবর্তে প্রাথমিক কীটির জন্য যা সরবরাহ করতে পারি তা ব্যবহার করব।

আপনার জন্য ডাটাবেসটি স্থানীয়ভাবে এটি সরবরাহ করার মাধ্যমে এটি কী প্রয়োজন তা অনন্য হওয়ার গ্যারান্টি দিতে পারে।

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

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

Comments

না। স্বতঃবৃদ্ধি কীগুলির অর্থ কীটির বর্ধিতকরণ ডাটাবেস দ্বারা স্বয়ংক্রিয়ভাবে সম্পন্ন হয়। কখনও কখনও (আমি আপনাকে দেখছি, ওরাকল!) এটি করার জন্য আপনার সিকোয়েন্স + ট্রিগার সংমিশ্রণ প্রয়োজন , তবে আপনাকে কখনই কীটির পূর্বে সন্নিবেশ করা মানটি দেখার দরকার নেই, 1 যুক্ত করুন, তারপরে এটি ব্যবহার করুন।

— এসকিউবি

কিছু জেদী ফ্রেমওয়ার্ক যেমন জেপিএর সাথে আপনি যদি চাবিটির চাবিটির মান ফিরিয়ে দিতে চান তবে এটি কী দেখার জন্য রেকর্ডটি লোড করতে হবে।

— আর্কিমিডিজ ট্রাজানো