ആദ്യം സത്യം, അല്ലെങ്കിൽ എന്തുകൊണ്ടാണ് ഡാറ്റാബേസ് ഉപകരണത്തെ അടിസ്ഥാനമാക്കി സിസ്റ്റം രൂപകൽപ്പന ചെയ്യേണ്ടത്

ഹേ ഹബർ!

ഞങ്ങൾ വിഷയം പര്യവേക്ഷണം ചെയ്യുന്നത് തുടരുന്നു ജാവ и സ്പ്രിംഗ്ഡാറ്റാബേസ് തലത്തിൽ ഉൾപ്പെടെ. വലിയ ആപ്ലിക്കേഷനുകൾ രൂപകൽപ്പന ചെയ്യുമ്പോൾ, ഡാറ്റാബേസ് ഘടനയാണ്, ജാവ കോഡിനല്ല, നിർണ്ണായക പ്രാധാന്യമുള്ളത് എന്തുകൊണ്ടാണെന്നും ഇത് എങ്ങനെ ചെയ്യാമെന്നും ഈ നിയമത്തിലെ അപവാദങ്ങൾ എന്തൊക്കെയാണെന്നും വായിക്കാൻ ഇന്ന് ഞങ്ങൾ വാഗ്ദാനം ചെയ്യുന്നു.

വളരെ വൈകിപ്പോയ ഈ ലേഖനത്തിൽ, മിക്കവാറും എല്ലാ സാഹചര്യങ്ങളിലും, ഒരു ആപ്ലിക്കേഷനിലെ ഡാറ്റാ മോഡൽ "ജാവയുടെ കഴിവുകളിൽ നിന്ന്" (അല്ലെങ്കിൽ നിങ്ങൾ ഏത് ക്ലയന്റ് ഭാഷയിലായാലും" രൂപകല്പന ചെയ്യുന്നതിനുപകരം "ഡാറ്റാബേസിൽ നിന്ന്" രൂപകൽപന ചെയ്യണമെന്ന് ഞാൻ കരുതുന്നത് എന്തുകൊണ്ടാണെന്ന് ഞാൻ വിശദീകരിക്കും. കൂടെ പ്രവർത്തിക്കുന്നു). രണ്ടാമത്തെ സമീപനം തിരഞ്ഞെടുക്കുന്നതിലൂടെ, നിങ്ങളുടെ പ്രോജക്റ്റ് വളരാൻ തുടങ്ങിയാൽ നിങ്ങൾ വേദനയുടെയും കഷ്ടപ്പാടുകളുടെയും ഒരു നീണ്ട പാതയിലേക്ക് പ്രവേശിക്കുന്നു.

എന്നതിനെ അടിസ്ഥാനമാക്കിയാണ് ലേഖനം എഴുതിയത് ഒരു ചോദ്യം, സ്റ്റാക്ക് ഓവർഫ്ലോയിൽ നൽകിയിരിക്കുന്നു.

വിഭാഗങ്ങളിൽ റെഡ്ഡിറ്റിനെക്കുറിച്ചുള്ള രസകരമായ ചർച്ചകൾ /r/java и /ആർ/പ്രോഗ്രാമിംഗ്.

കോഡ് ജനറേഷൻ

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)) {
    // ...
}

കോഡ് ബിൽഡിന് പുറത്ത് സ്വമേധയാ അല്ലെങ്കിൽ എല്ലാ ബിൽഡിലും സ്വമേധയാ സൃഷ്ടിക്കപ്പെടുന്നു. ഉദാഹരണത്തിന്, അത്തരം പുനരുജ്ജീവനം ഉടൻ തന്നെ പിന്തുടരാം ഫ്ലൈവേ ഡാറ്റാബേസ് മൈഗ്രേഷൻ, ഇത് സ്വമേധയാ അല്ലെങ്കിൽ സ്വയമേ ചെയ്യാവുന്നതാണ്.

ഉറവിട കോഡ് സൃഷ്ടിക്കൽ

