सत्य पहले, या सिस्टम को डेटाबेस संरचना के आधार पर डिज़ाइन करने की आवश्यकता क्यों है

हे हबर!

हम विषय पर शोध करना जारी रखते हैं जावा и वसंत, जिसमें डेटाबेस स्तर भी शामिल है। आज हम आपको इस बारे में पढ़ने के लिए आमंत्रित करते हैं कि क्यों, बड़े अनुप्रयोगों को डिज़ाइन करते समय, यह डेटाबेस संरचना है, न कि जावा कोड, जो निर्णायक महत्व का होना चाहिए, यह कैसे किया जाता है, और इस नियम के क्या अपवाद हैं।

इस देर के लेख में, मैं समझाऊंगा कि मेरा मानना ​​​​है कि लगभग सभी मामलों में, किसी एप्लिकेशन में डेटा मॉडल को "जावा की क्षमताओं" (या जो भी क्लाइंट भाषा आप हैं) के बजाय "डेटाबेस से" डिज़ाइन किया जाना चाहिए के साथ काम करना)। दूसरा तरीका अपनाकर, आप अपने प्रोजेक्ट के बढ़ने के बाद खुद को दर्द और पीड़ा के लंबे रास्ते के लिए तैयार कर रहे हैं।

लेख के आधार पर लिखा गया था एक सवाल, स्टैक ओवरफ्लो पर दिया गया है।

रेडिट पर अनुभागों में दिलचस्प चर्चाएँ /आर/जावा и / आर / प्रोग्रामिंग.

कोड जनरेशन

मुझे यह देखकर कितना आश्चर्य हुआ कि उपयोगकर्ताओं का एक छोटा सा वर्ग, जो 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# में लागू किया गया है. इस मामले में, कोड वास्तव में संकलन चरण में, संकलक द्वारा उत्पन्न होता है। सिद्धांत रूप में, ऐसा कोड स्रोत रूप में मौजूद नहीं है। जावा में समान, हालांकि उतने सुंदर नहीं, उपकरण हैं - एनोटेशन प्रोसेसर, उदाहरण के लिए, Lombok.

एक तरह से, यहाँ भी वही चीजें होती हैं जो पहले मामले में थीं, अपवाद के साथ:

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

कोड जनरेशन में क्या समस्या है?

कोड जनरेशन को सर्वोत्तम तरीके से कैसे चलाया जाए - मैन्युअल रूप से या स्वचालित रूप से, इस पेचीदा सवाल के अलावा, हमें यह भी उल्लेख करना होगा कि ऐसे लोग हैं जो मानते हैं कि कोड जनरेशन की बिल्कुल भी आवश्यकता नहीं है। इस दृष्टिकोण का औचित्य, जो मुझे सबसे अधिक बार मिला, वह यह है कि तब बिल्ड पाइपलाइन स्थापित करना कठिन होता है। हाँ, यह सचमुच कठिन है। अतिरिक्त बुनियादी ढांचे की लागत उत्पन्न होती है। यदि आप अभी किसी विशेष उत्पाद (चाहे वह jOOQ, या JAXB, या हाइबरनेट, आदि) के साथ शुरुआत कर रहे हैं, तो उत्पादन वातावरण स्थापित करने में समय लगता है जिसे आप एपीआई सीखने में ही खर्च करना चाहेंगे ताकि आप इससे मूल्य निकाल सकें। .

यदि जनरेटर की संरचना को समझने से जुड़ी लागत बहुत अधिक है, तो, वास्तव में, एपीआई ने कोड जनरेटर की उपयोगिता पर खराब काम किया है (और बाद में पता चला कि इसमें उपयोगकर्ता अनुकूलन भी जटिल है)। ऐसे किसी भी एपीआई के लिए उपयोगिता सर्वोच्च प्राथमिकता होनी चाहिए। लेकिन यह कोड जनरेशन के ख़िलाफ़ सिर्फ़ एक तर्क है। अन्यथा, आंतरिक या बाह्य सत्य का स्थानीय प्रतिनिधित्व लिखना पूरी तरह से मैनुअल है।

