सत्य पहिले, वा किन डाटाबेस डिजाइनमा आधारित प्रणाली डिजाइन गर्न आवश्यक छ

हे हाबर!

हामी विषयको अनुसन्धान जारी राख्छौं Java и वसन्त, डाटाबेस स्तर सहित। आज हामी तपाईलाई पढ्न आमन्त्रित गर्दछौं किन, ठूला अनुप्रयोगहरू डिजाइन गर्दा, यो डाटाबेस संरचना हो, जाभा कोड होइन, त्यो निर्णायक महत्त्वको हुनुपर्छ, यो कसरी गरिन्छ, र यस नियममा के अपवादहरू छन्।

यो बरु ढिलो लेखमा, म व्याख्या गर्नेछु किन म विश्वास गर्छु कि लगभग सबै अवस्थामा, एक अनुप्रयोगमा डाटा मोडेल "जाभा को क्षमताहरु बाट" को सट्टा "डेटाबेस बाट" डिजाइन गर्नुपर्छ (वा जुनसुकै ग्राहक भाषा तपाईं हुनुहुन्छ। संग काम गर्दै)। दोस्रो दृष्टिकोण अपनाएर, तपाईंले आफ्नो परियोजना बढ्न थालेपछि दुखाइ र पीडाको लामो मार्गको लागि आफैलाई सेट अप गर्दै हुनुहुन्छ।

आधारमा लेख लेखिएको थियो एउटा प्रश्न, Stack Overflow मा दिइएको छ।

खण्डहरूमा 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)) {
    // ...
}

कोड या त म्यानुअल रूपमा विधानसभा बाहिर, वा म्यानुअल रूपमा प्रत्येक सभामा उत्पन्न हुन्छ। उदाहरण को लागी, यस्तो पुनरुत्थान तुरुन्तै पछि लाग्न सक्छ फ्लाईवे डाटाबेस माइग्रेसन, जुन म्यानुअल वा स्वचालित रूपमा पनि गर्न सकिन्छ.

स्रोत कोड उत्पादन

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

त्यहाँ धेरै कोड जनरेटरहरू छन्। उदाहरणका लागि, XJC ले XSD वा WSDL फाइलहरूमा आधारित जाभा कोड उत्पन्न गर्न सक्छ। सिद्धान्त सधैं समान छ:

• त्यहाँ केहि सत्य छ (आन्तरिक वा बाह्य) - उदाहरण को लागी, एक विशिष्टता, एक डाटा मोडेल, आदि।
• हामीलाई हाम्रो प्रोग्रामिङ भाषामा यो सत्यको स्थानीय प्रतिनिधित्व चाहिन्छ।

यसबाहेक, अनावश्यकताबाट बच्नको लागि यस्तो प्रतिनिधित्व उत्पन्न गर्न लगभग सधैं सल्लाह दिइन्छ।

प्रकार प्रदायकहरू र एनोटेसन प्रशोधन

नोट: 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 प्रयोग गरेर। यस मामला मा तपाइँको संस्थाहरु के हुनेछ? तपाइँ या त तिनीहरूलाई म्यानुअल रूपमा अनुकूलन गर्न सक्नुहुन्छ (र यसरी तपाइँको कार्यभार दोब्बर), वा तपाइँ हाइबरनेट लाई तपाइँको लागि तिनीहरूलाई पुन: उत्पन्न गर्न भन्न सक्नुहुन्छ (कति सम्भावना छ कि तपाइँको अपेक्षाहरू पूरा गर्न यस तरिकाले उत्पन्न हुन्छ?) कुनै पनि तरिका, तपाइँ हराउनुहुन्छ।

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

बरु, चीजहरू सुरुदेखि नै पूर्ण रूपमा फरक तरिकाले गर्न सकिन्थ्यो। उदाहरणका लागि, साइकलमा गोल पाङ्ग्राहरू राख्नुहोस्।

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

