चुस्त विकास में, क्या मुझे डेटाबेस से पहले फ्लैट फाइल में दृढ़ता की कोशिश करनी चाहिए?

21

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

क्या यह सच है, या मैंने अवधारणा को गलत समझा? क्या यह है कि चुस्त टीम आमतौर पर एप्लिकेशन का निर्माण करती है? इसके लिए तर्क क्या हैं और मुझे यह तरीका कब नहीं अपनाना चाहिए?

— लुई राइस
स्रोत

1

दृढ़ता तर्क मामूली विवरण का हिस्सा नहीं है, या कम महत्वपूर्ण नहीं है। यह पहला निर्णय होना चाहिए। आप अपनी दृढ़ता संरचना के लिए ACID गुण चाहते हैं। उस निर्णय को लंबित नहीं रखा जा सकता है।

— मनोज आर।

42

व्यक्त की जा रही अवधारणा कुछ है जो निश्चित रूप से चुस्त और प्रासंगिक है, चीजों को अंतिम जिम्मेदार क्षण तक बंद करने का विचार है।

हालाँकि लिया गया उदाहरण वास्तव में शुरू करने के लिए पूरी तरह से गलत धारणा पर निर्भर करता है:

RDBMS का उपयोग करने की तुलना में फ्लैट-फ़ाइल डेटाबेस को लागू करना आसान / कम काम है। - अक्सर पूरी तरह से झूठ

उदाहरण होना चाहिए: दृढ़ता की परत को सबसे सरल संभव कार्यान्वयन के लिए रखा जाता है जब तक कि कोई निर्णय नहीं किया जाता है कि यह अपर्याप्त है।

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

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

संक्षेप में: अवधारणा सही और सटीक है, लेकिन उदाहरण बहुत बड़ी और अक्सर (लगभग हमेशा) गलत धारणा पर आधारित है ।

— जिम्मी होफा
स्रोत

6

और आपकी बहुत बड़ी धारणा यह है कि उन्हें मैन्युअल रूप से सभी शोध और डेटा-टेबल निर्माण प्रकार कोड को लिखना होगा! :-) आमतौर पर जब आप अपनी फ़्लैट फ़ाइल का उपयोग करते हैं, तो आप अपनी भाषा के बिल्ट-इन सीरियलाइज़ेशन प्रारूप (उदाहरण के लिए रूबी में मार्शल, या कोकोआ / ऑब्जेक्टिव-सी में NSKeyedArchiver) का उपयोग करके शुरू करते हैं और कुछ मौजूदा आंतरिक वस्तुओं को डंप कर देते हैं। जब तक आपके ऐप को बहुत बार पुनः लोड नहीं करना पड़ता है, और जब तक आपको ऐप संस्करणों में स्कीमा परिवर्तन पर एक हैंडल मिलता है, तब तक यह तकनीक लंबे समय तक उल्लेखनीय रूप से अच्छी तरह से काम कर सकती है, खासकर विकास के दौरान।

— एलेक्स चॉफी

@AlexChaffee उचित बिंदु, लेकिन किसी भी तरह से आपको इस सामान के चारों ओर कुछ कोड लिखने की आवश्यकता है एक रास्ता या किसी अन्य और आधुनिक ORM इस तरह की चीजों को RDBMS या NoSQL के साथ कर रहे हैं, इस मामले के लिए तुच्छता में काफी समकक्ष है, जहां टीम पर प्रभाव का अंतर है। कुछ भी की तुलना में टीमों के कौशल में अधिक आधारित है, मुझे लगता है कि यह इस कारण के लिए कोशिश कर रहे बिंदु को चित्रित करने के लिए एक बुरा उदाहरण है। व्यक्तिगत रूप से मैंने 13 साल के लिए MSSQL का उपयोग किया है, लेकिन मौके पर रखा MongoDB को सरलता की वजह से दृढ़ता के लिए स्पिन करेगा क्योंकि यह परियोजना के वास्तविक लक्ष्य को तब तक प्रभावित नहीं होने देगा जब तक ACID मायने नहीं रखता।

— जिमी होफा

17

चूँकि आप जानते हैं कि आप एक DB का उपयोग कर रहे हैं, फ्लैट फ़ाइलों को संभालने के लिए कोड लिखने में बहुत ज्यादा बात नहीं है। आप कुछ रीड-ओनली CSV का उपयोग करके कुछ पुनरावृत्तियों के माध्यम से प्राप्त कर सकते हैं, लेकिन आप जल्दी से अपने आप को कोड लिखेंगे जो आपको पता है कि आप फेंक देंगे।

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

— शॉन मैकसोमरेटिंग
स्रोत

4

लगता है जैसे आपको फ्लैट फ़ाइल सोसाइटी से एक डाउनवोट मिला।

— 18

@ जेफ़ो: SQLite एक फ्लैट फ़ाइल के लिए अपने डेटाबेस को बचाता है।

— श्री। मिन्दोर

7

@ Mr.Mindor, अधिकांश डेटाबेस करते हैं ... लेकिन यह अप्रासंगिक है। यहां 'फ्लैट फाइल' का मतलब सीधे फाइल में हेरफेर करना है, जैसा कि कुछ DB परत के माध्यम से जाने का विरोध है।

— ग्रैंडमास्टरबी

सहमत नहीं हैं। मुझे अभी भी सीखना होगा कि SQLite कैसे काम करता है, और .NET में SQLite डेटाबेस में हेरफेर करने वाला कोड लागू करता है, क्वेरी परिणाम को ऑब्जेक्ट में परिवर्तित करता है, आदि ताकि यह विकास को आसान न बनाए। यह सिर्फ एक पूर्ण डेटाबेस डेटाबेस सर्वर के फायदों के बिना, डेटाबेस बनाने के सभी बोझों को जोड़ता है।