कई लोग कहेंगे कि उनके पास यह सब करने का समय नहीं है। उनके सुपर उत्पाद की समय सीमा समाप्त हो रही है। किसी दिन हम असेंबली कन्वेयर को साफ कर देंगे, हमारे पास समय होगा। मैं उन्हें उत्तर दूंगा:

मूल, एलन ओ'रूर्के, ऑडियंस स्टैक

लेकिन हाइबरनेट/जेपीए में जावा कोड लिखना बहुत आसान है।

वास्तव में। हाइबरनेट और उसके उपयोगकर्ताओं के लिए, यह आशीर्वाद और अभिशाप दोनों है। हाइबरनेट में आप बस कुछ इकाइयाँ लिख सकते हैं, जैसे:

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

और लगभग सब कुछ तैयार है. अब यह हाइबरनेट पर निर्भर है कि वह आपके एसक्यूएल "बोली" के डीडीएल में इस इकाई को कैसे परिभाषित किया जाएगा, इसका जटिल "विवरण" उत्पन्न करेगा:

	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;
}

ठंडा। पुनर्जीवित करें. फिर, इस मामले में शुरुआत में यह बहुत आसान होगा।

लेकिन आपको इसके लिए बाद में भुगतान करना होगा

देर-सबेर आपको उत्पादन में जाना ही होगा। तभी यह मॉडल काम करना बंद कर देगा. क्योंकि:

उत्पादन में, यदि आवश्यक हो, तो पुराने डेटाबेस को त्यागना और नए सिरे से शुरू करना अब संभव नहीं होगा। आपका डेटाबेस विरासत बन जाएगा.

अब से लेकर हमेशा तक तुम्हें लिखना ही पड़ेगा उदाहरण के लिए, फ्लाईवे का उपयोग करते हुए डीडीएल माइग्रेशन स्क्रिप्ट. इस मामले में आपकी संस्थाओं का क्या होगा? आप या तो उन्हें मैन्युअल रूप से अनुकूलित कर सकते हैं (और इस प्रकार अपना कार्यभार दोगुना कर सकते हैं), या आप हाइबरनेट को उन्हें आपके लिए पुनर्जीवित करने के लिए कह सकते हैं (इस तरह से उत्पन्न होने वाले आपकी अपेक्षाओं को पूरा करने की कितनी संभावना है?) किसी भी तरह से, आप हार जाते हैं।

इसलिए एक बार जब आप उत्पादन शुरू कर देंगे तो आपको हॉट पैच की आवश्यकता होगी। और उन्हें बहुत जल्दी उत्पादन में लाने की आवश्यकता है। चूँकि आपने तैयारी नहीं की और उत्पादन के लिए अपने प्रवासन की एक सुचारु पाइपलाइन व्यवस्थित नहीं की, आप बेतहाशा सब कुछ पैच कर देते हैं। और फिर आपके पास सब कुछ सही ढंग से करने का समय नहीं रहेगा। और आप हाइबरनेट की आलोचना करते हैं, क्योंकि यह हमेशा किसी और की गलती होती है, सिर्फ आपकी नहीं...

इसके बजाय, चीज़ें शुरू से ही पूरी तरह से अलग तरीके से की जा सकती थीं। उदाहरण के लिए, साइकिल पर गोल पहिये लगाएं।

सबसे पहले डेटाबेस

आपके डेटाबेस स्कीमा में वास्तविक "सच्चाई" और उस पर "संप्रभुता" डेटाबेस के भीतर निहित है। स्कीमा को केवल डेटाबेस में ही परिभाषित किया गया है और कहीं नहीं, और प्रत्येक क्लाइंट के पास इस स्कीमा की एक प्रति है, इसलिए स्कीमा और इसकी अखंडता के अनुपालन को लागू करना, इसे डेटाबेस में सही तरीके से करना सही समझ में आता है - जहां जानकारी है संग्रहित.
यह पुराना, यहाँ तक कि घिसा-पिटा ज्ञान भी है। प्राथमिक और अद्वितीय कुंजियाँ अच्छी हैं. विदेशी कुंजियाँ अच्छी हैं. प्रतिबंधों की जाँच करना अच्छा है. अनुमोदन - अच्छा।