കോഡ് സൃഷ്ടിക്കുന്നതിനുള്ള ഈ സമീപനങ്ങളുമായി ബന്ധപ്പെട്ട വിവിധ തത്ത്വചിന്തകളും ഗുണങ്ങളും ദോഷങ്ങളുമുണ്ട് - മാനുവൽ, ഓട്ടോമാറ്റിക് - ഈ ലേഖനത്തിൽ ഞാൻ വിശദമായി ചർച്ച ചെയ്യാൻ പോകുന്നില്ല. പക്ഷേ, പൊതുവേ, ജനറേറ്റ് ചെയ്ത കോഡിന്റെ മുഴുവൻ പോയിന്റും, ഞങ്ങളുടെ സിസ്റ്റത്തിനകത്തോ പുറത്തോ ഞങ്ങൾ നിസ്സാരമായി കാണുന്ന “സത്യം” ജാവയിൽ പുനർനിർമ്മിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു എന്നതാണ്. ഒരർത്ഥത്തിൽ, സോഴ്‌സ് കോഡിൽ നിന്ന് ബൈറ്റ്‌കോഡ്, മെഷീൻ കോഡ് അല്ലെങ്കിൽ മറ്റേതെങ്കിലും തരത്തിലുള്ള കോഡ് സൃഷ്‌ടിക്കുന്ന കംപൈലറുകൾ ഇതുതന്നെയാണ് ചെയ്യുന്നത് - പ്രത്യേക കാരണങ്ങൾ പരിഗണിക്കാതെ തന്നെ മറ്റൊരു ഭാഷയിൽ നമ്മുടെ "സത്യ"ത്തിന്റെ ഒരു പ്രാതിനിധ്യം നമുക്ക് ലഭിക്കും.

അത്തരം നിരവധി കോഡ് ജനറേറ്ററുകൾ ഉണ്ട്. ഉദാഹരണത്തിന്, XSD അല്ലെങ്കിൽ WSDL ഫയലുകളെ അടിസ്ഥാനമാക്കി XJC-ക്ക് ജാവ കോഡ് സൃഷ്ടിക്കാൻ കഴിയും. തത്വം എല്ലായ്പ്പോഴും സമാനമാണ്:

• ചില സത്യങ്ങളുണ്ട് (ആന്തരികമോ ബാഹ്യമോ) - ഉദാഹരണത്തിന്, ഒരു സ്പെസിഫിക്കേഷൻ, ഒരു ഡാറ്റ മോഡൽ മുതലായവ.
• ഞങ്ങളുടെ പ്രോഗ്രാമിംഗ് ഭാഷയിൽ ഈ സത്യത്തിന്റെ പ്രാദേശിക പ്രാതിനിധ്യം ആവശ്യമാണ്.

മാത്രമല്ല, അത്തരം ഒരു പ്രാതിനിധ്യം സൃഷ്ടിക്കുന്നത് മിക്കവാറും എപ്പോഴും ഉചിതമാണ് - ആവർത്തനം ഒഴിവാക്കുന്നതിന്.

തരം ദാതാക്കളും വ്യാഖ്യാന പ്രോസസ്സിംഗും

ശ്രദ്ധിക്കുക: jOOQ-നുള്ള കോഡ് സൃഷ്ടിക്കുന്നതിനുള്ള മറ്റൊരു, കൂടുതൽ ആധുനികവും നിർദ്ദിഷ്ടവുമായ സമീപനം തരം ദാതാക്കളുടെ ഉപയോഗം ഉൾപ്പെടുന്നു, F#-ൽ അവ നടപ്പിലാക്കിയതുപോലെ. ഈ സാഹചര്യത്തിൽ, കോഡ് കംപൈലർ ജനറേറ്റുചെയ്യുന്നു, യഥാർത്ഥത്തിൽ സമാഹരണ ഘട്ടത്തിലാണ്. തത്വത്തിൽ, അത്തരം കോഡ് സോഴ്സ് കോഡുകളുടെ രൂപത്തിൽ നിലവിലില്ല. ജാവയിൽ, സമാനമായ ഉപകരണങ്ങൾ ഉണ്ട്, അത്ര ഗംഭീരമല്ലെങ്കിലും - ഇവ വ്യാഖ്യാന പ്രോസസ്സറുകളാണ്, ഉദാഹരണത്തിന്, ലാമ്ബാക്.

ഒരു പ്രത്യേക അർത്ഥത്തിൽ, ആദ്യ കേസിലെ അതേ കാര്യങ്ങൾ ഇവിടെ സംഭവിക്കുന്നു, ഒഴികെ:

