మొదట నిజం, లేదా డేటాబేస్ నిర్మాణం ఆధారంగా సిస్టమ్‌ను ఎందుకు రూపొందించాలి

హే హబ్ర్!

మేము అంశాన్ని అన్వేషించడం కొనసాగిస్తున్నాము జావా и స్ప్రింగ్డేటాబేస్ స్థాయిలో సహా. ఈ రోజు మనం పెద్ద అప్లికేషన్‌లను డిజైన్ చేసేటప్పుడు, డేటాబేస్ నిర్మాణం ఎందుకు, మరియు జావా కోడ్ కాదు, ఇది నిర్ణయాత్మక ప్రాముఖ్యత కలిగి ఉండాలి, ఇది ఎలా జరుగుతుంది మరియు ఈ నియమానికి మినహాయింపులు ఏమిటి అనే దాని గురించి చదవడానికి మేము అందిస్తున్నాము.

చాలా ఆలస్యంగా వచ్చిన ఈ కథనంలో, దాదాపు అన్ని సందర్భాల్లో, అప్లికేషన్‌లోని డేటా మోడల్‌ను "జావా సామర్థ్యాల నుండి" కాకుండా "డేటాబేస్ నుండి" రూపొందించాలని నేను ఎందుకు అనుకుంటున్నానో వివరిస్తాను (లేదా మీరు ఏ క్లయింట్ భాష అయినా పని చేయడం). రెండవ విధానాన్ని ఎంచుకోవడం ద్వారా, మీ ప్రాజెక్ట్ పెరగడం ప్రారంభించిన తర్వాత మీరు నొప్పి మరియు బాధల యొక్క సుదీర్ఘ మార్గంలోకి ప్రవేశిస్తారు.

అనే అంశాల ఆధారంగా వ్యాసం రాశారు ఒక ప్రశ్న, స్టాక్ ఓవర్‌ఫ్లో ఇవ్వబడింది.

విభాగాల్లో రెడ్డిట్‌పై ఆసక్తికరమైన చర్చలు /r/java и /r/ప్రోగ్రామింగ్.

కోడ్ ఉత్పత్తి

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, లేదా హైబర్నేట్, మొదలైనవి కావచ్చు), దాని నుండి విలువను పొందడానికి మీరు APIని నేర్చుకోవడానికి వెచ్చించాలనుకుంటున్న వర్క్‌బెంచ్‌ను సెటప్ చేయడానికి సమయం పడుతుంది. .

జనరేటర్ యొక్క పరికరాన్ని అర్థం చేసుకోవడానికి సంబంధించిన ఖర్చులు చాలా ఎక్కువగా ఉంటే, వాస్తవానికి, కోడ్ జెనరేటర్ యొక్క వినియోగంపై API పేలవమైన పని చేసింది (మరియు భవిష్యత్తులో దానిలో అనుకూలీకరణ కూడా కష్టమని తేలింది). అటువంటి APIకి వినియోగానికి అత్యధిక ప్రాధాన్యత ఇవ్వాలి. కానీ అది కోడ్ ఉత్పత్తికి వ్యతిరేకంగా కేవలం ఒక వాదన. లేకపోతే, అంతర్గత లేదా బాహ్య సత్యం యొక్క స్థానిక ప్రాతినిధ్యాన్ని పూర్తిగా చేతితో రాయండి.

ఇవన్నీ చేయడానికి తమకు సమయం లేదని చాలా మంది చెబుతారు. వారు తమ సూపర్ ఉత్పత్తి కోసం గడువులో ఉన్నారు. ఏదో ఒక రోజు తర్వాత మేము అసెంబ్లీ కన్వేయర్లను దువ్వెన చేస్తాము, మాకు సమయం ఉంటుంది. నేను వారికి సమాధానం ఇస్తాను:

అసలు, అలాన్ ఓ'రూర్కే, ఆడియన్స్ స్టాక్

కానీ హైబర్నేట్ / JPAలో "జావాలో" కోడ్ రాయడం చాలా సులభం.

