முதலில் உண்மை, அல்லது கணினி ஏன் தரவுத்தள சாதனத்தின் அடிப்படையில் வடிவமைக்கப்பட வேண்டும்

ஹே ஹப்ர்!

நாங்கள் தலைப்பை தொடர்ந்து ஆராய்வோம் ஜாவா и வசந்ததரவுத்தள மட்டத்தில் உட்பட. பெரிய பயன்பாடுகளை வடிவமைக்கும்போது, ​​தரவுத்தள அமைப்பு ஏன், ஜாவா குறியீடு அல்ல, தீர்க்கமான முக்கியத்துவம் வாய்ந்ததாக இருக்க வேண்டும், இது எவ்வாறு செய்யப்படுகிறது, இந்த விதிக்கு விதிவிலக்குகள் என்ன என்பதைப் பற்றி இன்று படிக்கிறோம்.

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

என்ற அடிப்படையில் கட்டுரை எழுதப்பட்டது ஒரு கேள்வி, ஸ்டாக் ஓவர்ஃப்ளோவில் கொடுக்கப்பட்டுள்ளது.

பிரிவுகளில் reddit பற்றிய சுவாரஸ்யமான விவாதங்கள் /ஆர்/ஜாவா и /ஆர்/நிரலாக்கம்.

குறியீடு உருவாக்கம்

JOOQ உடன் பழகிய பிறகு, jOOQ இயங்குவதற்கு மூலக் குறியீட்டை உருவாக்குவதைத் தீவிரமாக நம்பியிருப்பதால் வெறுப்படைந்த பயனர்களின் சிறிய அடுக்கு இருப்பது எனக்கு எவ்வளவு ஆச்சரியமாக இருக்கிறது. நீங்கள் பொருத்தமாக இருக்கும் விதத்தில் jOOQ ஐப் பயன்படுத்துவதை யாரும் தடுக்கவில்லை, மேலும் குறியீடு உருவாக்கத்தைப் பயன்படுத்த யாரும் உங்களை கட்டாயப்படுத்தவில்லை. ஆனால் முன்னிருப்பாக (கையேட்டில் விவரிக்கப்பட்டுள்ளபடி), jOOQ இப்படிச் செயல்படுகிறது: நீங்கள் (மரபு) தரவுத்தளத் திட்டத்துடன் தொடங்கி, jOOQ குறியீடு ஜெனரேட்டரைக் கொண்டு உங்கள் அட்டவணையைப் பிரதிநிதித்துவப்படுத்தும் வகுப்புகளின் தொகுப்பைப் பெற, அதைத் தலைகீழாகப் பொறித்து, பின்னர் தட்டச்சு எழுதவும். இந்த அட்டவணைகளுக்கு எதிரான பாதுகாப்பான வினவல்கள்:

	for (Record2<String, String> record : DSL.using(configuration)
//   ^^^^^^^^^^^^^^^^^^^^^^^ Информация о типах выведена на 
//   основании сгенерированного кода, на который ссылается приведенное
// ниже условие SELECT 
 
       .select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
//           vvvvv ^^^^^^^^^^^^  ^^^^^^^^^^^^^^^ сгенерированные имена
       .from(ACTOR)
       .orderBy(1, 2)) {
    // ...
}

குறியீடு உருவாக்கத்திற்கு வெளியே கைமுறையாக அல்லது ஒவ்வொரு கட்டமைப்பிலும் கைமுறையாக உருவாக்கப்படுகிறது. உதாரணமாக, அத்தகைய மீளுருவாக்கம் உடனடியாகத் தொடரலாம் ஃப்ளைவே தரவுத்தள இடம்பெயர்வு, இது கைமுறையாக அல்லது தானாகவே செய்யப்படலாம்.

மூல குறியீடு உருவாக்கம்