• നിങ്ങൾ ജനറേറ്റ് ചെയ്‌ത കോഡ് കാണുന്നില്ല (ഒരുപക്ഷേ ഈ സാഹചര്യം മറ്റൊരാൾക്ക് അത്ര വെറുപ്പുളവാക്കുന്നതായി തോന്നുന്നില്ലേ?)
• തരങ്ങൾ നൽകാനാകുമെന്ന് നിങ്ങൾ ഉറപ്പാക്കണം, അതായത്, "ശരി" എപ്പോഴും ലഭ്യമായിരിക്കണം. "സത്യം" വ്യാഖ്യാനിക്കുന്ന ലോംബോക്കിന്റെ കാര്യത്തിൽ ഇത് എളുപ്പമാണ്. എല്ലായ്‌പ്പോഴും ലഭ്യമായ ഒരു തത്സമയ കണക്ഷനെ ആശ്രയിക്കുന്ന ഡാറ്റാബേസ് മോഡലുകളിൽ ഇത് അൽപ്പം ബുദ്ധിമുട്ടാണ്.

കോഡ് സൃഷ്ടിക്കുന്നതിൽ എന്താണ് പ്രശ്നം?

സ്വമേധയാ അല്ലെങ്കിൽ സ്വയമേവ കോഡ് സൃഷ്ടിക്കുന്നത് എങ്ങനെ ആരംഭിക്കുന്നതാണ് നല്ലത് എന്ന തന്ത്രപരമായ ചോദ്യത്തിന് പുറമേ, കോഡ് സൃഷ്ടിക്കൽ ആവശ്യമില്ലെന്ന് വിശ്വസിക്കുന്ന ആളുകളുണ്ടെന്ന് ഞാൻ പരാമർശിക്കേണ്ടതുണ്ട്. ഞാൻ പലപ്പോഴും കണ്ടിട്ടുള്ള ഈ വീക്ഷണത്തിന്റെ ന്യായീകരണം, നിർമ്മാണ പൈപ്പ് ലൈൻ സ്ഥാപിക്കുന്നത് ബുദ്ധിമുട്ടാണ് എന്നതാണ്. അതെ, ഇത് ശരിക്കും ബുദ്ധിമുട്ടാണ്. അധിക അടിസ്ഥാന സൗകര്യ ചെലവുകൾ ഉണ്ട്. നിങ്ങൾ ഒരു പ്രത്യേക ഉൽപ്പന്നം ഉപയോഗിച്ചാണ് ആരംഭിക്കുന്നതെങ്കിൽ (അത് jOOQ, അല്ലെങ്കിൽ JAXB, അല്ലെങ്കിൽ ഹൈബർനേറ്റ്, മുതലായവ), ഒരു വർക്ക് ബെഞ്ച് സജ്ജീകരിക്കാൻ സമയമെടുക്കും, അതിൽ നിന്ന് മൂല്യം നേടുന്നതിന് API പഠിക്കാൻ നിങ്ങൾ ചെലവഴിക്കാൻ ആഗ്രഹിക്കുന്നു. .

ജനറേറ്ററിന്റെ ഉപകരണം മനസിലാക്കുന്നതുമായി ബന്ധപ്പെട്ട ചെലവുകൾ വളരെ ഉയർന്നതാണെങ്കിൽ, കോഡ് ജനറേറ്ററിന്റെ ഉപയോഗക്ഷമതയിൽ API ഒരു മോശം ജോലി ചെയ്തു (ഭാവിയിൽ അതിൽ ഇഷ്‌ടാനുസൃതമാക്കലും ബുദ്ധിമുട്ടാണെന്ന് മാറുന്നു). അത്തരം ഏതെങ്കിലും API-യ്‌ക്ക് ഏറ്റവും ഉയർന്ന മുൻഗണന നൽകേണ്ടത് ഉപയോഗക്ഷമതയാണ്. എന്നാൽ ഇത് കോഡ് സൃഷ്ടിക്കുന്നതിനെതിരായ ഒരു വാദം മാത്രമാണ്. അല്ലാത്തപക്ഷം, ആന്തരികമോ ബാഹ്യമോ ആയ സത്യത്തിന്റെ പ്രാദേശിക പ്രതിനിധാനം എഴുതുന്നത് പൂർണ്ണമായും കൈകൊണ്ടാണ്.

ഇതൊക്കെ ചെയ്യാൻ സമയമില്ല എന്ന് പലരും പറയും. അവർ അവരുടെ സൂപ്പർ ഉൽപ്പന്നത്തിനുള്ള സമയപരിധിയിലാണ്. ഒരു ദിവസം കഴിഞ്ഞ് ഞങ്ങൾ അസംബ്ലി കൺവെയറുകൾ ചീപ്പ് ചെയ്യും, ഞങ്ങൾക്ക് സമയമുണ്ടാകും. ഞാൻ അവർക്ക് ഉത്തരം നൽകും:

യഥാർത്ഥ, അലൻ ഒ റൂർക്ക്, ഓഡിയൻസ് സ്റ്റാക്ക്

എന്നാൽ ഹൈബർനേറ്റ് / ജെപിഎയിൽ "ജാവയിൽ" കോഡ് എഴുതുന്നത് വളരെ എളുപ്പമാണ്.

ശരിക്കും. ഹൈബർനേറ്റിനും അതിന്റെ ഉപയോക്താക്കൾക്കും ഇത് ഒരു അനുഗ്രഹവും ശാപവുമാണ്. ഹൈബർനേറ്റിൽ, നിങ്ങൾക്ക് ഇതുപോലെ രണ്ട് എന്റിറ്റികൾ എഴുതാം:

	@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-ൽ ഹൈബർനേറ്റ് ഒരു സൂചിക സൃഷ്ടിക്കുമോ? ഞങ്ങൾക്ക് അത് ആവശ്യമാണെന്ന് എനിക്കറിയാം.
• ഹൈബർനേറ്റ് ഈ കീ ഐഡന്റിറ്റി സ്പെസിഫിക്കേഷനിൽ ഒരു ഐഡന്റിറ്റി കീ ആക്കുമോ?

ഒരുപക്ഷേ ഇല്ല. നിങ്ങൾ ആദ്യം മുതൽ നിങ്ങളുടെ പ്രോജക്റ്റ് വികസിപ്പിക്കുകയാണെങ്കിൽ, പഴയ ഡാറ്റാബേസ് നിരസിക്കുകയും ആവശ്യമായ വ്യാഖ്യാനങ്ങൾ ചേർത്തയുടൻ പുതിയൊരെണ്ണം സൃഷ്ടിക്കുകയും ചെയ്യുന്നത് എല്ലായ്പ്പോഴും സൗകര്യപ്രദമാണ്. അതിനാൽ, പുസ്തക സ്ഥാപനം ഒടുവിൽ ഈ ഫോം എടുക്കും:

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

അടിപൊളി. പുനരുജ്ജീവിപ്പിക്കുക. വീണ്ടും, ഈ സാഹചര്യത്തിൽ, തുടക്കത്തിൽ ഇത് വളരെ എളുപ്പമായിരിക്കും.

എന്നാൽ നിങ്ങൾ പിന്നീട് പണം നൽകേണ്ടിവരും.

താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട് നിങ്ങൾ ഉൽപാദനത്തിലേക്ക് പോകേണ്ടിവരും. അപ്പോഴാണ് മോഡൽ പ്രവർത്തിക്കുന്നത് നിർത്തുന്നത്. കാരണം:

നിർമ്മാണത്തിൽ, ആവശ്യമെങ്കിൽ, പഴയ ഡാറ്റാബേസ് നിരസിക്കാനും ആദ്യം മുതൽ എല്ലാം ആരംഭിക്കാനും ഇനി സാധ്യമല്ല. നിങ്ങളുടെ ഡാറ്റാബേസ് ഒരു ലെഗസി ആയി മാറും.

ഇനി മുതൽ എന്നേക്കും എഴുതേണ്ടി വരും DDL മൈഗ്രേഷൻ സ്ക്രിപ്റ്റുകൾ, ഉദാ. ഫ്ലൈവേ ഉപയോഗിക്കുന്നു. ഈ സാഹചര്യത്തിൽ നിങ്ങളുടെ സ്ഥാപനങ്ങൾക്ക് എന്ത് സംഭവിക്കും? ഒന്നുകിൽ നിങ്ങൾക്ക് അവ സ്വമേധയാ ക്രമീകരിക്കാം (നിങ്ങളുടെ ജോലിഭാരം ഇരട്ടിയാക്കാം) അല്ലെങ്കിൽ ഹൈബർനേറ്റ് നിങ്ങൾക്കായി അവ പുനർനിർമ്മിക്കുക (നിങ്ങളുടെ പ്രതീക്ഷകൾ നിറവേറ്റാൻ ഈ രീതിയിൽ സൃഷ്ടിച്ചത് എത്രത്തോളം സാധ്യതയുണ്ട്?) ഒന്നുകിൽ നിങ്ങൾക്ക് നഷ്ടപ്പെടും.