నిజంగా. హైబర్నేట్ మరియు దాని వినియోగదారులకు, ఇది ఒక వరం మరియు శాపం. హైబర్నేట్‌లో, మీరు ఇలా రెండు ఎంటిటీలను వ్రాయవచ్చు:

	@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 మైగ్రేషన్ స్క్రిప్ట్‌లు, ఉదా. ఫ్లైవేని ఉపయోగించడం. మరియు ఈ సందర్భంలో మీ సంస్థలకు ఏమి జరుగుతుంది? మీరు వాటిని మాన్యువల్‌గా సరిచేయవచ్చు (మరియు మీ పనిభారాన్ని రెట్టింపు చేయవచ్చు) లేదా హైబర్నేట్ మీ కోసం వాటిని పునరుద్ధరించవచ్చు (మీ అంచనాలను అందుకోవడానికి ఈ విధంగా రూపొందించబడినది ఎంత అవకాశం ఉంది?) మీరు ఏ విధంగానైనా కోల్పోతారు.

అందువలన, మీరు ఉత్పత్తికి వెళ్ళిన వెంటనే, మీకు వేడి పాచెస్ అవసరం. మరియు వారు చాలా త్వరగా ఉత్పత్తికి తీసుకురావాలి. మీరు ఉత్పత్తి కోసం మీ మైగ్రేషన్‌ల యొక్క మృదువైన పైప్‌లైన్‌ను సిద్ధం చేసి నిర్వహించనందున, మీరు విపరీతంగా పాచ్ చేస్తున్నారు. ఆపై ప్రతిదీ సరిగ్గా చేయడానికి మీకు సమయం లేదు. మరియు మీరు హైబర్నేట్‌ని తిట్టారు, ఎందుకంటే ఇది ఎల్లప్పుడూ ఎవరి తప్పు, కానీ మీరు కాదు ...

బదులుగా, చాలా మొదటి నుండి, ప్రతిదీ పూర్తిగా భిన్నంగా చేయవచ్చు. ఉదాహరణకు, సైకిల్‌పై రౌండ్ వీల్స్ ఉంచండి.

ముందుగా డేటాబేస్

మీ డేటాబేస్ స్కీమాలోని నిజమైన "సత్యం" మరియు దానిపై "సార్వభౌమాధికారం" డేటాబేస్‌లోనే ఉన్నాయి. స్కీమా అనేది డేటాబేస్‌లో మాత్రమే నిర్వచించబడింది మరియు మరెక్కడా లేదు, మరియు ప్రతి క్లయింట్‌లు ఈ స్కీమా యొక్క కాపీని కలిగి ఉంటారు, కాబట్టి స్కీమా మరియు దాని సమగ్రతకు కట్టుబడి, డేటాబేస్‌లోనే దీన్ని చేయడానికి ఇది ఖచ్చితమైన అర్ధమే - ఇక్కడ సమాచారం నిల్వ చేయబడుతుంది.
ఇది పాతది కూడా హాక్నీడ్ జ్ఞానం. ప్రాథమిక మరియు ఏకైక కీలు బాగున్నాయి. విదేశీ కీలు బాగానే ఉన్నాయి. నిర్బంధ తనిఖీ మంచిది. వాదనలు - బాగానే ఉంది.

మరియు, అంతే కాదు. ఉదాహరణకు, ఒరాకిల్ ఉపయోగించి, మీరు బహుశా పేర్కొనవచ్చు:

• మీ టేబుల్ ఏ టేబుల్ స్పేస్‌లో ఉంది
• ఆమె 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 మెటా-మాడ్యూల్ ఉపయోగించి.

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

• మీరు JDBC లేదా స్ప్రింగ్‌ని ఉపయోగిస్తుంటే, మీరు స్ట్రింగ్ స్థిరాంకాల సమితిని సృష్టించవచ్చు
• మీరు 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ని జావా కోడ్‌లోకి అనువదించవచ్చు

