प्रथम सत्य, किंवा डेटाबेस संरचनेवर आधारित सिस्टमची रचना का करणे आवश्यक आहे

अहो हाब्र!

आम्ही विषय एक्सप्लोर करणे सुरू ठेवतो जावा и वसंत ऋतूडेटाबेस स्तरावर समावेश. आज आम्ही मोठ्या ऍप्लिकेशन्सची रचना करताना, डेटाबेसची रचना का आहे, जावा कोड नाही, हे निर्णायक महत्त्वाचे का असावे, हे कसे केले जाते आणि या नियमाला कोणते अपवाद आहेत याबद्दल वाचण्याची ऑफर दिली आहे.

या ऐवजी उशीर झालेल्या लेखात, मी समजावून सांगेन की जवळजवळ सर्व प्रकरणांमध्ये, अनुप्रयोगातील डेटा मॉडेल "जावाच्या क्षमतांवरून" (किंवा आपण कोणतीही क्लायंट भाषा) ऐवजी "डेटाबेसमधून" डिझाइन केले पाहिजे असे मला का वाटते. सह काम करणे). दुसरा दृष्टीकोन निवडून, तुमचा प्रकल्प वाढू लागल्यावर तुम्ही वेदना आणि दुःखाच्या दीर्घ मार्गावर प्रवेश करता.

त्यावर आधारित लेख लिहिला होता एक प्रश्न, स्टॅक ओव्हरफ्लो वर दिले.

विभागांमध्ये reddit वर मनोरंजक चर्चा /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)) {
    // ...
}

कोड बिल्डच्या बाहेर मॅन्युअली किंवा प्रत्येक बिल्डवर मॅन्युअली व्युत्पन्न केला जातो. उदाहरणार्थ, अशा पुनरुत्पादनानंतर लगेच येऊ शकते फ्लायवे डेटाबेस स्थलांतर, जे व्यक्तिचलितपणे किंवा स्वयंचलितपणे देखील केले जाऊ शकते.

स्त्रोत कोड निर्मिती

कोड तयार करण्याच्या या पद्धतींशी संबंधित विविध तत्त्वज्ञान, फायदे आणि तोटे आहेत - मॅन्युअल आणि स्वयंचलित - ज्याची मी या लेखात तपशीलवार चर्चा करणार नाही. परंतु, सर्वसाधारणपणे, व्युत्पन्न केलेल्या कोडचा संपूर्ण मुद्दा असा आहे की ते तुम्हाला Java मध्ये "सत्य" पुनरुत्पादित करण्यास अनुमती देते जे आम्ही गृहीत धरतो, एकतर आमच्या सिस्टममध्ये किंवा त्याच्या बाहेर. एका अर्थाने, स्त्रोत कोडमधून बाइटकोड, मशीन कोड किंवा इतर काही प्रकारचे कोड व्युत्पन्न करणारे कंपाइलर हेच काम करतात - विशिष्ट कारणांची पर्वा न करता, आम्हाला दुसर्‍या भाषेत आमच्या "सत्य" चे प्रतिनिधित्व मिळते.

असे अनेक कोड जनरेटर आहेत. उदाहरणार्थ, XJC XSD किंवा WSDL फायलींवर आधारित Java कोड व्युत्पन्न करू शकते. तत्त्व नेहमी समान असते:

• काही सत्य (अंतर्गत किंवा बाह्य) आहे - उदाहरणार्थ, एक तपशील, डेटा मॉडेल इ.
• आम्हाला आमच्या प्रोग्रामिंग भाषेत या सत्याचे स्थानिक प्रतिनिधित्व आवश्यक आहे.

शिवाय, रिडंडंसी टाळण्यासाठी - असे प्रतिनिधित्व व्युत्पन्न करणे जवळजवळ नेहमीच उचित असते.

प्रकार प्रदाता आणि भाष्य प्रक्रिया

टीप: jOOQ साठी कोड निर्मितीसाठी आणखी एक, अधिक आधुनिक आणि विशिष्ट दृष्टीकोन प्रकार प्रदात्यांचा वापर समाविष्ट आहे, जसे ते F# मध्ये लागू केले आहेत. या प्रकरणात, कोड कंपाइलरद्वारे तयार केला जातो, प्रत्यक्षात संकलनाच्या टप्प्यावर. तत्वतः, असा कोड स्त्रोत कोडच्या स्वरूपात अस्तित्वात नाही. Java मध्ये, समान आहेत, जरी मोहक नसली तरी साधने - हे भाष्य प्रोसेसर आहेत, उदाहरणार्थ, लॉमबॉक.

एका विशिष्ट अर्थाने, येथे पहिल्या प्रकरणाप्रमाणेच घडतात, वगळता:

