বর্ণনা

উপরের প্রতিটি কৌশল এবং কৌশলের নিজস্ব সুবিধা এবং অসুবিধা রয়েছে। একটি নির্দিষ্ট কৌশল বেছে নেওয়ার জন্য সাধারণ সুপারিশগুলি এইরকম দেখাবে:

UNION ভিত্তিক TABLE_PER_CLASS কৌশল

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

Java webinar

SINGLE_TABLE কৌশল

এই কৌশলটি ব্যবহার করা উচিত:

ক) শুধুমাত্র সাধারণ কাজের জন্য। এমন পরিস্থিতিতে যেখানে স্বাভাবিককরণ এবং শূন্য নয় সীমাবদ্ধতা গুরুত্বপূর্ণ, কৌশল #3 (যোগদান) পছন্দ করা উচিত। এই ক্ষেত্রে উত্তরাধিকারকে সম্পূর্ণরূপে পরিত্যাগ করা এবং প্রতিনিধিত্বের সাথে প্রতিস্থাপন করা উপযুক্ত নয় কিনা তা নিয়ে চিন্তা করা বোধগম্য।

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

এবং তার উপরে, আপনি DBA এর সাথে একটি গুরুতর কথোপকথন করেছেন।

যোগদান কৌশল

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

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

আলাদাভাবে, এটি বিবেচনায় নেওয়া উচিত যে উত্তরাধিকার টীকা ইন্টারফেসে প্রয়োগ করা যাবে না।

স্পষ্ট

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

এই জন্য একটি টীকা আছে:

@Polymorphism(type = PolymorphismType.EXPLICIT)

যদি আমরা এটিকে ক্লায়েন্ট ক্লাসে যুক্ত করি :

@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@Entity
class User {
  int id;
  String name;
  LocalDate birthday;
}
@Entity
class Employee extends User {
 	String occupation;
 	int salary;
 	LocalDate join;
}
@Entity
@Polymorphism(type = PolymorphismType.EXPLICIT)
class Client extends User {
   String address;
}

তারপর HQL ক্যোয়ারী বেস ক্লাসের প্রশ্ন করার সময় এই ক্লাসের বস্তুগুলিকে উপেক্ষা করবে:

List<User> accounts = session.createQuery("from User").getResultList();

এই ক্যোয়ারী ব্যবহারকারী এবং কর্মচারী বস্তুর একটি তালিকা প্রদান করবে , কিন্তু ক্লায়েন্ট নয় ।