@Bill Karwin তার তিন উত্তরাধিকার মডেল বর্ণনা করে এসকিউএল Antipatterns বই, যখন SQL সমাধান প্রস্তাব সত্তা-বৈশিষ্ট্য-মূল্য antipattern। এটি একটি সংক্ষিপ্ত বিবরণ:
একক টেবিল উত্তরাধিকার (ওরফ টেবিল প্রতি অনুক্রমের উত্তরাধিকার):
আপনার প্রথম বিকল্প হিসাবে একটি একক টেবিল ব্যবহার করা সম্ভবত সবচেয়ে সহজ নকশা। যেমনটি আপনি উল্লেখ করেছেন, অনেকগুলি বৈশিষ্ট্য যা সাব টাইপ-নির্দিষ্ট রয়েছে তাদের NULLসারিগুলিতে একটি মান দিতে হবে যেখানে এই বৈশিষ্ট্যগুলি প্রয়োগ হয় না। এই মডেলটির সাথে আপনার একটি নীতি সারণী থাকবে যা দেখতে এরকম কিছু দেখাচ্ছে:
+------+---------------------+----------+----------------+------------------+
| id | date_issued | type | vehicle_reg_no | property_address |
+------+---------------------+----------+----------------+------------------+
| 1 | 2010-08-20 12:00:00 | MOTOR | 01-A-04004 | NULL |
| 2 | 2010-08-20 13:00:00 | MOTOR | 02-B-01010 | NULL |
| 3 | 2010-08-20 14:00:00 | PROPERTY | NULL | Oxford Street |
| 4 | 2010-08-20 15:00:00 | MOTOR | 03-C-02020 | NULL |
+------+---------------------+----------+----------------+------------------+
\------ COMMON FIELDS -------/ \----- SUBTYPE SPECIFIC FIELDS -----/
নকশাটিকে সহজ রাখা একটি প্লাস, তবে এই পদ্ধতির সাথে প্রধান সমস্যাগুলি নিম্নলিখিত:
যখন নতুন সাব টাইপ যুক্ত করার কথা আসে তখন আপনাকে এই নতুন অবজেক্টগুলিকে বর্ণনা করে এমন বৈশিষ্ট্যগুলি সমন্বিত করতে টেবিলটি পরিবর্তন করতে হবে। আপনার অনেকগুলি সাব টাইপ থাকে বা আপনি যদি নিয়মিত ভিত্তিতে সাব টাইপ যুক্ত করার পরিকল্পনা করেন তবে এটি দ্রুত সমস্যাযুক্ত হয়ে উঠতে পারে।
ডাটাবেসটি প্রয়োগ করতে সক্ষম হবে না কোন বৈশিষ্ট্যগুলি প্রয়োগ হয় এবং কোনটি প্রয়োগ হয় না, কারণ কোন উপ-প্রকারের সাথে সম্পর্কিত কোন বৈশিষ্ট্য নির্ধারণ করার জন্য কোনও মেটাডেটা নেই।
NOT NULLবাধ্যতামূলক হওয়া উচিত এমন একটি উপ-টাইপের বৈশিষ্ট্যগুলিও আপনি প্রয়োগ করতে পারবেন না । আপনাকে আপনার অ্যাপ্লিকেশনটিতে এটি পরিচালনা করতে হবে, যা সাধারণভাবে আদর্শ নয়।
কংক্রিট টেবিল উত্তরাধিকার:
উত্তরাধিকার মোকাবেলার জন্য আরেকটি পদ্ধতি হ'ল প্রতিটি উপ-টাইপের জন্য একটি নতুন টেবিল তৈরি করা, প্রতিটি টেবিলের সমস্ত সাধারণ বৈশিষ্ট্য পুনরাবৃত্তি করে। উদাহরণ স্বরূপ:
--// Table: policies_motor
+------+---------------------+----------------+
| id | date_issued | vehicle_reg_no |
+------+---------------------+----------------+
| 1 | 2010-08-20 12:00:00 | 01-A-04004 |
| 2 | 2010-08-20 13:00:00 | 02-B-01010 |
| 3 | 2010-08-20 15:00:00 | 03-C-02020 |
+------+---------------------+----------------+
--// Table: policies_property
+------+---------------------+------------------+
| id | date_issued | property_address |
+------+---------------------+------------------+
| 1 | 2010-08-20 14:00:00 | Oxford Street |
+------+---------------------+------------------+
এই নকশাটি মূলত একক টেবিল পদ্ধতির জন্য চিহ্নিত সমস্যাগুলি সমাধান করবে:
বাধ্যতামূলক বৈশিষ্ট্যগুলি এখন প্রয়োগ করা যেতে পারে NOT NULL।
একটি নতুন সাব টাইপ যুক্ত করতে একটি বিদ্যমান কলামে কলাম যুক্ত করার পরিবর্তে একটি নতুন টেবিল যুক্ত করা দরকার।
কোনও নির্দিষ্ট উপ-টাইপের জন্য যেমন vehicle_reg_noকোনও সম্পত্তি নীতিমালার ক্ষেত্রের জন্য অনুপযুক্ত বৈশিষ্ট্য সেট করা আছে এমন কোনও ঝুঁকিও নেই ।
typeএকক টেবিল পদ্ধতির মতো অ্যাট্রিবিউটের প্রয়োজন নেই । টাইপটি এখন মেটাডেটা দ্বারা সংজ্ঞায়িত করা হয়েছে: টেবিলের নাম।
তবে এই মডেলটি কয়েকটি অসুবিধা নিয়ে আসে:
সাধারণ বৈশিষ্ট্যগুলি উপ-টাইপ নির্দিষ্ট বৈশিষ্ট্যগুলির সাথে মিশ্রিত হয় এবং তাদের সনাক্ত করার কোনও সহজ উপায় নেই। ডাটাবেসটিও জানবে না।
সারণীগুলি সংজ্ঞায়িত করার সময়, আপনাকে প্রতিটি উপ-টাইপ সারণির জন্য সাধারণ বৈশিষ্ট্যগুলি পুনরাবৃত্তি করতে হবে। এটি অবশ্যই DRY নয় ।
সাব-টাইপ নির্বিশেষে সমস্ত নীতি অনুসন্ধান করা কঠিন হয়ে পড়ে এবং UNIONএর জন্য একগুচ্ছ এস।
প্রকার নির্বিশেষে আপনাকে সমস্ত নীতি সম্পর্কে জিজ্ঞাসা করতে হবে:
SELECT date_issued, other_common_fields, 'MOTOR' AS type
FROM policies_motor
UNION ALL
SELECT date_issued, other_common_fields, 'PROPERTY' AS type
FROM policies_property;
নোট করে কীভাবে নতুন সাব টাইপ যুক্ত করতে UNION ALLপ্রতিটি উপ টাইপের জন্য অতিরিক্ত দিয়ে উপরের ক্যোয়ারীটি সংশোধন করা দরকার । যদি এই অপারেশনটি ভুলে যায় তবে এটি সহজেই আপনার অ্যাপ্লিকেশনে বাগগুলি নিয়ে যেতে পারে।
ক্লাস টেবিল উত্তরাধিকার (ওরফে টেবিল প্রতি টাইপ উত্তরাধিকার):
এই সমাধানটি @ ডেভিড অন্য উত্তরে উল্লেখ করেছেন । আপনি আপনার বেস শ্রেণীর জন্য একটি একক সারণী তৈরি করেন, এতে সমস্ত সাধারণ বৈশিষ্ট্য অন্তর্ভুক্ত থাকে। তারপরে আপনি প্রতিটি উপ টাইপের জন্য নির্দিষ্ট সারণী তৈরি করবেন, যার প্রাথমিক কীটি বেস টেবিলের জন্য একটি বিদেশী কী হিসাবে কাজ করে । উদাহরণ:
CREATE TABLE policies (
policy_id int,
date_issued datetime,
-- // other common attributes ...
);
CREATE TABLE policy_motor (
policy_id int,
vehicle_reg_no varchar(20),
-- // other attributes specific to motor insurance ...
FOREIGN KEY (policy_id) REFERENCES policies (policy_id)
);
CREATE TABLE policy_property (
policy_id int,
property_address varchar(20),
-- // other attributes specific to property insurance ...
FOREIGN KEY (policy_id) REFERENCES policies (policy_id)
);
এই সমাধানটি অন্য দুটি ডিজাইনে চিহ্নিত সমস্যাগুলি সমাধান করে:
বাধ্যতামূলক বৈশিষ্ট্য প্রয়োগ করা যেতে পারে NOT NULL।
একটি নতুন সাব টাইপ যুক্ত করতে একটি বিদ্যমান কলামে কলাম যুক্ত করার পরিবর্তে একটি নতুন টেবিল যুক্ত করা দরকার।
কোনও বিশেষ উপপ্রকারের জন্য অনুপযুক্ত বৈশিষ্ট্য সেট করা হওয়ার ঝুঁকি নেই।
গুণকের প্রয়োজন নেই type।
এখন সাধারণ বৈশিষ্ট্যগুলি সাব-টাইপ নির্দিষ্ট বৈশিষ্ট্যগুলির সাথে আর মিশ্রিত হয় না।
আমরা শেষ পর্যন্ত DRY থাকতে পারি। টেবিলগুলি তৈরি করার সময় প্রতিটি উপ-টাইপ টেবিলের জন্য সাধারণ বৈশিষ্ট্যগুলি পুনরাবৃত্তি করার দরকার নেই।
idনীতিগুলির জন্য একটি অটো ইনক্রিমেন্টিং পরিচালনা করা সহজ হয়ে যায়, কারণ এটি প্রতিটি উপ-টাইপ টেবিলের পরিবর্তে স্বতন্ত্রভাবে উত্পাদনের পরিবর্তে বেস টেবিল দ্বারা পরিচালনা করা যায়।
সাব-টাইপ নির্বিশেষে সমস্ত নীতি অনুসন্ধান করা এখন খুব সহজ হয়ে যায়: UNIONদরকার নেই - কেবল একটি SELECT * FROM policies।
আমি ক্লাস টেবিল পদ্ধতির বেশিরভাগ পরিস্থিতিতে সবচেয়ে উপযুক্ত হিসাবে বিবেচনা করি।
এই তিনটি মডেলের নাম এসেছে মার্টিন ফাউলারের বই প্যাটার্নস অফ এন্টারপ্রাইজ অ্যাপ্লিকেশন আর্কিটেকচার থেকে ।