അതിനാൽ, നിങ്ങൾ ഉൽപാദനത്തിലേക്ക് നീങ്ങുമ്പോൾ, നിങ്ങൾക്ക് ചൂടുള്ള പാച്ചുകൾ ആവശ്യമാണ്. അവ വളരെ വേഗത്തിൽ ഉൽപാദനത്തിലേക്ക് കൊണ്ടുവരേണ്ടതുണ്ട്. ഉൽപ്പാദനത്തിനായി നിങ്ങളുടെ മൈഗ്രേഷനുകളുടെ സുഗമമായ പൈപ്പ്ലൈനിംഗ് നിങ്ങൾ തയ്യാറാക്കുകയും സംഘടിപ്പിക്കുകയും ചെയ്യാത്തതിനാൽ, നിങ്ങൾ വന്യമായി ഒത്തുകളിക്കുകയാണ്. പിന്നെ എല്ലാം ശരിയായി ചെയ്യാൻ നിങ്ങൾക്ക് സമയമില്ല. നിങ്ങൾ ഹൈബർനേറ്റിനെ ശകാരിക്കുന്നു, കാരണം ഇത് എല്ലായ്പ്പോഴും ആരുടെയെങ്കിലും തെറ്റാണ്, പക്ഷേ നിങ്ങളല്ല ...

പകരം, തുടക്കം മുതൽ, എല്ലാം തികച്ചും വ്യത്യസ്തമായി ചെയ്യാമായിരുന്നു. ഉദാഹരണത്തിന്, ഒരു സൈക്കിളിൽ റൗണ്ട് വീലുകൾ ഇടുക.

ആദ്യം ഡാറ്റാബേസ്

നിങ്ങളുടെ ഡാറ്റാബേസ് സ്കീമയിലെ യഥാർത്ഥ "സത്യവും" അതിന്മേലുള്ള "പരമാധികാരവും" ഡാറ്റാബേസിനുള്ളിലാണ്. സ്കീമ നിർവചിച്ചിരിക്കുന്നത് ഡാറ്റാബേസിൽ മാത്രമാണ്, മറ്റെവിടെയുമില്ല, കൂടാതെ ഓരോ ക്ലയന്റുകൾക്കും ഈ സ്കീമയുടെ ഒരു പകർപ്പ് ഉണ്ട്, അതിനാൽ സ്കീമയും അതിന്റെ സമഗ്രതയും പാലിക്കുന്നത് നിർബന്ധമായും ഡാറ്റാബേസിൽ തന്നെ ചെയ്യാൻ ഇത് തികച്ചും യുക്തിസഹമാണ് - ഇവിടെ വിവരങ്ങൾ സൂക്ഷിച്ചിരിക്കുന്നു.
ഇത് പഴയ ജ്ഞാനമാണ്. പ്രാഥമികവും അദ്വിതീയവുമായ കീകൾ നല്ലതാണ്. വിദേശ കീകൾ നല്ലതാണ്. നിയന്ത്രണ പരിശോധന നല്ലതാണ്. അവകാശവാദങ്ങൾ - നന്നായി.

പിന്നെ, അത് മാത്രമല്ല. ഉദാഹരണത്തിന്, Oracle ഉപയോഗിച്ച്, നിങ്ങൾ വ്യക്തമാക്കാൻ താൽപ്പര്യപ്പെട്ടേക്കാം:

• നിങ്ങളുടെ മേശ ഏത് സ്ഥലത്താണ്
• അവളുടെ PCTFREE മൂല്യം എന്താണ്
• നിങ്ങളുടെ ക്രമത്തിലെ കാഷെ വലുപ്പം എന്താണ് (ഐഡിക്ക് പിന്നിൽ)

ചെറിയ സിസ്റ്റങ്ങളിൽ ഇതെല്ലാം പ്രശ്നമല്ലായിരിക്കാം, പക്ഷേ "വലിയ ഡാറ്റ" എന്ന മണ്ഡലത്തിലേക്ക് മാറുന്നത് വരെ കാത്തിരിക്കേണ്ടതില്ല - മുകളിൽ സൂചിപ്പിച്ചത് പോലെയുള്ള വെണ്ടർ നൽകുന്ന സ്റ്റോറേജ് ഒപ്റ്റിമൈസേഷനുകളിൽ നിന്ന് നിങ്ങൾക്ക് പ്രയോജനം നേടാൻ കഴിയും. ഞാൻ കണ്ട ORM-കളൊന്നും (jOOQ ഉൾപ്പെടെ) നിങ്ങളുടെ ഡാറ്റാബേസിൽ നിങ്ങൾ ഉപയോഗിക്കാൻ ആഗ്രഹിച്ചേക്കാവുന്ന മുഴുവൻ DDL ഓപ്ഷനുകളിലേക്കും പ്രവേശനം നൽകുന്നില്ല. DDL എഴുതാൻ നിങ്ങളെ സഹായിക്കുന്നതിന് ORM-കൾ ചില ടൂളുകൾ വാഗ്ദാനം ചെയ്യുന്നു.