• तुम्हाला व्युत्पन्न केलेला कोड दिसत नाही (कदाचित ही परिस्थिती एखाद्याला इतकी तिरस्करणीय वाटत नाही?)
• आपण हे सुनिश्चित करणे आवश्यक आहे की प्रकार प्रदान केले जाऊ शकतात, म्हणजेच "सत्य" नेहमी उपलब्ध असणे आवश्यक आहे. लोम्बोकच्या बाबतीत हे सोपे आहे, जे "सत्य" भाष्य करते. नेहमी उपलब्ध असलेल्या थेट कनेक्शनवर अवलंबून असलेल्या डेटाबेस मॉडेल्ससह हे थोडे अधिक कठीण आहे.

कोड जनरेशनमध्ये काय समस्या आहे?

स्वहस्ते किंवा आपोआप कोड जनरेशन कसे सुरू करणे चांगले आहे या अवघड प्रश्नाव्यतिरिक्त, मला हे नमूद करावे लागेल की असे लोक आहेत जे मानतात की कोड निर्मितीची अजिबात गरज नाही. या दृष्टिकोनाचे औचित्य, जे मला बर्‍याचदा आढळले आहे, ते म्हणजे बिल्ड पाइपलाइन सेट करणे कठीण आहे. होय, हे खरोखर कठीण आहे. अतिरिक्त पायाभूत सुविधा खर्च आहेत. तुम्ही नुकतेच एखाद्या विशिष्ट उत्पादनासह सुरुवात करत असाल (मग ते jOOQ, किंवा JAXB, किंवा हायबरनेट इ.), वर्कबेंच सेट करण्यासाठी वेळ लागतो ज्याचे मूल्य मिळवण्यासाठी तुम्हाला स्वतः API शिकण्यात खर्च करायचा आहे. .

जनरेटरचे डिव्हाइस समजून घेण्याशी संबंधित खर्च खूप जास्त असल्यास, कोड जनरेटरच्या वापरण्यावर एपीआयने खराब काम केले (आणि भविष्यात असे दिसून आले की त्यात सानुकूलित करणे देखील अवघड आहे). अशा कोणत्याही API साठी उपयोगिता सर्वोच्च प्राधान्य असावी. पण कोड जनरेशन विरुद्ध तो फक्त एक युक्तिवाद आहे. अन्यथा, अंतर्गत किंवा बाह्य सत्याचे स्थानिक प्रतिनिधित्व पूर्णपणे हाताने लिहा.

हे सर्व करायला त्यांच्याकडे वेळ नाही, असे अनेकजण म्हणतील. ते त्यांच्या सुपर उत्पादनासाठी अंतिम मुदतीवर आहेत. नंतर कधीतरी आम्ही विधानसभा कन्व्हेयरना कंघी करू, आम्हाला वेळ मिळेल. मी त्यांना उत्तर देईन:

मूळ, अॅलन O'Rourke, प्रेक्षक स्टॅक

परंतु हायबरनेट/जेपीएमध्ये "जावामध्ये" कोड लिहिणे इतके सोपे आहे.

खरंच. हायबरनेट आणि त्याच्या वापरकर्त्यांसाठी, हे वरदान आणि शाप दोन्ही आहे. हायबरनेटमध्ये, तुम्ही फक्त दोन संस्था लिहू शकता, जसे की:

	@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 स्थलांतर स्क्रिप्ट, उदा. Flyway वापरणे. आणि या प्रकरणात आपल्या संस्थांचे काय होईल? तुम्ही एकतर त्यांना मॅन्युअली तयार करू शकता (आणि तुमचा कामाचा भार दुप्पट करू शकता) किंवा हायबरनेटने ते तुमच्यासाठी पुन्हा निर्माण करू शकता (तुमच्या अपेक्षा पूर्ण करण्यासाठी अशा प्रकारे व्युत्पन्न होण्याची शक्यता किती आहे?) तुम्ही दोन्ही मार्ग गमावाल.

अशा प्रकारे, तुम्ही उत्पादनात जाताच, तुम्हाला हॉट पॅचची आवश्यकता असेल. आणि ते फार लवकर उत्पादनात आणले जाणे आवश्यक आहे. तुम्ही उत्पादनासाठी तुमच्या स्थलांतराची गुळगुळीत पाइपलाइनिंग तयार आणि व्यवस्थित केली नसल्यामुळे, तुम्ही बिनधास्तपणे पॅचिंग करत आहात. आणि मग तुमच्याकडे सर्वकाही बरोबर करण्यासाठी वेळ नाही. आणि आपण हायबरनेटला फटकारतो, कारण ही नेहमीच कोणाचीही चूक असते, परंतु तुमची नाही ...