तपाईको डाटाबेस स्कीमामा वास्तविक "सत्य" र यसमा "सार्वभौमिकता" डाटाबेस भित्र छ। स्कीमा केवल डाटाबेसमा नै परिभाषित गरिएको छ र अरू कतै छैन, र प्रत्येक ग्राहकसँग यो स्कीमाको प्रतिलिपि छ, त्यसैले यो स्कीमा र यसको अखण्डतासँग अनुपालन लागू गर्न, यसलाई डाटाबेसमा सही गर्नको लागि सही अर्थ दिन्छ - जहाँ जानकारी छ। भण्डार गरिएको।
यो पुरानो हो, अचम्मको बुद्धि पनि हो। प्राथमिक र अद्वितीय कुञ्जीहरू राम्रो छन्। विदेशी कुञ्जीहरू राम्रो छन्। प्रतिबन्धहरू जाँच गर्नु राम्रो छ। दावीहरु - ठीक छ।

यसबाहेक, त्यो सबै होइन। उदाहरण को लागी, Oracle प्रयोग गरेर, तपाइँ सम्भवतः निर्दिष्ट गर्न चाहानुहुन्छ:

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

यो साना प्रणालीहरूमा महत्त्वपूर्ण नहुन सक्छ, तर तपाईंले ठूला डाटा क्षेत्रमा नजाउन्जेल पर्खनु पर्दैन — तपाईंले विक्रेता-प्रदान गरिएको भण्डारण अप्टिमाइजेसनहरूबाट लाभ उठाउन सुरु गर्न सक्नुहुन्छ जस्तै माथि उल्लेख गरिएकाहरू। मैले देखेको कुनै पनि ORMs (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 वा Spring प्रयोग गर्दै हुनुहुन्छ भने, तपाइँ string constants को सेट बनाउन सक्नुहुन्छ
• यदि तपाइँ 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 राम्रोसँग संस्करण गरिएको छ र उन्नत ब्याकवर्ड अनुकूलता छ
• XSD XJC प्रयोग गरेर जाभा कोडमा अनुवाद गर्न सकिन्छ

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

इमानदारीपूर्वक, यो जेएसओएन एपीआईहरूसँग सबै समय हुन्छ, तर त्यो अर्को कथा हो, म अर्को पटक झगडा गर्नेछु ...

डाटाबेस: तिनीहरू एउटै कुरा हुन्

डाटाबेसहरूसँग काम गर्दा, तपाईंले महसुस गर्नुहुन्छ कि तिनीहरू सबै मूल रूपमा समान छन्। आधारसँग यसको डाटाको स्वामित्व छ र योजना व्यवस्थापन गर्नुपर्छ। स्कीमामा गरिएका कुनै पनि परिमार्जनहरू प्रत्यक्ष रूपमा DDL मा लागू गरिनुपर्छ ताकि सत्यको एकल स्रोत अद्यावधिक हुन्छ।

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

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

मलाई अझै धन्यवाद नदिनुहोस्, पछि।

स्पष्टीकरण

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

दुई-स्तर वास्तुकलाहरूमा, जुन अझै पनि केही ठाउँहरूमा संरक्षित छन्, यस्तो प्रणाली मोडेल मात्र सम्भव हुन सक्छ। यद्यपि, धेरैजसो प्रणालीहरूमा डाटा पहुँच तह मलाई "सबसिस्टम" जस्तो देखिन्छ जसले डाटाबेस मोडेललाई समेट्छ।

अपवादहरू

त्यहाँ प्रत्येक नियममा अपवादहरू छन्, र मैले पहिले नै भनेको छु कि डाटाबेस-पहिलो र स्रोत-कोड उत्पादन दृष्टिकोण कहिलेकाहीं अनुपयुक्त हुन सक्छ। यहाँ त्यस्ता केही अपवादहरू छन् (त्यहाँ सायद अरू पनि छन्):

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

अपवाद प्रकृति द्वारा असाधारण छन्। RDBMS को प्रयोगमा संलग्न अधिकांश अवस्थामा, स्कीमा पहिले नै थाहा हुन्छ, यो RDBMS भित्र रहन्छ र "सत्य" को एक मात्र स्रोत हो, र सबै ग्राहकहरूले यसबाट व्युत्पन्न प्रतिलिपिहरू प्राप्त गर्नुपर्छ। आदर्श रूपमा, तपाईंले कोड जनरेटर प्रयोग गर्न आवश्यक छ।

स्रोत: www.habr.com