குறியீடு உருவாக்கத்திற்கான இந்த அணுகுமுறைகளுடன் தொடர்புடைய பல்வேறு தத்துவங்கள், நன்மைகள் மற்றும் தீமைகள் உள்ளன - கையேடு மற்றும் தானியங்கி - இந்த கட்டுரையில் நான் விரிவாக விவாதிக்கப் போவதில்லை. ஆனால், பொதுவாக, உருவாக்கப்பட்ட குறியீட்டின் முழு அம்சம் என்னவென்றால், எங்கள் கணினியில் அல்லது அதற்கு வெளியே நாம் எடுத்துக் கொள்ளும் "உண்மையை" ஜாவாவில் மீண்டும் உருவாக்க அனுமதிக்கிறது. ஒரு வகையில், மூலக் குறியீட்டிலிருந்து பைட்கோட், மெஷின் குறியீடு அல்லது வேறு சில வகையான குறியீட்டை உருவாக்கும் கம்பைலர்கள் அதையே செய்கின்றன - குறிப்பிட்ட காரணங்களைப் பொருட்படுத்தாமல், வேறொரு மொழியில் நமது "உண்மையின்" பிரதிநிதித்துவத்தைப் பெறுகிறோம்.

இதுபோன்ற பல குறியீடு ஜெனரேட்டர்கள் உள்ளன. உதாரணத்திற்கு, XJC XSD அல்லது WSDL கோப்புகளின் அடிப்படையில் ஜாவா குறியீட்டை உருவாக்க முடியும். கொள்கை எப்போதும் ஒன்றுதான்:

• சில உண்மை உள்ளது (உள் அல்லது வெளி) - எடுத்துக்காட்டாக, ஒரு விவரக்குறிப்பு, ஒரு தரவு மாதிரி போன்றவை.
• எங்கள் நிரலாக்க மொழியில் இந்த உண்மையை உள்ளூர் பிரதிநிதித்துவம் செய்ய வேண்டும்.

மேலும், அத்தகைய பிரதிநிதித்துவத்தை உருவாக்குவது எப்போதும் அறிவுறுத்தப்படுகிறது - பணிநீக்கத்தைத் தவிர்ப்பதற்காக.

வகை வழங்குநர்கள் மற்றும் சிறுகுறிப்பு செயலாக்கம்

குறிப்பு: jOOQ க்கான குறியீடு உருவாக்கத்திற்கான மற்றொரு, மிகவும் நவீனமான மற்றும் குறிப்பிட்ட அணுகுமுறை வகை வழங்குநர்களின் பயன்பாட்டை உள்ளடக்கியது, அவை F# இல் செயல்படுத்தப்படுவதால். இந்த வழக்கில், குறியீடு தொகுப்பாளரால் உருவாக்கப்படுகிறது, உண்மையில் தொகுத்தல் கட்டத்தில். கொள்கையளவில், அத்தகைய குறியீடு மூல குறியீடுகளின் வடிவத்தில் இல்லை. ஜாவாவில், இதே போன்ற, நேர்த்தியாக இல்லாவிட்டாலும், கருவிகள் உள்ளன - இவை சிறுகுறிப்பு செயலிகள், எடுத்துக்காட்டாக, லாம்பாக்.

ஒரு குறிப்பிட்ட அர்த்தத்தில், முதல் விஷயத்தைப் போலவே இங்கேயும் நடக்கிறது, தவிர:

• உருவாக்கப்பட்ட குறியீட்டை நீங்கள் காணவில்லை (ஒருவேளை இந்த சூழ்நிலை ஒருவருக்கு மிகவும் வெறுப்பாகத் தோன்றவில்லையா?)
• வகைகளை வழங்க முடியும் என்பதை உறுதிப்படுத்த வேண்டும், அதாவது "உண்மை" எப்போதும் இருக்க வேண்டும். லோம்போக் விஷயத்தில் இது எளிதானது, இது "உண்மை" என்று குறிப்பிடுகிறது. எப்பொழுதும் கிடைக்கும் நேரடி இணைப்பைச் சார்ந்திருக்கும் தரவுத்தள மாதிரிகளில் இது இன்னும் கொஞ்சம் கடினமானது.

குறியீடு உருவாக்கத்தில் என்ன பிரச்சனை?

கைமுறையாக அல்லது தானாக குறியீடு உருவாக்கத்தை எவ்வாறு தொடங்குவது நல்லது என்ற தந்திரமான கேள்விக்கு கூடுதலாக, குறியீடு உருவாக்கம் தேவையில்லை என்று நம்புபவர்களும் உள்ளனர் என்பதை நான் குறிப்பிட வேண்டும். நான் அடிக்கடி பார்த்த இந்தக் கண்ணோட்டத்திற்கான நியாயம் என்னவென்றால், பைப்லைனை அமைப்பது கடினம். ஆம், இது மிகவும் கடினம். கூடுதல் உள்கட்டமைப்பு செலவுகள் உள்ளன. நீங்கள் ஒரு குறிப்பிட்ட தயாரிப்புடன் (அது jOOQ, அல்லது JAXB, அல்லது Hibernate, முதலியன) தொடங்கினால், அதன் மதிப்பைப் பெற API ஐக் கற்றுக்கொள்வதில் நீங்கள் செலவிட விரும்பும் ஒரு பணிப்பெட்டியை அமைக்க நேரம் எடுக்கும். .