इसके अलावा, इतना ही नहीं है. उदाहरण के लिए, Oracle का उपयोग करते हुए, आप संभवतः यह निर्दिष्ट करना चाहेंगे:

• आपकी टेबल किस टेबलस्पेस में है?
• इसका PCTFREE मूल्य क्या है?
• आपके अनुक्रम में कैश आकार क्या है (आईडी के पीछे)

यह छोटी प्रणालियों में महत्वपूर्ण नहीं हो सकता है, लेकिन आपको बड़े डेटा क्षेत्र में जाने तक इंतजार करने की ज़रूरत नहीं है - आप विक्रेता द्वारा प्रदान किए गए भंडारण अनुकूलन से लाभ उठाना शुरू कर सकते हैं जैसे कि ऊपर उल्लिखित हैं। मेरे द्वारा देखे गए कोई भी ORM (jOOQ सहित) 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 मेटा-मॉड्यूल का उपयोग करके।

ऐसे प्रश्नों के परिणामों से, आपके डेटाबेस मॉडल का कोई भी क्लाइंट-साइड प्रतिनिधित्व उत्पन्न करना अपेक्षाकृत आसान है, भले ही आप क्लाइंट पर किस तकनीक का उपयोग करते हों।

• यदि आप जेडीबीसी या स्प्रिंग का उपयोग कर रहे हैं, तो आप स्ट्रिंग स्थिरांक का एक सेट बना सकते हैं
• यदि आप जेपीए का उपयोग करते हैं, तो आप इकाइयां स्वयं उत्पन्न कर सकते हैं
• यदि आप jOOQ का उपयोग करते हैं, तो आप jOOQ मेटा-मॉडल उत्पन्न कर सकते हैं

आपके क्लाइंट एपीआई (उदाहरण के लिए jOOQ या JPA) द्वारा कितनी कार्यक्षमता की पेशकश की जाती है, इसके आधार पर, जेनरेट किया गया मेटा मॉडल वास्तव में समृद्ध और पूर्ण हो सकता है। उदाहरण के लिए, अंतर्निहित जुड़ाव की संभावना को लें, jOOQ 3.11 में पेश किया गया, जो आपकी तालिकाओं के बीच मौजूद विदेशी कुंजी संबंधों के बारे में उत्पन्न मेटा जानकारी पर निर्भर करता है।

अब कोई भी डेटाबेस वृद्धि स्वचालित रूप से क्लाइंट कोड को अपडेट कर देगी। उदाहरण के लिए कल्पना कीजिए:

ALTER TABLE book RENAME COLUMN title TO book_title;

क्या आप सचमुच यह काम दो बार करना चाहेंगे? किसी भी मामले में नहीं। बस डीडीएल प्रतिबद्ध करें, इसे अपनी बिल्ड पाइपलाइन के माध्यम से चलाएं, और अद्यतन इकाई प्राप्त करें:

@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 XML सामग्री को बहुत अच्छी तरह से टोकनाइज़ करता है और सभी क्लाइंट भाषाओं में सत्यापन की अनुमति देता है
• XSD अच्छी तरह से संस्करणित है और इसमें उन्नत बैकवर्ड संगतता है
• XJC का उपयोग करके XSD को जावा कोड में अनुवादित किया जा सकता है

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

ईमानदारी से कहूँ तो, JSON API के साथ हर समय यही होता है, लेकिन यह एक और कहानी है, मैं अगली बार झगड़ा करूँगा...

डेटाबेस: वे एक ही चीज़ हैं

डेटाबेस के साथ काम करते समय, आपको एहसास होता है कि वे सभी मूल रूप से समान हैं। आधार अपने डेटा का मालिक है और उसे योजना का प्रबंधन करना चाहिए। स्कीमा में किए गए किसी भी संशोधन को सीधे डीडीएल में लागू किया जाना चाहिए ताकि सत्य का एकल स्रोत अद्यतन हो सके।