എന്നാൽ ദിവസാവസാനം, നന്നായി രൂപകൽപ്പന ചെയ്ത ഒരു സ്കീമ 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 മെറ്റാ-മൊഡ്യൂൾ ഉപയോഗിച്ച്.

അത്തരം അന്വേഷണങ്ങളുടെ ഫലങ്ങളിൽ നിന്ന്, നിങ്ങളുടെ ഡാറ്റാബേസ് മോഡലിന്റെ ഏതെങ്കിലും ക്ലയന്റ്-സൈഡ് പ്രാതിനിധ്യം സൃഷ്ടിക്കുന്നത് താരതമ്യേന എളുപ്പമാണ്, നിങ്ങൾ ക്ലയന്റിൽ ഏത് സാങ്കേതികവിദ്യ ഉപയോഗിച്ചാലും.

• നിങ്ങൾ ജെഡിബിസി അല്ലെങ്കിൽ സ്പ്രിംഗ് ഉപയോഗിക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ഒരു കൂട്ടം സ്ട്രിംഗ് കോൺസ്റ്റന്റുകൾ സൃഷ്ടിക്കാൻ കഴിയും
• നിങ്ങൾ 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 ക്ലാസ്. മിക്ക DDL മാറ്റങ്ങളും വാക്യഘടനയെ മാത്രമല്ല, അർത്ഥശാസ്ത്രത്തെയും ബാധിക്കുന്നു. അതിനാൽ, നിങ്ങളുടെ ഡാറ്റാബേസ് വർദ്ധിപ്പിക്കുന്നതിലൂടെ ഏത് കോഡിനെ ബാധിക്കും (അല്ലെങ്കിൽ ആകാം) കംപൈൽ ചെയ്ത കോഡിൽ കാണുന്നത് സൗകര്യപ്രദമായിരിക്കും.

സത്യം മാത്രം

നിങ്ങൾ ഏത് സാങ്കേതികവിദ്യ ഉപയോഗിച്ചാലും, ചില ഉപസിസ്റ്റങ്ങൾക്ക് സത്യത്തിന്റെ ഏക ഉറവിടമായ ഒരു മോഡൽ എപ്പോഴും ഉണ്ടായിരിക്കും - അല്ലെങ്കിൽ കുറഞ്ഞത് ഞങ്ങൾ ഇതിനായി പരിശ്രമിക്കുകയും "സത്യം" എല്ലായിടത്തും ഒരിടത്തും ഒരേസമയം ഇല്ലാത്ത എന്റർപ്രൈസ് ആശയക്കുഴപ്പം ഒഴിവാക്കുകയും വേണം. എല്ലാം വളരെ എളുപ്പമാക്കാം. നിങ്ങൾ മറ്റേതെങ്കിലും സിസ്റ്റവുമായി 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 വളരെ മോശം നിലവാരമുള്ളതും, രേഖകളില്ലാത്തതും, വികസിപ്പിക്കാൻ ബുദ്ധിമുട്ടുള്ളതുമായിരിക്കും. അത്തരമൊരു ഇന്റർഫേസിൽ സേവന നിലവാരത്തിന്റെ (എസ്‌എൽ‌എ) ഒരു കരാറുണ്ടെങ്കിൽ, ഞങ്ങൾ അത് ഉടനടി സ്ക്രൂ ചെയ്യും.

സത്യം പറഞ്ഞാൽ, JSON API-യിൽ എല്ലായ്‌പ്പോഴും സംഭവിക്കുന്നത് ഇതാണ്, പക്ഷേ ഇത് മറ്റൊരു കഥയാണ്, അടുത്ത തവണ ഞാൻ വാദിക്കും ...

ഡാറ്റാബേസുകൾ: അവ സമാനമാണ്

