క్రమానుగత సంరక్షణ వ్యూహాన్ని ఎంచుకోవడం

వివరణ

పైన పేర్కొన్న ప్రతి వ్యూహాలు మరియు సాంకేతికతలకు దాని స్వంత ప్రయోజనాలు మరియు అప్రయోజనాలు ఉన్నాయి. నిర్దిష్ట వ్యూహాన్ని ఎంచుకోవడానికి సాధారణ సిఫార్సులు ఇలా ఉంటాయి:

UNION ఆధారంగా TABLE_PER_CLASS వ్యూహం

పాలిమార్ఫిక్ ప్రశ్నలు మరియు అనుబంధాలు అవసరం లేకపోతే ఈ వ్యూహం ఉత్తమంగా ఎంచుకోబడుతుంది. మీరు అరుదుగా చేస్తే (లేదా అస్సలు చేయకపోతే) "వినియోగదారు వినియోగదారు నుండి వినియోగదారుని ఎంచుకోండి". మీకు వినియోగదారుని సూచించే ఎంటిటీ తరగతులు లేకుంటే, ఇది ఉత్తమ ఎంపిక (ఎందుకంటే మీరు ఇప్పటికీ ఆప్టిమైజ్ చేయబడిన పాలిమార్ఫిక్ ప్రశ్నలు మరియు అనుబంధాలను జోడించవచ్చు).

SINGLE_TABLE వ్యూహం

ఈ వ్యూహాన్ని ఉపయోగించాలి:

ఎ) సాధారణ పనులకు మాత్రమే. సాధారణీకరణ మరియు NOT NULL పరిమితి కీలకమైన పరిస్థితుల్లో, వ్యూహం #3 (JOINED)కి ప్రాధాన్యత ఇవ్వాలి. ఈ సందర్భంలో వారసత్వాన్ని పూర్తిగా వదిలివేయడం మరియు దానిని ప్రతినిధి బృందంతో భర్తీ చేయడం విలువైనది కాదా అని ఆలోచించడం అర్ధమే.

బి) పాలిమార్ఫిక్ ప్రశ్నలు మరియు అనుబంధాలు అవసరమైతే, అలాగే రన్ టైమ్‌లో కాంక్రీట్ క్లాస్ యొక్క డైనమిక్ నిర్వచనం. అదే సమయంలో, ఉపవర్గాలు సాపేక్షంగా కొన్ని కొత్త ఫీల్డ్‌లను ప్రకటిస్తాయి మరియు సూపర్‌క్లాస్‌తో ప్రధాన వ్యత్యాసం ప్రవర్తనలో ఉంటుంది.

మరియు దాని పైన, మీరు 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();

ఈ ప్రశ్న వినియోగదారు మరియు ఉద్యోగి వస్తువుల జాబితాను అందిస్తుంది , కానీ క్లయింట్ కాదు .