చివరి పాయింట్ ముఖ్యమైనది. XML సందేశాలను ఉపయోగించి బాహ్య సిస్టమ్‌తో కమ్యూనికేట్ చేస్తున్నప్పుడు, మా సందేశాలు చెల్లుబాటు అయ్యేవని మేము నిర్ధారించుకోవాలనుకుంటున్నాము. JAXB, XJC మరియు XSDతో దీన్ని సాధించడం చాలా సులభం. మన సందేశాలను జావా ఆబ్జెక్ట్‌లుగా తయారుచేసే జావా-ఫస్ట్ డిజైన్ విధానంలో, అవి ఏదో ఒకవిధంగా XMLకి అర్థమయ్యేలా రెండర్ చేయబడి, మరొక సిస్టమ్‌కు వినియోగం కోసం పంపబడతాయని అనుకోవడం పూర్తిగా పిచ్చిగా ఉంటుంది. ఈ విధంగా ఉత్పత్తి చేయబడిన XML చాలా తక్కువ నాణ్యతతో ఉంటుంది, డాక్యుమెంట్ లేనిది మరియు అభివృద్ధి చేయడం కష్టం. అటువంటి ఇంటర్‌ఫేస్‌లో సేవా నాణ్యత (SLA) స్థాయిపై ఒప్పందం ఉన్నట్లయితే, మేము దానిని వెంటనే స్క్రూ చేస్తాము.

నిజం చెప్పాలంటే, JSON APIతో ఇది ఎల్లప్పుడూ జరుగుతుంది, కానీ ఇది మరొక కథ, నేను తదుపరిసారి వాదిస్తాను ...

డేటాబేస్‌లు: అవి ఒకటే

డేటాబేస్‌లతో పని చేయడం, అవన్నీ ప్రాథమికంగా ఒకే విధంగా ఉన్నాయని మీరు అర్థం చేసుకున్నారు. డేటాబేస్ దాని డేటాను కలిగి ఉంది మరియు తప్పనిసరిగా స్కీమాను నిర్వహించాలి. స్కీమాకు చేసిన ఏవైనా సవరణలు తప్పనిసరిగా DDLలో అమలు చేయబడాలి, తద్వారా నిజం యొక్క ఏకైక మూలం నవీకరించబడుతుంది.

సోర్స్ అప్‌డేట్ జరిగినప్పుడు, క్లయింట్‌లందరూ తప్పనిసరిగా మోడల్ కాపీలను కూడా అప్‌డేట్ చేయాలి. కొంతమంది క్లయింట్లు jOOQ మరియు హైబర్నేట్ లేదా JDBC (లేదా రెండూ) ఉపయోగించి జావాలో వ్రాయబడవచ్చు. ఇతర క్లయింట్‌లు పెర్ల్‌లో వ్రాయబడి ఉండవచ్చు (వారి అదృష్టం కోరుకుందాం), ఇతరులు C#లో వ్రాయబడవచ్చు. పర్వాలేదు. ప్రధాన మోడల్ డేటాబేస్లో ఉంది. ORM-ఉత్పత్తి చేయబడిన నమూనాలు సాధారణంగా నాణ్యత లేనివి, పేలవంగా డాక్యుమెంట్ చేయబడవు మరియు అభివృద్ధి చేయడం కష్టం.

కాబట్టి తప్పులు చేయవద్దు. మొదటి నుండి తప్పులు చేయవద్దు. డేటాబేస్ నుండి పని చేయండి. స్వయంచాలకంగా ఉండే విస్తరణ పైప్‌లైన్‌ను రూపొందించండి. మీ డేటాబేస్ మోడల్‌ను సౌకర్యవంతంగా కాపీ చేయడానికి మరియు క్లయింట్‌లపై డంప్ చేయడానికి కోడ్ జనరేటర్‌లను ప్రారంభించండి. మరియు కోడ్ జనరేటర్ల గురించి చింతించడం మానేయండి. వాళ్ళు మంచివారు. వారితో, మీరు మరింత ఉత్పాదకత పొందుతారు. మీరు చేయవలసిందల్లా ప్రారంభం నుండి వాటిని సెటప్ చేయడానికి కొంచెం సమయం వెచ్చించండి మరియు మీ ప్రాజెక్ట్ కథనాన్ని రూపొందించడానికి మీరు సంవత్సరాల మెరుగైన పనితీరును కలిగి ఉంటారు.