ഡാറ്റാബേസുകളിൽ പ്രവർത്തിക്കുമ്പോൾ, അവയെല്ലാം അടിസ്ഥാനപരമായി ഒന്നുതന്നെയാണെന്ന് നിങ്ങൾ മനസ്സിലാക്കുന്നു. ഡാറ്റാബേസിന് അതിന്റെ ഡാറ്റയുണ്ട് കൂടാതെ സ്കീമ മാനേജ് ചെയ്യണം. സ്കീമയിൽ വരുത്തിയ എല്ലാ മാറ്റങ്ങളും DDL-ൽ നേരിട്ട് നടപ്പിലാക്കണം, അങ്ങനെ സത്യത്തിന്റെ ഏക ഉറവിടം അപ്‌ഡേറ്റ് ചെയ്യപ്പെടും.

ഉറവിട അപ്‌ഡേറ്റ് സംഭവിക്കുമ്പോൾ, എല്ലാ ക്ലയന്റുകളും മോഡലിന്റെ പകർപ്പുകൾ അപ്‌ഡേറ്റ് ചെയ്യണം. ചില ക്ലയന്റുകൾ jOOQ, Hibernate അല്ലെങ്കിൽ JDBC (അല്ലെങ്കിൽ രണ്ടും) ഉപയോഗിച്ച് ജാവയിൽ എഴുതിയേക്കാം. മറ്റ് ക്ലയന്റുകൾ Perl-ൽ എഴുതിയേക്കാം (അവർക്ക് നമുക്ക് ആശംസകൾ നേരാം), മറ്റുള്ളവ C#-ൽ. സാരമില്ല. പ്രധാന മോഡൽ ഡാറ്റാബേസിലാണ്. ORM- ജനറേറ്റഡ് മോഡലുകൾ സാധാരണയായി മോശം ഗുണനിലവാരമുള്ളതും മോശമായി രേഖപ്പെടുത്തപ്പെട്ടതും വികസിപ്പിക്കാൻ ബുദ്ധിമുട്ടുള്ളതുമാണ്.

അതുകൊണ്ട് തെറ്റുകൾ വരുത്തരുത്. തുടക്കം മുതൽ തെറ്റുകൾ വരുത്തരുത്. ഒരു ഡാറ്റാബേസിൽ നിന്ന് പ്രവർത്തിക്കുക. ഓട്ടോമേറ്റ് ചെയ്യാൻ കഴിയുന്ന ഒരു വിന്യാസ പൈപ്പ്ലൈൻ നിർമ്മിക്കുക. നിങ്ങളുടെ ഡാറ്റാബേസ് മോഡൽ സൗകര്യപ്രദമായി പകർത്താനും ക്ലയന്റുകളിൽ ഇടാനും കോഡ് ജനറേറ്ററുകൾ പ്രവർത്തനക്ഷമമാക്കുക. കോഡ് ജനറേറ്ററുകളെ കുറിച്ച് ആകുലപ്പെടുന്നത് നിർത്തുക. അവർ നല്ലവരാണ്. അവരോടൊപ്പം, നിങ്ങൾ കൂടുതൽ ഉൽപ്പാദനക്ഷമതയുള്ളവരായിത്തീരും. തുടക്കം മുതൽ തന്നെ അവ സജ്ജീകരിക്കുന്നതിന് കുറച്ച് സമയം ചിലവഴിക്കുക മാത്രമാണ് നിങ്ങൾ ചെയ്യേണ്ടത്, നിങ്ങളുടെ പ്രോജക്റ്റിന്റെ സ്റ്റോറി നിർമ്മിക്കുന്നതിന് നിങ്ങൾക്ക് വർഷങ്ങളോളം മെച്ചപ്പെട്ട പ്രകടനം ഉണ്ടായിരിക്കും.

എന്നോട് നന്ദി പറയരുത്, പിന്നീട്.

വിശദീകരണം

വ്യക്തമായി പറഞ്ഞാൽ: നിങ്ങളുടെ ഡാറ്റാബേസ് മോഡലിന് അനുയോജ്യമായ രീതിയിൽ മുഴുവൻ സിസ്റ്റവും (അതായത്, ഡൊമെയ്ൻ, ബിസിനസ് ലോജിക്, മുതലായവ) വളച്ചൊടിക്കണമെന്ന് ഈ ലേഖനം ഒരു തരത്തിലും വാദിക്കുന്നില്ല. ഈ ലേഖനത്തിൽ ഞാൻ സംസാരിക്കുന്നത് ഒരു ഡാറ്റാബേസുമായി സംവദിക്കുന്ന ക്ലയന്റ് കോഡ് ഡാറ്റാബേസ് മോഡലിന്റെ അടിസ്ഥാനത്തിൽ പ്രവർത്തിക്കണം, അങ്ങനെ അത് ഡാറ്റാബേസ് മോഡലിനെ "ഫസ്റ്റ് ക്ലാസ്" സ്റ്റാറ്റസിൽ പുനർനിർമ്മിക്കില്ല. അത്തരം ലോജിക് സാധാരണയായി നിങ്ങളുടെ ക്ലയന്റിലുള്ള ഡാറ്റ ആക്സസ് ലെയറിലാണ് സ്ഥിതി ചെയ്യുന്നത്.

