বলতে গেলে "Composite keys as PRIMARY KEY is bad practice"একেবারে বাজে!
যৌগিক PRIMARY KEYগুলি প্রায়শই খুব "ভাল জিনিস" এবং প্রতিদিনের জীবনে ঘটে যাওয়া প্রাকৃতিক পরিস্থিতিতে মডেল করার একমাত্র উপায়!
শিক্ষার্থী এবং কোর্সগুলির ক্লাসিক ডেটাবেসস -১১১ শিক্ষার উদাহরণ এবং অনেক শিক্ষার্থী নেওয়া বহু কোর্সের কথা চিন্তা করুন!
সারণী কোর্স এবং ছাত্র তৈরি করুন:
CREATE TABLE course
(
course_id SERIAL,
course_year SMALLINT NOT NULL,
course_name VARCHAR (100) NOT NULL,
CONSTRAINT course_pk PRIMARY KEY (course_id)
);
CREATE TABLE student
(
student_id SERIAL,
student_name VARCHAR (50),
CONSTRAINT student_pk PRIMARY KEY (student_id)
);
আমি পোস্টগ্রিজ এসকিউএল ডায়ালাইটে (এবং মাইএসকিউএল ) উদাহরণ দিচ্ছি - কিছুটা টুইট করে কোনও সার্ভারের জন্য কাজ করা উচিত।
এখন, আপনি স্পষ্টতই কোন শিক্ষার্থী কোন কোর্সটি নিচ্ছেন তা ট্র্যাক করে রাখতে চান - সুতরাং আপনার যা বলা হয় joining table(যাকে ডাকা হয় linking, many-to-manyবা m-to-nসারণীও বলা হয় )। তারা associative entitiesআরও প্রযুক্তিগত কলঙ্ক হিসাবে পরিচিত হয় !
1 কোর্সে অনেক শিক্ষার্থী থাকতে পারে ।
1 জন ছাত্র অনেক কোর্স নিতে পারে ।
সুতরাং, আপনি একটি যোগদানের টেবিল তৈরি করুন
CREATE TABLE course_student
(
cs_course_id INTEGER NOT NULL,
cs_student_id INTEGER NOT NULL,
-- now for FK constraints - have to ensure that the student
-- actually exists, ditto for the course.
CREATE CONSTRAINT cs_course_fk FOREIGN KEY (cs_course_id) REFERENCES course (course_id),
CREATE CONSTRAINT cs_student_fk FOREIGN KEY (cs_student_id) REFERENCES student (student_id)
);
এখন, এই টেবিলটিকে সংবেদনশীলভাবে দেওয়ার একমাত্র উপায় PRIMARY KEYহ'ল KEYএটি অবশ্যই কোর্স এবং শিক্ষার্থীর সংমিশ্রণ। এইভাবে, আপনি পাবেন না:
ছাত্র এবং কোর্সের সংমিশ্রণের একটি সদৃশ
আপনার KEYপ্রতি শিক্ষার্থী কোর্সে রেডিমেড সার্চও রয়েছে - একে একে একটি কভারিং ইনডেক্স ,
শিক্ষার্থী এবং শিক্ষার্থী নেই যে কোনও কোর্স নিচ্ছে না তাদের কোর্সগুলি খুঁজে পাওয়া তুচ্ছ!
- ডিবি-ফিডাল উদাহরণটিতে পিকে সীমাবদ্ধতা তৈরি করে টেবিল তৈরি করা হয়েছে - এটি যে কোনও উপায়ে করা যেতে পারে। আমি ক্রেট টেবিল বিবৃতিতে সবকিছুই পছন্দ করি।
ALTER TABLE course_student
ADD CONSTRAINT course_student_pk
PRIMARY KEY (cs_course_id, cs_student_id);
এখন, আপনি যদি খুঁজে পেয়েছিলেন যে শিক্ষার্থীদের জন্য অবশ্যই অনুসন্ধানগুলি ধীর গতিতে রয়েছে তবে একটি UNIQUE INDEX(sc_student_id, sc_course_id) ব্যবহার করুন।
ALTER TABLE course_student
ADD CONSTRAINT course_student_sc_uq
UNIQUE (cs_student_id, cs_course_id);
নেই কোন ইনডেক্স যোগ করার জন্য কবচ - তারা হবে করা INSERTs এবং UPDATEধীর গুলি কিন্তু অতিশয় মহান সুবিধার এ কমছেSELECT গুণ! বিকাশকারীদের তাদের জ্ঞান এবং অভিজ্ঞতা অনুসারে সূচী স্থির করার সিদ্ধান্ত নেওয়ার বিষয়, তবে এটি যৌক্তিক PRIMARY KEYগুলি সর্বদা খারাপ থাকে তা কেবল সাধারণ ভুল।
টেবিলগুলিতে যোগদানের ক্ষেত্রে, তারা সাধারণত একমাত্র PRIMARY KEY এটি বোঝায়! ব্যবসায় বা প্রকৃতি বা কার্যত প্রতিটি ক্ষেত্রে যা আমি ভাবতে পারি তার মধ্যে মডেলিংয়ের একমাত্র উপায়টিও টেবিলে যোগদানের জন্য খুব ঘন ঘন!
এই পিকে এছাড়াও covering indexঅনুসন্ধান হিসাবে গতিতে সহায়তা করতে পারে হিসাবে ব্যবহার করা হয় । এই ক্ষেত্রে, এটি বিশেষত কার্যকর হবে যদি কেউ নিয়মিতভাবে (কোর্স_আইডি, শিক্ষার্থী_আইডি) অনুসন্ধান করে যা একজন কল্পনাও করে যে এটি প্রায়শই ঘটতে পারে!
এটি একটি সামান্য উদাহরণ যেখানে একটি যৌগিক PRIMARY KEYখুব ভাল ধারণা হতে পারে, এবং বাস্তবতার মডেল করার একমাত্র বুদ্ধিমান উপায়! আমার মাথার উপরের অংশটি ছেড়ে, আমি আরও অনেক কিছুই ভাবতে পারি ।
আমার নিজের কাজ থেকে একটি উদাহরণ!
একটি ফ্লাইট_আইডযুক্ত একটি ফ্লাইট টেবিল, প্রস্থান এবং আগমন বিমানবন্দরগুলির তালিকা এবং প্রাসঙ্গিক সময়গুলি বিবেচনা করুন এবং তারপরে ক্রু সদস্যদের সাথে একটি কেবিন_ক্রু টেবিলও বিবেচনা করুন!
শুধুমাত্র বিবেকী এই অনুকরণে করা যেতে পারে flight_id এবং attibutes যেমন crew_id এবং শুধুমাত্র বিবেকী সঙ্গে একটি flight_crew টেবিল থাকতে হয় PRIMARY KEYদুই ক্ষেত্র যৌগিক কী ব্যবহার হয়!
