ஒரு படிநிலை பாதுகாப்பு உத்தியைத் தேர்ந்தெடுப்பது

விளக்கம்

மேலே உள்ள உத்திகள் மற்றும் நுட்பங்கள் ஒவ்வொன்றும் அதன் சொந்த நன்மைகள் மற்றும் தீமைகள் உள்ளன. ஒரு குறிப்பிட்ட மூலோபாயத்தைத் தேர்ந்தெடுப்பதற்கான பொதுவான பரிந்துரைகள் இப்படி இருக்கும்:

UNION அடிப்படையில் TABLE_PER_CLASS உத்தி

பாலிமார்பிக் வினவல்கள் மற்றும் தொடர்புகள் தேவையில்லை என்றால் இந்த உத்தி சிறப்பாக தேர்ந்தெடுக்கப்படுகிறது. நீங்கள் அரிதாகச் செய்தால் (அல்லது செய்யவே இல்லை) "பயனர் பயனரிடமிருந்து பயனரைத் தேர்ந்தெடுக்கவும்". பயனரைக் குறிக்கும் நிறுவன வகுப்புகள் உங்களிடம் இல்லையென்றால், இதுவே சிறந்த வழி (ஏனெனில் நீங்கள் இன்னும் மேம்படுத்தப்பட்ட பாலிமார்பிக் வினவல்கள் மற்றும் சங்கங்களைச் சேர்க்கலாம்).

SINGLE_TABLE உத்தி

இந்த மூலோபாயம் பயன்படுத்தப்பட வேண்டும்:

அ) எளிய பணிகளுக்கு மட்டும். இயல்பாக்கம் மற்றும் NOT NULL கட்டுப்பாடு ஆகியவை முக்கியமானதாக இருக்கும் சூழ்நிலைகளில், உத்தி #3 (JOINED) விரும்பப்பட வேண்டும். இந்த விஷயத்தில் பரம்பரையை முற்றிலுமாக கைவிட்டு அதை பிரதிநிதித்துவத்துடன் மாற்றுவது மதிப்புக்குரியதா என்பதைப் பற்றி சிந்திப்பது அர்த்தமுள்ளதாக இருக்கிறது.

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();

இந்த வினவல் பயனர் மற்றும் பணியாளர் பொருள்களின் பட்டியலை வழங்கும் , ஆனால் கிளையண்ட் அல்ல .