ചില സ്ഥലങ്ങളിൽ ഇപ്പോഴും സംരക്ഷിക്കപ്പെട്ടിരിക്കുന്ന ദ്വിതല വാസ്തുവിദ്യകളിൽ, അത്തരമൊരു സിസ്റ്റം മാതൃക മാത്രമേ സാധ്യമാകൂ. എന്നിരുന്നാലും, മിക്ക സിസ്റ്റങ്ങളിലും, ഡാറ്റ ആക്‌സസ് ലെയർ, ഡാറ്റാബേസ് മോഡലിനെ ഉൾക്കൊള്ളുന്ന ഒരു "ഉപസിസ്റ്റം" ആയി എനിക്ക് തോന്നുന്നു.

ഒഴിവാക്കലുകൾ

എല്ലാ നിയമങ്ങൾക്കും ഒഴിവാക്കലുകൾ ഉണ്ട്, ഡാറ്റാബേസ് ഫസ്റ്റ്, സോഴ്സ് കോഡ് ജനറേഷൻ സമീപനം ചിലപ്പോൾ അനുചിതമായേക്കാമെന്ന് ഞാൻ മുമ്പ് പറഞ്ഞിട്ടുണ്ട്. അത്തരം ചില ഒഴിവാക്കലുകൾ ഇതാ (മറ്റുള്ളവയും ഉണ്ട്):

• സ്കീമ അജ്ഞാതമാകുമ്പോൾ അത് തുറക്കേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, ഏതെങ്കിലും ഡയഗ്രം നാവിഗേറ്റ് ചെയ്യാൻ ഉപയോക്താക്കളെ സഹായിക്കുന്നതിന് നിങ്ങൾ ഒരു ടൂൾ നൽകുന്നു. ഫ്യൂ. ഇവിടെ കോഡ് ജനറേഷൻ ഇല്ല. എന്നിട്ടും - ഡാറ്റാബേസ് ആദ്യം.
• ചില പ്രശ്‌നങ്ങൾ പരിഹരിക്കാൻ ഈച്ചയിൽ ഒരു സർക്യൂട്ട് സൃഷ്ടിക്കേണ്ടിവരുമ്പോൾ. ഈ ഉദാഹരണം പാറ്റേണിന്റെ ചെറുതായി ചടുലമായ പതിപ്പാണെന്ന് തോന്നുന്നു എന്റിറ്റി ആട്രിബ്യൂട്ട് മൂല്യം, അതായത്, നിങ്ങൾക്ക് കൃത്യമായി നിർവചിക്കപ്പെട്ട ഒരു സ്കീമ ഇല്ല. ഈ സാഹചര്യത്തിൽ, ഒരു RDBMS നിങ്ങൾക്ക് അനുയോജ്യമാകുമെന്ന് നിങ്ങൾക്ക് പലപ്പോഴും ഉറപ്പുനൽകാൻ പോലും കഴിയില്ല.

ഒഴിവാക്കലുകൾ സ്വഭാവത്താൽ അസാധാരണമാണ്. ആർ‌ഡി‌ബി‌എം‌എസിന്റെ ഉപയോഗം ഉൾപ്പെടുന്ന മിക്ക കേസുകളിലും, സ്കീമ മുൻകൂട്ടി അറിയാം, അത് ആർ‌ഡി‌ബി‌എം‌എസിനുള്ളിലാണ്, മാത്രമല്ല "സത്യ"ത്തിന്റെ ഏക ഉറവിടവുമാണ്, കൂടാതെ എല്ലാ ക്ലയന്റുകളും അതിൽ നിന്ന് ഉരുത്തിരിഞ്ഞ പകർപ്പുകൾ നേടേണ്ടതുണ്ട്. എബൌട്ട്, ഇതിൽ ഒരു കോഡ് ജനറേറ്റർ ഉൾപ്പെട്ടിരിക്കണം.

അവലംബം: www.habr.com