— लुई रईस

11

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

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

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

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

— PDR
स्रोत

मैं प्रवास पथ के बारे में असहमत हूं। Technet.microsoft.com/en-us/library/cc966396.aspx के पास MySQL से MSSQL के लिए माइग्रेट करने के बारे में विस्तृत निर्देश हैं, हालाँकि फ्लैट-फाइल को या तो पसंद में बदलने के लिए मैन्युअल रूप से SSIS या MySQL के संस्करण में कुछ ETL लिखना होगा।

— जिमी हॉफ

@ जिमीहॉफ: मुझे पता नहीं, एक सीएसवी बहुत आसान है। blog.sqlauthority.com/2008/02/06/… tech-recipes.com/rx/2345/import_csv_file_directly_into_mysql लेकिन मैं आपकी बात मानता हूं कि न तो कोई रास्ता जटिल है।

— pdr

6

क्याआप कर रहे हैं?

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

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

— FrustratedWithFormsDesigner
स्रोत

1

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

— लुईस

@LouisRhys: इस कतार डेटा के साथ क्या किया जाएगा? बस उपयोगकर्ता को पढ़ना और प्रदर्शित करना? एक डेटाबेस में बने रहने से आपको क्या लाभ होगा?

— FrustratedWithFormsDesigner

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

— लुई रईस

@LouisRhys: हो सकता है कि पहली यात्रा या विकास के दो के लिए आप एक फ्लैट फ़ाइल का उपयोग कर सकते हैं, बस एक प्रूफ-ऑफ-कांसेप्ट काम कर रहे हैं, लेकिन आप भविष्य में डेटा एक्सेस से तर्क को पूरी तरह से अलग करना चाहते हैं, क्योंकि यह भविष्य में हो सकता है एक डेटाबेस की तरह लगता है एक अच्छी बात हो सकती है (और फ़ाइल से डीबी में बदलने के बाद अधिक समय लगेगा)। अंततः, यह एक उन्नत वास्तुकला निर्णय है जो केवल आप ही कर सकते हैं क्योंकि आपके पास ग्राहक के चश्मे / आवश्यकताओं तक पहुंच है।

— FrustratedWithFormsDesigner

5

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

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

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

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

— कार्ल बेवफेल्ड
स्रोत

1

"योजनाएं बेकार हैं, लेकिन योजना बनाना आवश्यक है।" - आइज़नहावर

— एलेक्सा चाफी

3

मुझे लगता है कि आप गलत मूल्यों पर ध्यान दे रहे हैं। फुर्तीले में, व्यापार मूल्य ध्यान में है। कुछ अंतिम उपयोगकर्ताओं को व्यावसायिक मूल्य देने के लिए आप एक उत्पाद बनाते हैं।

यदि आप दृढ़ता की परत को देर से बनाते हैं, या ग्राहक के लिए व्यावसायिक मूल्य प्रदान करने के लिए अपनी रणनीति के साथ इसे बनाते हैं। मुझे विश्वास नहीं है कि "फुर्तीली" शब्द खुद को निर्धारित करता है कि क्या आपको एक या दूसरे को करना चाहिए।

रॉबर्ट सी। मार्टिन (फुर्तीले घोषणापत्र के लेखकों में से एक) द्वारा इस प्रस्तुति में डेटा स्टोरेज की रणनीति के बारे में विचार करने की वकालत की गई है।

यह एक बहुत अच्छी प्रस्तुति है, मैं यह सलाह दे सकता हूं कि आप इसे देखें।

लेकिन मैं इससे असहमत हूं! कम से कम एक हद तक।

मुझे विश्वास नहीं है कि आप "डन" के लिए एक उपयोगकर्ता कहानी को कॉल कर सकते हैं, यदि उपयोगकर्ता कहानी में डेटा शामिल है जिसे निरंतर होना चाहिए, और आपके पास वास्तव में किसी भी प्रकार की दृढ़ता लागू नहीं है।

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

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

— पीट
स्रोत

1

यह देखने के लिए अच्छा निर्णय और अनुभव होता है कि किसी नई परियोजना को शुरू करते समय पहले किन सवालों के जवाब देने की आवश्यकता होती है।

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

यदि अंतिम उत्पाद अच्छी तरह से जाना जाता है, तो यह समझना कि आपके आवेदन में कितनी दृढ़ता से काम किया जाएगा, यह जल्दी जानना अधिक महत्वपूर्ण हो सकता है। वहाँ जोखिम यह है कि विकास प्रक्रिया में आपके उत्पाद विनिर्देश के साथ समस्याओं का पता लगाएं।

— रॉबर्ट वत्स
स्रोत

0

फ्लैट फ़ाइलें सरल नहीं हैं!

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

ऐसे कारण हैं जो डेटाबेस मौजूद हैं और उनमें से एक डेवलपर्स के लिए चीजों को सरल बनाना है।

मेरा ज्यादातर विकास बड़ी कंपनियों के भीतर बड़े सिस्टम के लिए हुआ है। हमारे पास हमेशा कोई भी डिज़ाइन या विकास करने से पहले डेटा मॉडल होता है। एक डेटा मॉडल आपको अपनी समस्या को समझने में मदद करता है और एक साफ कार्यान्वयन के लिए अनुमति देता है।

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

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

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

— जेम्स एंडरसन
स्रोत

-1

क्या आपको डेटाबेस से पहले एक फ्लैट फ़ाइल में दृढ़ता की कोशिश करनी चाहिए?

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

— एलेक्स चाफी
स्रोत