ஜெனரேட்டரின் சாதனத்தைப் புரிந்துகொள்வதில் தொடர்புடைய செலவுகள் மிக அதிகமாக இருந்தால், உண்மையில், ஏபிஐ குறியீடு ஜெனரேட்டரின் பயன்பாட்டினை மோசமாகச் செய்தது (எதிர்காலத்தில் அதில் தனிப்பயனாக்கலும் கடினம் என்று மாறிவிடும்). அத்தகைய எந்த API க்கும் உபயோகம் மிக உயர்ந்த முன்னுரிமையாக இருக்க வேண்டும். ஆனால் இது குறியீடு உருவாக்கத்திற்கு எதிரான ஒரு வாதம். இல்லையெனில், உள் அல்லது வெளிப்புற உண்மையின் உள்ளூர் பிரதிநிதித்துவத்தை முழுவதுமாக கையால் எழுதுங்கள்.

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

அசல், ஆலன் ஓ'ரூர்க், ஆடியன்ஸ் ஸ்டேக்

ஆனால் ஹைபர்னேட் / ஜேபிஏவில் "ஜாவாவில்" குறியீட்டை எழுதுவது மிகவும் எளிதானது.

உண்மையில். ஹைபர்னேட் மற்றும் அதன் பயனர்களுக்கு, இது ஒரு வரம் மற்றும் சாபம். Hibernate இல், நீங்கள் இரண்டு நிறுவனங்களை எழுதலாம், இது போன்றது:

	@Entity
class Book {
  @Id
  int id;
  String title;
}

மற்றும் கிட்டத்தட்ட எல்லாம் தயாராக உள்ளது. SQL இன் "மொழியின்" DDL இல் இந்த உட்பொருளானது எவ்வாறு சரியாக வரையறுக்கப்படும் என்பதற்கான சிக்கலான "விவரங்களை" உருவாக்குவதே இப்போது ஹைபர்னேட்டின் முக்கிய அம்சமாகும்:

	CREATE TABLE book (
  id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
  title VARCHAR(50),
 
  CONSTRAINT pk_book PRIMARY KEY (id)
);
 
CREATE INDEX i_book_title ON book (title);

... மற்றும் பயன்பாட்டை இயக்கத் தொடங்குங்கள். விரைவாக எழுந்து இயங்குவதற்கும் வெவ்வேறு விஷயங்களை முயற்சிப்பதற்கும் மிகவும் அருமையான அம்சம்.

இருப்பினும், என்னை விடுங்கள். நான் பொய் கூறினேன்.

• இந்த பெயரிடப்பட்ட முதன்மை விசையின் வரையறையை ஹைபர்னேட் உண்மையில் செயல்படுத்துமா?
• TITLE இல் Hibernate ஒரு குறியீட்டை உருவாக்குமா? எங்களுக்கு அது தேவை என்று எனக்குத் தெரியும்.
• ஹைபர்னேட் இந்த விசையை அடையாள விவரக்குறிப்பில் அடையாள விசையாக மாற்றுமா?

அநேகமாக இல்லை. உங்கள் திட்டத்தை புதிதாக உருவாக்கினால், பழைய தரவுத்தளத்தை நிராகரித்து, தேவையான சிறுகுறிப்புகளைச் சேர்த்தவுடன் புதியதை உருவாக்குவது எப்போதும் வசதியானது. எனவே, புத்தக நிறுவனம் இறுதியில் படிவத்தை எடுக்கும்:

	@Entity