त्याऐवजी, अगदी सुरुवातीपासून, सर्वकाही पूर्णपणे वेगळ्या पद्धतीने केले जाऊ शकते. उदाहरणार्थ, सायकलवर गोल चाके लावा.

प्रथम डेटाबेस

तुमच्या डेटाबेस स्कीमामधील खरे "सत्य" आणि त्यावर "सार्वभौमत्व" डेटाबेसमध्ये आहे. स्कीमा केवळ डेटाबेसमध्येच परिभाषित केला जातो आणि इतर कोठेही नाही, आणि प्रत्येक क्लायंटकडे या स्कीमाची एक प्रत आहे, त्यामुळे स्कीमा आणि त्याच्या अखंडतेचे पालन करणे, डेटाबेसमध्ये ते योग्यरित्या करणे योग्य आहे - जेथे माहिती साठवली जाते.
हे अगदी जुने शहाणपण आहे. प्राथमिक आणि अद्वितीय की चांगल्या आहेत. परदेशी कळा ठीक आहेत. प्रतिबंध तपासणी चांगली आहे. निवेदने - ठीक आहे.

आणि, एवढेच नाही. उदाहरणार्थ, ओरॅकल वापरून, आपण कदाचित निर्दिष्ट करू इच्छित असाल:

• तुमचे टेबल कोणत्या टेबलस्पेसमध्ये आहे
• तिचे PCTFREE मूल्य काय आहे
• तुमच्या क्रमातील कॅशेचा आकार किती आहे (आयडीच्या मागे)

छोट्या सिस्टीममध्ये हे सर्व काही फरक पडत नाही, परंतु "मोठ्या डेटा" च्या क्षेत्रामध्ये संक्रमण होईपर्यंत प्रतीक्षा करणे आवश्यक नाही - आपण वर उल्लेख केलेल्या विक्रेत्या-प्रदान केलेल्या स्टोरेज ऑप्टिमायझेशनचा लाभ घेण्यास सुरुवात करू शकता, जसे की वर नमूद केले आहे. मी पाहिलेले कोणतेही ORM (jOOQ सह) तुम्हाला तुमच्या डेटाबेसमध्ये वापरू इच्छित असलेल्या DDL पर्यायांच्या संपूर्ण सेटमध्ये प्रवेश प्रदान करत नाहीत. ORM तुम्हाला 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 किंवा 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 चांगली आवृत्ती आहे आणि अत्यंत मागास सुसंगत आहे
• XSD चे XJC वापरून Java कोडमध्ये भाषांतर केले जाऊ शकते

शेवटचा मुद्दा महत्त्वाचा आहे. XML संदेश वापरून बाह्य प्रणालीशी संप्रेषण करताना, आमचे संदेश वैध आहेत याची आम्ही खात्री करू इच्छितो. JAXB, XJC आणि XSD सह हे साध्य करणे खूप सोपे आहे. जावा-फर्स्ट डिझाईन पध्दतीत जिथे आपण जावा ऑब्जेक्ट्स म्हणून आपले संदेश बनवतो, ते XML ला सुगमपणे रेंडर केले जाऊ शकतात आणि दुसर्‍या सिस्टमला वापरण्यासाठी पाठवले जाऊ शकतात असा विचार करणे निव्वळ वेडेपणाचे ठरेल. अशाप्रकारे व्युत्पन्न केलेले XML अत्यंत निकृष्ट दर्जाचे, कागदोपत्री नसलेले आणि विकसित करणे कठीण असेल. अशा इंटरफेसवर सेवा गुणवत्तेच्या (एसएलए) स्तरावर करार असल्यास, आम्ही ते त्वरित खराब करू.

खरे सांगायचे तर, जेएसओएन एपीआय सह नेहमीच असेच घडते, परंतु ती दुसरी कथा आहे, मी पुढच्या वेळी वाद घालेन ...

डेटाबेस: ते समान आहेत

डेटाबेससह कार्य करताना, आपण समजता की ते सर्व मूलतः समान आहेत. डेटाबेस त्याच्या डेटाचे मालक आहे आणि स्कीमा व्यवस्थापित करणे आवश्यक आहे. स्कीमामध्ये केलेले कोणतेही बदल थेट DDL मध्ये लागू केले जाणे आवश्यक आहे जेणेकरुन सत्याचा एकल स्रोत अद्यतनित केला जाईल.

