"अंतिम उपाय" या डेटाबेस फर्स्ट डिज़ाइन की आवश्यकता क्यों है

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

एलन ओ'रोरके / ऑडियंस स्टैक द्वारा लाइसेंस टू सीसी बेहतर "टू बिजी बिफोर बी"। मूल छवि

यह लेख एक हालिया StackOverflow प्रश्न से प्रेरित है ।

दिलचस्प रेडिट चर्चा / आर / जावा और / आर / प्रोग्रामिंग ।

कोड जनरेशन

मेरे आश्चर्य के लिए, उपयोगकर्ताओं का एक छोटा समूह इस तथ्य से चौंक गया है कि jOOQ स्रोत कोड पीढ़ी से बहुत अधिक बंधा हुआ है।

जब आप अपनी पसंद के अनुसार jOOQ का उपयोग कर सकते हैं, तो पसंदीदा तरीका (दस्तावेज़ के अनुसार) मौजूदा डेटाबेस स्कीमा के साथ शुरू करना है, फिर jOOQ का उपयोग करके आवश्यक क्लाइंट क्लासेस (अपनी तालिकाओं के अनुरूप) उत्पन्न करें, और उसके बाद टाइप-सेफ लिखना आसान है इन तालिकाओं के लिए प्रश्न:

for (Record2<String, String> record : DSL.using(configuration) // ^^^^^^^^^^^^^^^^^^^^^^^ Type information derived from the // generated code referenced from the below SELECT clause .select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME) // vvvvv ^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ Generated names .from(ACTOR) .orderBy(1, 2)) { // ... } 

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

स्रोत कोड पीढ़ी

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

काफी कुछ ऐसे कोड जनरेटर हैं। उदाहरण के लिए, XJC XSD या WSDL फ़ाइलों से जावा कोड उत्पन्न कर सकता है । सिद्धांत हमेशा समान है:

• कुछ मानक (बाहरी या आंतरिक) हैं, जैसे विनिर्देश, डेटा मॉडल, आदि।
• हमारी सामान्य प्रोग्रामिंग भाषा में इस मानक का अपना विचार प्राप्त करना आवश्यक है।

और लगभग हमेशा यह बेकार काम और अनावश्यक गलतियों से बचने के लिए इस दृश्य को उत्पन्न करने के लिए समझ में आता है।

प्रदाताओं और एनोटेशन प्रसंस्करण टाइप करें

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

दोनों मामलों में, सामान्य कोड पीढ़ी के अलावा सब कुछ एक जैसा है:

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

कोड पीढ़ी के साथ समस्या क्या है?

कोड को मैन्युअल रूप से या स्वचालित रूप से जेनरेट करने के ट्रिकी प्रश्न के अलावा, कुछ लोग सोचते हैं कि कोड को बिल्कुल उत्पन्न करने की आवश्यकता नहीं है। सबसे अधिक बार सुनने का कारण यह है कि ऐसी पीढ़ी को CI / CD पाइपलाइन में लागू करना मुश्किल है। और हाँ, यह सच है, क्योंकि अतिरिक्त इन्फ्रास्ट्रक्चर बनाने और समर्थन करने के लिए हम ओवरहेड प्राप्त करते हैं, खासकर यदि आप उपयोग किए गए उपकरणों में नए हैं (jOOQ, JAXB, हाइबरनेट, आदि)।

यदि कोड जनरेटर का अध्ययन करने का ओवरहेड बहुत अधिक है, तो वास्तव में बहुत कम लाभ होगा। लेकिन इसके खिलाफ एकमात्र तर्क है। अधिकांश अन्य मामलों में, यह मैन्युअल रूप से कोड लिखने के लिए बिल्कुल कोई मतलब नहीं है, जो किसी चीज के मॉडल का सामान्य प्रतिनिधित्व है।

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

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

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

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

और वह लगभग पूरा हो चुका है। इसके बाद, हाइबरनेट डीडीएल और वांछित SQL बोली में इस ऑब्जेक्ट को परिभाषित करने के बारे में पूरी दिनचर्या को ले जाएगा:

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

लेकिन आप इसके लिए भुगतान करेंगे, थोड़ी देर बाद

जल्दी या बाद में, आपका आवेदन उत्पादन में चला जाता है, और वर्णित योजना काम करना बंद कर देगी:

एक जीवित और वास्तविक प्रणाली में, आप अब अपना डेटाबेस नहीं चुन सकते हैं और छोड़ सकते हैं, क्योंकि इसमें डेटा का उपयोग किया जाता है और इसमें काफी पैसा खर्च हो सकता है।

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

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

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

इसके बजाय, आप शुरू से ही काफी अलग तरह से अभिनय कर सकते थे। अर्थात्, चौकोर वाले के बजाय गोल पहियों का उपयोग करें।

पहले डेटाबेस में जाएं

डेटा स्कीमा संदर्भ और नियंत्रण आपके DBMS के कार्यालय में है। एक डेटाबेस एकमात्र स्थान है जहां एक स्कीमा को परिभाषित किया गया है, और सभी ग्राहकों के पास उस स्कीमा की एक प्रति है , लेकिन इसके विपरीत नहीं। डेटा आपके डेटाबेस में है, और आपके क्लाइंट में नहीं है, इसलिए यह योजना और उसकी अखंडता पर नियंत्रण प्रदान करने के लिए समझ में आता है कि डेटा कहाँ है।

यह पुराना ज्ञान है, कोई नई बात नहीं। प्राथमिक और अद्वितीय कुंजियाँ अच्छी हैं। विदेशी चाबियां सुंदर हैं। डेटाबेस की ओर से बाधाओं की जाँच करना अद्भुत है। अभिकथन (जब वे अंततः लागू होते हैं) महान होते हैं ।

और यह सब नहीं है। उदाहरण के लिए, यदि आप Oracle का उपयोग कर रहे हैं, तो आप यह निर्दिष्ट कर सकते हैं:

• आपकी तालिका किस तालिका में है?
• PCTFREE का मतलब क्या है
• अनुक्रम कैश का आकार क्या है?

शायद यह सब छोटी प्रणालियों पर कोई फर्क नहीं पड़ता है, लेकिन बड़े सिस्टम पर आपको "बड़े डेटा" के पथ का पालन करने की आवश्यकता नहीं है जब तक कि आप अपने वर्तमान भंडारण से सभी रसों को बाहर नहीं निकालते हैं। एक भी ORM जो मैंने कभी नहीं देखा है (jOOQ सहित), आपको आपके DDL पैरामीटर के पूर्ण सेट का उपयोग करने की अनुमति देगा जो आपके DBX प्रदान करता है। ORM आपको DDL लिखने में मदद करने के लिए केवल कुछ उपकरण प्रदान करते हैं।

अंततः, एक अच्छी तरह से डिज़ाइन किए गए स्कीमा को केवल डीबीएमएस-विशिष्ट डीडीएल का उपयोग करके मैन्युअल रूप से लिखा जाना चाहिए। सभी स्वचालित रूप से उत्पन्न DDLs इस के लिए एक सन्निकटन हैं।

क्लाइंट मॉडल के बारे में क्या?

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

सभी डेटाबेस अच्छे पुराने 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 

यह ऐसी क्वेरीज़ (साथ ही विचारों, भौतिक विचारों और तालिका कार्यों के लिए समान क्वेरी) हैं, जो तब निष्पादित की जाती हैं जब किसी विशिष्ट JDBC ड्राइवर के डेटाबेस MetaData.getTables () विधि को, या jOOQ- मेटा मॉड्यूल में कहा जाता है।

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

• यदि आप JDBC या स्प्रिंग का उपयोग करते हैं, तो आप स्ट्रिंग स्थिरांक का एक समूह बना सकते हैं
• यदि JPA का उपयोग कर रहे हैं, तो आप अपने आप ऑब्जेक्ट बना सकते हैं
• यदि jOOQ का उपयोग कर रहे हैं, तो आप jOOQ मेटामॉडल बना सकते हैं

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

अब डेटाबेस स्कीमा में कोई भी परिवर्तन स्वचालित रूप से क्लाइंट कोड के अपडेट के लिए होगा।

कल्पना कीजिए कि आपको एक तालिका में एक स्तंभ का नाम बदलने की आवश्यकता है:

 ALTER TABLE book RENAME COLUMN title TO book_title; 

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

 @Entity @Table(name = "book", indexes = { // Would you have thought of this? @Index(name = "i_book_title", columnList = "book_title") }) class Book { @Id @GeneratedValue(strategy = IDENTITY) int id; @Column("book_title") String **bookTitle**; } 

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

सच हमेशा अकेला होता है

कोई फर्क नहीं पड़ता कि आप किस तकनीक का उपयोग करते हैं, हमेशा एक ही मॉडल होना चाहिए, जो सबसिस्टम के लिए मानक है। या, कम से कम, हमें इसके लिए प्रयास करना चाहिए और व्यापार में भ्रम से बचना चाहिए, जहां "मानक" हर जगह है और एक ही समय में कहीं भी नहीं है। यह सब कुछ बहुत आसान बना देता है। उदाहरण के लिए, यदि आप XML फाइल को किसी अन्य सिस्टम के साथ साझा कर रहे हैं, तो आप शायद XSD का उपयोग कर रहे हैं। XML प्रारूप में एक मेटामॉडल INFORMATION_SCHEMA jOOQ के रूप में: https://www.jooq.org/xsd/jooq-meta-3.10.0.xsd

• XSD अच्छी तरह से समझा जाता है
• XSD पूरी तरह से XML सामग्री का वर्णन करता है और सभी क्लाइंट भाषाओं में सत्यापन की अनुमति देता है
• XSD आसान और पीछे संगत संस्करण बनाता है
• XJC का उपयोग करके XSD को जावा कोड में बदल दिया जा सकता है

हम अंतिम बिंदु पर विशेष ध्यान देते हैं। एक्सएमएल संदेशों के माध्यम से एक बाहरी प्रणाली के साथ संचार करते समय, हमें संदेशों की वैधता के बारे में सुनिश्चित होना चाहिए। और यह वास्तव में JAXB, XJC, और XSD जैसी चीजों के साथ करना बहुत आसान है। इस मामले में जावा-प्रथम दृष्टिकोण की उपयुक्तता के बारे में सोचना पागल होगा। एक्सएमएल ऑब्जेक्ट्स पर आधारित एक्सएमएल उत्पन्न खराब गुणवत्ता का होगा, खराब रूप से प्रलेखित और विस्तार करने में मुश्किल होगा। और अगर इस तरह की बातचीत के लिए एसएलए है, तो आप निराश होंगे।

ईमानदारी से, यह अब JSON APIs के साथ क्या हो रहा है, इसके समान है, लेकिन यह पूरी तरह से अलग कहानी है ...

क्या डेटाबेस खराब करता है?

डेटाबेस के साथ काम करते समय, यहां सब कुछ समान है। डेटाबेस डेटा का मालिक है, और यह डेटा स्कीमा का मास्टर भी होना चाहिए। संदर्भ को अद्यतन करने के लिए सभी स्कीमा संशोधनों को सीधे DDL के माध्यम से किया जाना चाहिए।

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

इसलिए, यह मत करो, और विकास की शुरुआत से। इसके बजाय, एक डेटाबेस से शुरू करें। एक स्वचालित CI / CD पाइपलाइन बनाएं। प्रत्येक बिल्ड के लिए क्लाइंट के लिए डेटाबेस मॉडल को स्वचालित रूप से उत्पन्न करने के लिए इसमें कोड जनरेशन का उपयोग करें। और चिंता करना बंद करो, सब ठीक हो जाएगा। यह सब आवश्यक है कि बुनियादी ढाँचा स्थापित करने के लिए थोड़ा प्रारंभिक प्रयास हो, लेकिन इसके परिणामस्वरूप आपको आने वाले वर्षों के लिए अपनी परियोजना के बाकी हिस्सों के लिए विकास प्रक्रिया में लाभ मिलेगा।

कोई धन्यवाद नहीं।

स्पष्टीकरण

समेकित करने के लिए: यह लेख किसी भी तरह से दावा नहीं करता है कि डेटाबेस मॉडल आपके पूरे सिस्टम (विषय क्षेत्र, व्यावसायिक तर्क, आदि) पर लागू होना चाहिए। मेरे कथन केवल इस तथ्य से संबंधित हैं कि डेटाबेस के साथ बातचीत करने वाला क्लाइंट कोड केवल डेटाबेस स्कीमा का प्रतिनिधित्व होना चाहिए, लेकिन इसे परिभाषित नहीं करना चाहिए और इसे किसी भी तरह से बनाना चाहिए।

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

अपवाद

किसी भी अन्य अच्छे नियम की तरह, हमारे पास भी इसके अपवाद हैं (और मैंने पहले ही चेतावनी दी थी कि डेटाबेस पहले दृष्टिकोण और कोड पीढ़ी हमेशा सही विकल्प नहीं है)। ये अपवाद (शायद सूची पूरी नहीं है):

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

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