@Table(name = "book", indexes = {
  @Index(name = "i_book_title", columnList = "title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
  String title;
}

குளிர். மீண்டும் உருவாக்கு. மீண்டும், இந்த விஷயத்தில், இது ஆரம்பத்தில் மிகவும் எளிதாக இருக்கும்.

ஆனால் அதற்குப் பிறகு நீங்கள் பணம் செலுத்த வேண்டும்.

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

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

இனிமேலாவது நீங்கள் எழுத வேண்டும் DDL இடம்பெயர்வு ஸ்கிரிப்டுகள், எ.கா. ஃப்ளைவேயைப் பயன்படுத்துதல். இந்த விஷயத்தில் உங்கள் நிறுவனங்களுக்கு என்ன நடக்கும்? நீங்கள் அவற்றை கைமுறையாக மாற்றியமைக்கலாம் (மற்றும் உங்கள் பணிச்சுமையை இரட்டிப்பாக்கலாம்) அல்லது அவற்றை உங்களுக்காக ஹைபர்னேட் மீண்டும் உருவாக்கலாம் (உங்கள் எதிர்பார்ப்புகளை பூர்த்தி செய்யும் வகையில் இந்த வழியில் உருவாக்கப்படுவது எவ்வளவு சாத்தியம்?) நீங்கள் எந்த வழியிலும் இழக்கிறீர்கள்.

எனவே, நீங்கள் உற்பத்திக்குச் சென்றவுடன், உங்களுக்கு சூடான இணைப்புகள் தேவைப்படும். மேலும் அவை மிக விரைவாக உற்பத்திக்கு கொண்டு வரப்பட வேண்டும். உற்பத்திக்கான உங்கள் இடம்பெயர்வுகளை நீங்கள் தயார் செய்து ஒழுங்கமைக்காததால், நீங்கள் பெருமளவில் இணைக்கப்படுகிறீர்கள். பின்னர் எல்லாவற்றையும் சரியாகச் செய்ய உங்களுக்கு நேரம் இல்லை. நீங்கள் ஹைபர்னேட்டை திட்டுகிறீர்கள், ஏனென்றால் அது எப்போதும் யாருடைய தவறு, ஆனால் நீங்கள் அல்ல ...

மாறாக, ஆரம்பத்திலிருந்தே, எல்லாவற்றையும் முற்றிலும் வித்தியாசமாகச் செய்திருக்கலாம். உதாரணமாக, ஒரு சைக்கிளில் சுற்று சக்கரங்களை வைக்கவும்.

முதலில் தரவுத்தளம்

உங்கள் தரவுத்தள திட்டத்தில் உள்ள உண்மையான "உண்மை" மற்றும் அதன் மீதான "இறையாண்மை" தரவுத்தளத்தில் உள்ளது. ஸ்கீமா தரவுத்தளத்தில் மட்டுமே வரையறுக்கப்பட்டுள்ளது, வேறு எங்கும் இல்லை, மேலும் ஒவ்வொரு வாடிக்கையாளர்களிடமும் இந்த திட்டத்தின் நகல் உள்ளது, எனவே ஸ்கீமா மற்றும் அதன் ஒருமைப்பாட்டைக் கடைப்பிடிப்பதைச் செயல்படுத்துவது, தரவுத்தளத்தில் அதைச் செய்ய சரியான அர்த்தத்தை அளிக்கிறது. தகவல் சேமிக்கப்படுகிறது.
இது பழமையான ஞானம் கூட. முதன்மை மற்றும் தனிப்பட்ட விசைகள் நல்லது. வெளிநாட்டு விசைகள் நன்றாக உள்ளன. கட்டுப்பாடு சரிபார்த்தல் நல்லது. வலியுறுத்தல்கள் - சரி.

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

• உங்கள் மேஜை எந்த இடத்தில் உள்ளது
• அவளுடைய PCTFREE மதிப்பு என்ன
• உங்கள் வரிசையில் (ஐடிக்கு பின்னால்) கேச் அளவு என்ன

இவை அனைத்தும் சிறிய அமைப்புகளில் ஒரு பொருட்டல்ல, ஆனால் "பெரிய தரவு" சாம்ராஜ்யத்திற்கு மாறும் வரை காத்திருக்க வேண்டிய அவசியமில்லை - மேலே குறிப்பிட்டுள்ளவை போன்ற விற்பனையாளர் வழங்கிய சேமிப்பக மேம்படுத்தல்களிலிருந்து நீங்கள் பயனடையத் தொடங்கலாம். நான் பார்த்த ORMகள் எதுவும் (jOOQ உட்பட) உங்கள் தரவுத்தளத்தில் நீங்கள் பயன்படுத்த விரும்பும் DDL விருப்பங்களின் முழு தொகுப்புக்கான அணுகலை வழங்கவில்லை. ORMகள் DDL எழுத உதவும் சில கருவிகளை வழங்குகின்றன.

ஆனால் நாள் முடிவில், DDLல் நன்கு வடிவமைக்கப்பட்ட திட்டம் கையால் எழுதப்பட்டது. எந்த ஒரு DDL உருவாக்கப்பட்டாலும் அது தோராயமாக மட்டுமே இருக்கும்.

வாடிக்கையாளர் மாதிரி பற்றி என்ன?

மேலே குறிப்பிட்டுள்ளபடி, கிளையண்டில் உங்கள் தரவுத்தளத் திட்டத்தின் நகல், கிளையன்ட் பார்வை தேவைப்படும். இந்த கிளையன்ட் பார்வை உண்மையான மாதிரியுடன் ஒத்திசைவாக இருக்க வேண்டும் என்று சொல்ல தேவையில்லை. இதை அடைய சிறந்த வழி என்ன? குறியீடு ஜெனரேட்டருடன்.

அனைத்து தரவுத்தளங்களும் அவற்றின் மெட்டா தகவலை SQL வழியாக வழங்குகின்றன. உங்கள் தரவுத்தளத்திலிருந்து வெவ்வேறு SQL பேச்சுவழக்குகளில் அனைத்து அட்டவணைகளையும் எவ்வாறு பெறுவது என்பது இங்கே:

	-- H2, HSQLDB, MySQL, PostgreSQL, SQL Server
SELECT table_schema, table_name
FROM information_schema.tables
 
-- DB2
SELECT tabschema, tabname
FROM syscat.tables
 
-- Oracle
SELECT owner, table_name
FROM all_tables
 
-- SQLite
SELECT name
FROM sqlite_master
 
-- Teradata
SELECT databasename, tablename
FROM dbc.tables

இந்த வினவல்கள் (அல்லது அதுபோன்றவை, நீங்கள் பார்வைகள், பொருளடக்கம் செய்யப்பட்ட பார்வைகள், அட்டவணை மதிப்புள்ள செயல்பாடுகள் ஆகியவற்றைக் கருத்தில் கொள்ள வேண்டுமா என்பதைப் பொறுத்து) அழைப்பதன் மூலம் செயல்படுத்தப்படும். DatabaseMetaData.getTables() JDBC இலிருந்து, அல்லது jOOQ meta-module ஐப் பயன்படுத்துகிறது.

அத்தகைய வினவல்களின் முடிவுகளிலிருந்து, நீங்கள் கிளையண்டில் எந்தத் தொழில்நுட்பத்தைப் பயன்படுத்தினாலும், உங்கள் தரவுத்தள மாதிரியின் எந்தவொரு கிளையன்ட் பக்க பிரதிநிதித்துவத்தையும் உருவாக்குவது ஒப்பீட்டளவில் எளிதானது.

• நீங்கள் JDBC அல்லது Spring ஐப் பயன்படுத்துகிறீர்கள் என்றால், சரம் மாறிலிகளின் தொகுப்பை உருவாக்கலாம்
• நீங்கள் JPA ஐப் பயன்படுத்துகிறீர்கள் என்றால், நீங்கள் நிறுவனங்களைத் தாங்களே உருவாக்கலாம்
• நீங்கள் jOOQ ஐப் பயன்படுத்தினால், நீங்கள் jOOQ மெட்டா மாதிரியை உருவாக்கலாம்

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

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

ALTER TABLE book RENAME COLUMN title TO book_title;

இந்த வேலையை இரண்டு முறை செய்ய விரும்புகிறீர்களா? எந்த சந்தர்ப்பத்திலும். நாங்கள் DDL ஐச் செய்து, அதை உங்கள் பில்ட் பைப்லைன் மூலம் இயக்கி, புதுப்பிக்கப்பட்ட நிறுவனத்தைப் பெறுகிறோம்:

@Entity
@Table(name = "book", indexes = {
 
  // Вы об этом задумывались?
  @Index(name = "i_book_title", columnList = "book_title")
})
class Book {
  @Id
  @GeneratedValue(strategy = IDENTITY)
  int id;
 
  @Column("book_title")
  String bookTitle;
}

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

ஒரே உண்மை

நீங்கள் எந்த தொழில்நுட்பத்தைப் பயன்படுத்தினாலும், சில துணை அமைப்புகளுக்கு உண்மையின் ஒரே ஆதாரமாக எப்போதும் ஒரு மாதிரி உள்ளது - அல்லது குறைந்தபட்சம் நாம் இதற்காக பாடுபட வேண்டும் மற்றும் "உண்மை" எல்லா இடங்களிலும் ஒரே நேரத்தில் எங்கும் இல்லாத நிறுவன குழப்பத்தைத் தவிர்க்க வேண்டும். எல்லாம் மிகவும் எளிதாக இருக்கும். நீங்கள் XML கோப்புகளை வேறு ஏதேனும் கணினியுடன் பரிமாறிக் கொண்டால், XSDஐப் பயன்படுத்தவும். XML வடிவத்தில் jOOQ இன் INFORMATION_SCHEMA மெட்டா மாடலைப் பாருங்கள்:
https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• XSD நன்கு புரிந்து கொள்ளப்பட்டுள்ளது
• XSD XML உள்ளடக்கத்தை நன்றாகக் குறிக்கிறது மற்றும் அனைத்து கிளையன்ட் மொழிகளிலும் சரிபார்ப்பை அனுமதிக்கிறது
• XSD நன்கு பதிப்பானது மற்றும் மிகவும் பின்தங்கிய இணக்கமானது
• XJC ஐப் பயன்படுத்தி XSD ஐ ஜாவா குறியீட்டில் மொழிபெயர்க்கலாம்

கடைசி புள்ளி முக்கியமானது. எக்ஸ்எம்எல் செய்திகளைப் பயன்படுத்தி வெளிப்புற அமைப்புடன் தொடர்பு கொள்ளும்போது, ​​​​எங்கள் செய்திகள் செல்லுபடியாகும் என்பதை உறுதிப்படுத்த விரும்புகிறோம். JAXB, XJC மற்றும் XSD மூலம் இதை அடைவது மிகவும் எளிதானது. நமது செய்திகளை ஜாவா ஆப்ஜெக்ட்களாக உருவாக்கும் ஜாவா-முதல் வடிவமைப்பு அணுகுமுறையில், அவை எப்படியாவது XML க்கு புத்திசாலித்தனமாக வழங்கப்பட்டு மற்றொரு கணினிக்கு நுகர்வுக்கு அனுப்பப்படும் என்று நினைப்பது சுத்த பைத்தியக்காரத்தனமாக இருக்கும். இந்த வழியில் உருவாக்கப்பட்ட XML மிகவும் மோசமான தரம், ஆவணமற்ற மற்றும் உருவாக்க கடினமாக இருக்கும். அத்தகைய இடைமுகத்தில் சேவைத் தரம் (SLA) அளவில் ஒப்பந்தம் இருந்தால், உடனடியாக அதைத் திருகுவோம்.

உண்மையைச் சொல்வதென்றால், JSON API இல் எப்போதும் இதுதான் நடக்கும், ஆனால் இது மற்றொரு கதை, நான் அடுத்த முறை வாதிடுவேன் ...

தரவுத்தளங்கள்: அவை ஒன்றே

தரவுத்தளங்களுடன் பணிபுரியும் போது, ​​​​அவை அனைத்தும் ஒரே மாதிரியானவை என்பதை நீங்கள் புரிந்துகொள்கிறீர்கள். தரவுத்தளமானது அதன் தரவைக் கொண்டுள்ளது மற்றும் திட்டத்தை நிர்வகிக்க வேண்டும். திட்டத்தில் செய்யப்பட்ட எந்த மாற்றங்களும் நேரடியாக DDL இல் செயல்படுத்தப்பட வேண்டும், இதனால் உண்மையின் ஒற்றை ஆதாரம் புதுப்பிக்கப்படும்.

மூலப் புதுப்பிப்பு ஏற்பட்டால், அனைத்து வாடிக்கையாளர்களும் தங்கள் மாதிரியின் நகல்களைப் புதுப்பிக்க வேண்டும். சில கிளையண்டுகள் jOOQ மற்றும் Hibernate அல்லது JDBC (அல்லது இரண்டும்) பயன்படுத்தி ஜாவாவில் எழுதப்படலாம். பிற கிளையன்ட்கள் பெர்லில் எழுதப்பட்டிருக்கலாம் (அவர்களுக்கு அதிர்ஷ்டத்தை வாழ்த்துவோம்), மற்றவை சி#ல். பரவாயில்லை. முக்கிய மாதிரி தரவுத்தளத்தில் உள்ளது. ORM-உருவாக்கப்பட்ட மாதிரிகள் பொதுவாக மோசமான தரம், மோசமாக ஆவணப்படுத்தப்பட்ட மற்றும் உருவாக்க கடினமாக இருக்கும்.

எனவே தவறு செய்யாதீர்கள். ஆரம்பத்திலிருந்தே தவறு செய்யாதீர்கள். தரவுத்தளத்திலிருந்து வேலை செய்யுங்கள். தானியங்கு செய்யக்கூடிய வரிசைப்படுத்தல் பைப்லைனை உருவாக்கவும். உங்கள் தரவுத்தள மாதிரியை வசதியாக நகலெடுத்து கிளையண்டுகளில் டம்ப் செய்ய குறியீடு ஜெனரேட்டர்களை இயக்கவும். குறியீடு ஜெனரேட்டர்களைப் பற்றி கவலைப்படுவதை நிறுத்துங்கள். அவர்கள் நல்லவர்கள். அவர்களுடன், நீங்கள் அதிக உற்பத்தி பெறுவீர்கள். தொடக்கத்திலிருந்தே அவற்றை அமைக்க சிறிது நேரம் செலவழித்தால் போதும், உங்கள் திட்டத்தின் கதையை உருவாக்க பல ஆண்டுகளாக மேம்பட்ட செயல்திறன் உங்களுக்கு இருக்கும்.

இன்னும் எனக்கு நன்றி சொல்லாதே, பிறகு.

விளக்கவுரையும்

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

இன்னும் சில இடங்களில் பாதுகாக்கப்படும் இரண்டு-நிலை கட்டமைப்புகளில், அத்தகைய அமைப்பு மாதிரி மட்டுமே சாத்தியமானதாக இருக்கலாம். இருப்பினும், பெரும்பாலான கணினிகளில், தரவு அணுகல் அடுக்கு தரவுத்தள மாதிரியை இணைக்கும் ஒரு "துணை அமைப்பாக" எனக்குத் தோன்றுகிறது.

விதிவிலக்குகள்

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

• ஸ்கீமா தெரியவில்லை மற்றும் திறக்கப்பட வேண்டும். எடுத்துக்காட்டாக, எந்தவொரு வரைபடத்தையும் பயனர்கள் வழிநடத்த உதவும் ஒரு கருவியை வழங்குகிறீர்கள். ப்யூ. இங்கே குறியீடு உருவாக்கம் இல்லை. ஆனால் இன்னும் - முதலில் தரவுத்தளம்.
• சில சிக்கலைத் தீர்க்க பறக்கும்போது ஒரு சுற்று உருவாக்கப்பட வேண்டும். இந்த உதாரணம் மாதிரியின் சற்று சுறுசுறுப்பான பதிப்பாகத் தெரிகிறது பொருள் பண்பு மதிப்பு, அதாவது, உங்களிடம் உண்மையில் நன்கு வரையறுக்கப்பட்ட திட்டம் இல்லை. இந்த வழக்கில், ஒரு RDBMS உங்களுக்கு பொருந்தும் என்பதை நீங்கள் அடிக்கடி உறுதியாகச் சொல்ல முடியாது.

விதிவிலக்குகள் இயல்பிலேயே விதிவிலக்கானவை. RDBMS இன் பயன்பாடு சம்பந்தப்பட்ட பெரும்பாலான சந்தர்ப்பங்களில், திட்டம் முன்கூட்டியே அறியப்படுகிறது, அது RDBMS க்குள் உள்ளது மற்றும் "உண்மையின்" ஒரே ஆதாரமாக உள்ளது, மேலும் அனைத்து வாடிக்கையாளர்களும் அதிலிருந்து பெறப்பட்ட நகல்களைப் பெற வேண்டும். வெறுமனே, இது ஒரு குறியீடு ஜெனரேட்டரை உள்ளடக்கியதாக இருக்க வேண்டும்.

ஆதாரம்: www.habr.com