जेव्हा स्त्रोत अद्यतन होते, तेव्हा सर्व क्लायंटने त्यांच्या मॉडेलच्या प्रती देखील अद्यतनित केल्या पाहिजेत. काही क्लायंट jOOQ आणि हायबरनेट किंवा JDBC (किंवा दोन्ही) वापरून Java मध्ये लिहिले जाऊ शकतात. इतर क्लायंट पर्लमध्ये लिहिले जाऊ शकतात (त्यांना शुभेच्छा देऊया), इतर C# मध्ये. काही फरक पडत नाही. मुख्य मॉडेल डेटाबेसमध्ये आहे. ORM-व्युत्पन्न केलेले मॉडेल सामान्यत: खराब दर्जाचे, खराब दस्तऐवजीकरण केलेले आणि विकसित करणे कठीण असते.

त्यामुळे चुका करू नका. सुरुवातीपासूनच चुका करू नका. डेटाबेसमधून कार्य करा. एक उपयोजन पाइपलाइन तयार करा जी स्वयंचलित असू शकते. तुमचा डेटाबेस मॉडेल सोयीस्करपणे कॉपी करण्यासाठी आणि क्लायंटवर डंप करण्यासाठी कोड जनरेटर सक्षम करा. आणि कोड जनरेटरबद्दल काळजी करणे थांबवा. ते चांगले आहे. त्यांच्यासह, आपण अधिक उत्पादक व्हाल. तुम्हाला फक्त सुरुवातीपासूनच त्यांना सेट करण्यात थोडा वेळ घालवायचा आहे आणि तुमच्या प्रोजेक्टची कथा तयार करण्यासाठी तुमच्याकडे अनेक वर्षे सुधारित कार्यप्रदर्शन असेल.

नंतर माझे आभार मानू नका.

स्पष्टीकरण

स्पष्ट होण्यासाठी: हा लेख कोणत्याही प्रकारे संपूर्ण प्रणाली (म्हणजे डोमेन, व्यवसाय तर्क, इ. इ.) आपल्या डेटाबेस मॉडेलमध्ये बसण्यासाठी वाकवणे आवश्यक असल्याचे समर्थन करत नाही. मी या लेखात ज्याबद्दल बोलत आहे ते म्हणजे डेटाबेसशी संवाद साधणारा क्लायंट कोड डेटाबेस मॉडेलच्या आधारावर कार्य करतो जेणेकरून ते डेटाबेस मॉडेलला "प्रथम श्रेणी" स्थितीत पुनरुत्पादित करू शकत नाही. असे लॉजिक सहसा तुमच्या क्लायंटवरील डेटा ऍक्सेस लेयरमध्ये असते.

दोन-स्तरीय आर्किटेक्चरमध्ये, जे अजूनही काही ठिकाणी संरक्षित आहेत, अशा प्रणालीचे मॉडेल एकमेव शक्य आहे. तथापि, बर्‍याच प्रणालींमध्ये, डेटा ऍक्सेस लेयर मला "सबसिस्टम" असल्याचे दिसते जे डेटाबेस मॉडेलचे अंतर्भूत करते.

अपवाद

प्रत्येक नियमाला अपवाद आहेत आणि मी आधी सांगितले आहे की डेटाबेस फर्स्ट आणि सोर्स कोड जनरेशनचा दृष्टीकोन कधी कधी अयोग्य असू शकतो. येथे असे काही अपवाद आहेत (कदाचित इतर आहेत):

• जेव्हा स्कीमा अज्ञात असते आणि उघडणे आवश्यक असते. उदाहरणार्थ, तुम्ही वापरकर्त्यांना कोणत्याही आकृतीमध्ये नेव्हिगेट करण्यात मदत करण्यासाठी एक साधन प्रदान करता. ओफ. इथे कोड जनरेशन नाही. पण तरीही - सर्व प्रथम डेटाबेस.
• जेव्हा एखादी समस्या सोडवण्यासाठी फ्लायवर सर्किट तयार करणे आवश्यक असते. हे उदाहरण पॅटर्नची किंचित चपखल आवृत्ती असल्याचे दिसते अस्तित्व गुणधर्म मूल्य, म्हणजे, तुमच्याकडे खरोखरच सु-परिभाषित स्कीमा नाही. या प्रकरणात, आपण अनेकदा खात्री देखील करू शकत नाही की RDBMS आपल्यास अनुकूल असेल.

अपवाद स्वभावाने अपवादात्मक आहेत. RDBMS च्या वापराचा समावेश असलेल्या बहुतेक प्रकरणांमध्ये, स्कीमा आधीच ओळखला जातो, तो RDBMS च्या आत असतो आणि "सत्य" चा एकमेव स्त्रोत असतो आणि सर्व क्लायंटना त्यातून काढलेल्या प्रती प्राप्त कराव्या लागतात. आदर्शपणे, यामध्ये कोड जनरेटरचा समावेश असावा.

स्त्रोत: www.habr.com