నాకు ఇంకా ధన్యవాదాలు చెప్పవద్దు, తర్వాత.

స్పష్టీకరణ

స్పష్టంగా చెప్పాలంటే: మీ డేటాబేస్ మోడల్‌కు సరిపోయేలా మొత్తం సిస్టమ్ (అంటే, డొమైన్, బిజినెస్ లాజిక్, మొదలైనవి, మొదలైనవి) వంచుగా ఉండాలని ఈ కథనం ఏ విధంగానూ సూచించదు. ఈ కథనంలో నేను మాట్లాడుతున్నది ఏమిటంటే, డేటాబేస్‌తో పరస్పర చర్య చేసే క్లయింట్ కోడ్ డేటాబేస్ మోడల్ ఆధారంగా పని చేయాలి, తద్వారా ఇది డేటాబేస్ మోడల్‌ను "ఫస్ట్ క్లాస్" స్థితిలో పునరుత్పత్తి చేయదు. ఇటువంటి లాజిక్ సాధారణంగా మీ క్లయింట్‌లోని డేటా యాక్సెస్ లేయర్‌లో ఉంటుంది.

కొన్ని ప్రదేశాలలో ఇప్పటికీ భద్రపరచబడిన రెండు-స్థాయి నిర్మాణాలలో, అటువంటి వ్యవస్థ నమూనా మాత్రమే సాధ్యమవుతుంది. అయినప్పటికీ, చాలా సిస్టమ్‌లలో, డేటా యాక్సెస్ లేయర్ అనేది డేటాబేస్ మోడల్‌ను ఎన్‌క్యాప్సులేట్ చేసే "సబ్‌సిస్టమ్"గా నాకు అనిపిస్తోంది.

మినహాయింపులు

ప్రతి నియమానికి మినహాయింపులు ఉన్నాయి మరియు మొదటి డేటాబేస్ మరియు సోర్స్ కోడ్ ఉత్పత్తి విధానం కొన్నిసార్లు సరికాదని నేను ముందే చెప్పాను. అలాంటి కొన్ని మినహాయింపులు ఇక్కడ ఉన్నాయి (బహుశా ఇతరులు ఉండవచ్చు):

• స్కీమా తెలియనప్పుడు మరియు తెరవాల్సిన అవసరం ఉన్నప్పుడు. ఉదాహరణకు, మీరు ఏదైనా రేఖాచిత్రాన్ని నావిగేట్ చేయడంలో వినియోగదారులకు సహాయపడే సాధనాన్ని అందిస్తారు. ఫ్యూ. ఇక్కడ కోడ్ జనరేషన్ లేదు. కానీ ఇప్పటికీ - అన్ని మొదటి డేటాబేస్.
• కొన్ని సమస్యను పరిష్కరించడానికి ఫ్లైలో సర్క్యూట్‌ను రూపొందించాల్సిన అవసరం వచ్చినప్పుడు. ఈ ఉదాహరణ నమూనా యొక్క కొద్దిగా చురుకైన సంస్కరణగా కనిపిస్తుంది ఎంటిటీ లక్షణం విలువ, అంటే, మీకు నిజంగా బాగా నిర్వచించబడిన స్కీమా లేదు. ఈ సందర్భంలో, RDBMS మీకు సరిపోతుందని మీరు తరచుగా ఖచ్చితంగా చెప్పలేరు.

మినహాయింపులు సహజంగా అసాధారణమైనవి. RDBMS వినియోగానికి సంబంధించిన చాలా సందర్భాలలో, స్కీమా ముందుగానే తెలుసు, ఇది RDBMS లోపల ఉంది మరియు "సత్యం" యొక్క ఏకైక మూలం, మరియు క్లయింట్లందరూ దాని నుండి పొందిన కాపీలను పొందవలసి ఉంటుంది. ఆదర్శవంతంగా, ఇది కోడ్ జనరేటర్‌ను కలిగి ఉండాలి.

మూలం: www.habr.com