जब कोई स्रोत अपडेट होता है, तो सभी क्लाइंट को मॉडल की अपनी प्रतियां भी अपडेट करनी होंगी। कुछ क्लाइंट को जावा में jOOQ और हाइबरनेट या JDBC (या दोनों) का उपयोग करके लिखा जा सकता है। अन्य क्लाइंट को पर्ल में लिखा जा सकता है (हम बस उन्हें शुभकामनाएं देते हैं), जबकि अन्य को C# में लिखा जा सकता है। कोई फर्क नहीं पड़ता कि। मुख्य मॉडल डेटाबेस में है. ओआरएम का उपयोग करके तैयार किए गए मॉडल आमतौर पर खराब गुणवत्ता वाले, खराब दस्तावेज वाले और विकसित करने में कठिन होते हैं।

इसलिए गलतियाँ मत करो. शुरू से ही ग़लतियाँ न करें. डेटाबेस से कार्य करें. एक परिनियोजन पाइपलाइन बनाएं जिसे स्वचालित किया जा सके। अपने डेटाबेस मॉडल की प्रतिलिपि बनाना और उसे क्लाइंट पर डंप करना आसान बनाने के लिए कोड जेनरेटर सक्षम करें। और कोड जनरेटर के बारे में चिंता करना बंद करें। वे अच्छे हैं। उनके साथ आप अधिक उत्पादक बनेंगे। आपको शुरुआत से ही उन्हें स्थापित करने में बस थोड़ा समय बिताने की ज़रूरत है - और फिर वर्षों की बढ़ी हुई उत्पादकता आपका इंतजार कर रही है, जो आपके प्रोजेक्ट का इतिहास बनाएगी।

मुझे अभी धन्यवाद मत देना, बाद में।

स्पष्टीकरण

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

दो-स्तरीय आर्किटेक्चर में, जो अभी भी कुछ स्थानों पर संरक्षित हैं, ऐसा सिस्टम मॉडल एकमात्र संभव हो सकता है। हालाँकि, अधिकांश प्रणालियों में डेटा एक्सेस परत मुझे एक "सबसिस्टम" लगती है जो डेटाबेस मॉडल को समाहित करती है।

अपवाद

प्रत्येक नियम के अपवाद हैं, और मैंने पहले ही कहा है कि डेटाबेस-प्रथम और स्रोत-कोड पीढ़ी दृष्टिकोण कभी-कभी अनुपयुक्त हो सकता है। यहां ऐसे कुछ अपवाद दिए गए हैं (संभवतः अन्य भी हैं):

• जब स्कीमा अज्ञात हो और उसे खोजने की आवश्यकता हो। उदाहरण के लिए, आप एक उपकरण के प्रदाता हैं जो उपयोगकर्ताओं को किसी भी आरेख को नेविगेट करने में सहायता करता है। उह. यहां कोई कोड जेनरेशन नहीं है. लेकिन फिर भी, डेटाबेस पहले आता है।
• जब किसी समस्या को हल करने के लिए तत्काल एक सर्किट उत्पन्न किया जाना चाहिए। यह उदाहरण पैटर्न का थोड़ा काल्पनिक संस्करण जैसा लगता है इकाई विशेषता मान, यानी, आपके पास वास्तव में कोई स्पष्ट रूप से परिभाषित योजना नहीं है। इस मामले में, आप अक्सर यह भी सुनिश्चित नहीं कर सकते कि आरडीबीएमएस आपके लिए उपयुक्त होगा या नहीं।

अपवाद स्वभावतः असाधारण होते हैं। आरडीबीएमएस के उपयोग से जुड़े अधिकांश मामलों में, स्कीमा पहले से ज्ञात होता है, यह आरडीबीएमएस के भीतर रहता है और "सच्चाई" का एकमात्र स्रोत है, और सभी ग्राहकों को इससे प्राप्त प्रतियां प्राप्त करनी होती हैं। आदर्श रूप से, आपको एक कोड जनरेटर का उपयोग करने की आवश्यकता है।

स्रोत: www.habr.com