मेरे सहकर्मी ने 96 कॉलम SQL टेबल बनाया

Question

यहां हम 2010 में हैं, सॉफ्टवेयर इंजीनियर 4 या 5 साल या अनुभव के साथ, अभी भी 96 फ्रैकिंग कॉलम के साथ टेबल डिजाइन कर रहे हैं।

मैंने उससे कहा कि यह एक बुरा सपना है।
मैंने उसे दिखाया कि हमें MySQL को C # के साथ इंटरफ़ेस करने के लिए अध्यादेशों का उपयोग करना होगा।
मैंने समझाया कि पंक्तियों की तुलना में अधिक स्तंभों वाली तालिका एक बड़ी गंध है।

फिर भी, मुझे "यह इस तरह से सरल होने जा रहा है" मिलता है।

मुझे क्या करना चाहिए?

संपादित करें *

इस तालिका में सेंसर से डेटा है।
हमारे पास
Sens_D1X
डायनामिक_ D1Y के साथ सेंसर 1 है
[...]

डायनामिक_
डी 6 एक्स डायनेमिक_ डी 6 वाई
[...]

EDIT2 *

खैर, मैंने आखिरकार वह काम छोड़ दिया। यह एक संकेत है जब अन्य प्रोग्रामर समय पर महीनों के लिए अंधेरा हो जाता है, यह एक और संकेत है जब प्रबंधन को एहसास नहीं होता है कि यह एक समस्या है

Comments

उग, अंधेरे युग भी हो सकते हैं। जब लोग डेटाबेस का उपयोग करना सीखेंगे?

— चोसपांडियन

आपका विकल्प क्या है? यदि आपके पास कोई हल नहीं है तो आप किसी समस्या पर अतिरंजित नहीं हो सकते।

— TGnat

मैं उत्सुक हूं कि प्रत्येक पंक्ति में क्या संग्रहीत है।

— मेटलएमिस्टर

@ChaosPandion, केवल पारंपरिक डेटाबेस के उपयोग के बाद ही एक डिज़ाइन गंध है।

— instofTom

खैर वह स्पष्ट रूप से आपके डेटाबेस को ओवरडिज़ाइन कर रहा है। हमारे पास केवल 4 वर्चर कॉलम के साथ एकल तालिका के साथ एक डेटाबेस होता था: क्लास, ऑबजेक्ट, एटीआरआईबीयूटीई, वैल्यू। सभी डेटा वहाँ में फिट। को हराया! :)

— लुकास एडर

Answer 1

हो सकता है कि उसने ऐसा किसी अच्छे कारण के लिए किया हो, जैसे प्रदर्शन या आरओआई? ।

सबसे अच्छी बात है, उससे सवाल पूछना। "क्यों" की एक निश्चित राशि के साथ आप निश्चित रूप से उसे समझ पाएंगे कि वह शायद खुद से गलत है (यदि वह वास्तव में है)।

मेरे पास खुद एक मामला था जो प्रदर्शन से संबंधित नहीं है, लेकिन निवेश (आरओआई) पर लौटा है। मेरे पास एक मेज थी जिसमें सप्ताह के प्रत्येक घंटे (एक सप्ताह में 168h) के लिए विशिष्ट मूल्य था। हमारे पास एक ObjectHour तालिका बनाने का विकल्प था जिसमें मूल्य शामिल होगा, लेकिन ऑब्जेक्ट की कुंजी और घंटे की संख्या का दिन भी होगा। लेकिन हमें 168 मानों को पंक्ति में लगाने का अवसर भी मिला। शायद आपके सहकर्मी ने क्या किया।

डेवलपर्स ने दोनों समाधानों का अनुमान लगाया। सरल समाधान (168 कॉलम) अपने डिज़ाइन किए गए समकक्ष की तुलना में बहुत सस्ता था। ग्राहक के लिए ठीक उसी परिणाम के लिए।

हमने सुरक्षा जैसे अधिक महत्वपूर्ण सामान के हमारे प्रयासों पर ध्यान केंद्रित करने के लिए सरल / सबसे सस्ते समाधान के लिए जाने का फैसला किया।

भविष्य में इसे सुधारने के लिए हमारे पास कई अवसर होंगे। बाजार के लिए समय उस समय हमारे लिए प्राथमिकता थी।

Comments

मैं सहमत हूं - 'क्यों' के अतिरिक्त संदर्भ के बिना, स्तंभों की संख्या वास्तव में मायने नहीं रखती है। ट्रैक करने के लिए वैध रूप से 96 चीजें हो सकती हैं ... या, वह डेटा के 'सरणियों' (name_1, name_2) के लिए अतिरिक्त स्तंभों का उपयोग कर सकता है, जिन्हें अन्य तालिकाओं में तोड़ दिया जाना चाहिए।

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

ओह, तुम मुझे एक बात याद रखना ... मैं इसे अपने उत्तर में

"सामान्यीकृत" जरूरी "अच्छी तरह से डिज़ाइन किया गया" नहीं है। मैं आपके द्वारा यहां वर्णित निरूपण पर विचार करूंगा, यह पूरी तरह से ठीक डिजाइन निर्णय होगा।

मैं पूरी तरह से @GrandmasterB से सहमत हूं। स्तंभों की संख्या कुछ ऐसी नहीं है जिसे स्वतंत्र रूप से आंका जा सके। ऐसे समय होते हैं जब संबंधित डेटा का एक बड़ा सौदा किसी एक चीज़ के बारे में संग्रहीत किया जाना चाहिए। लोगों को क्या करना चाहिए? टैग की गई डेटा तालिका, (id, tag, value)और INSERTनब्बे विषम पंक्तियाँ बनाएं ? यदि जानकारी किसी तालिका में है और उचित है, तो कॉलम स्थिर रहता है, जब तक कि यह एक भयावह प्रदर्शन समस्या पैदा नहीं करता है।

— परिक्रमा

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

— इवान प्लाइस

Answer 2

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

Comments

कभी-कभी यह किसी को समझाने के लिए सबूत लेता है जो पहले से ही आश्वस्त हैं कि वे सही हैं। +1

— क्रिस

वास्तव में? औसत डेवलपर ऐसा करता है? ओह।

— वेबबिडीव

शायद बड़ी फ्लैट फाइलें वही हैं जो उन्हें पहली जगह में चाहिए?)

— जॉब

जरूरी नहीं कि अहंकार हो, लेकिन आपको क्यों बदलना चाहिए? नए सामान का उपयोग करने में लगने वाले समय और प्रयास के लिए "भुगतान" करना बेहतर होगा।

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

— इवान प्लाइस

Answer 3

कुछ इसी तरह की चर्चा पहले StackOverflow पर की गई थी ।

सामान्य तौर पर, एक मेज पर बहुत सारे कॉलम होने का मतलब यह नहीं है कि आप कुछ गलत कर रहे हैं, लेकिन यह निश्चित रूप से कुछ लाल झंडे को उठाना चाहिए ताकि आप डिजाइन को करीब से देखें। कभी-कभी एक विशाल तालिका सही विकल्प होती है, लेकिन कई मामलों में, अन्य विकल्प अधिक समझ में आते हैं। उदाहरण के लिए, एक विकल्प भंडारण को दो तालिकाओं में विभाजित करना है: एक तालिका जो आपकी संस्थाओं की पहचान करती है और एक अन्य तालिका जो प्रभावी रूप से उन संस्थाओं का वर्णन करने वाली विशेषताओं की कुंजी / मूल्य संग्रह है (इसलिए आप अधिकतम 96 पंक्तियों के साथ समाप्त हो सकते हैंप्रत्येक इकाई के लिए)। अन्य डिजाइन भी संभव हैं। अपने टीम के साथियों के साथ बात करें और यह पता लगाएं कि डेटा सामान्यीकरण, कोड पठनीयता और बनाए रखने के आधार पर कौन सा समाधान बेहतर है (भरने के लिए 96 विशेषताओं के साथ स्टेटमेंट डालें?), प्रदर्शन निहितार्थ, कितनी बार नई विशेषताओं (कॉलम) को जोड़ा या बदला जा सकता है, कितना विरल? डेटा है (96 कॉलम में से कितने को कभी भरा जाएगा और कितने NULL रहेंगे?), और रिपोर्टिंग पर निहितार्थ। किसी भी डेवलपर को अपने डिजाइन निर्णयों को यथोचित रूप से सक्षम करना चाहिए और यह दिखाना चाहिए कि लागत / लाभ व्यापार बंद (और हाँ, हर डिजाइन निर्णय एक व्यापार बंद है) उनके पक्ष में है। आपकी जिम्मेदारी शिकायत करना या आलोचना करना नहीं है, बल्कि विकल्पों को प्रस्तावित करना और सुनिश्चित करना है कि वे इन मुद्दों के माध्यम से सोचें।

Comments

मुख्य मूल्य भंडार perfomance और querability के लिए सबसे खराब विकल्प हैं।

— HLGEM

विस्तृत करने के लिए परवाह?

— येवगेनी ब्रिकमैन

Answer 4

क्या यह 96 स्तंभों के साथ सामान्यीकृत है? क्या यह 1st, 2nd, 3rd आदि NF को संतुष्ट करता है?

यह हो सकता है कि आपके पास इकाई के लिए 96 अलग-अलग विशेषताएँ हों।

अन्यथा, उसे सरल बात पर जो सेलको पढ़ा

Answer 5

यह पूरी तरह से निर्भर करता है।

सामान्यीकृत / अप्राकृतिकृत डीबी डिज़ाइन दोनों के अपने फायदे और नुकसान हैं।

मेरा पहला डीबी डिज़ाइन सुंदरता की एक सामान्यीकृत चीज़ थी। यह लचीला और एक्स्टेंसिबल था। यह कोड स्तर पर खुद को छोड़कर किसी के लिए भी एक अविश्वसनीय PITA था, और यह मेरे लिए एक हल्का PITA था।

मेरा अगला प्रयास एक सपाट संरचना थी, और यह (ए) बहुत तेज और (बी) के साथ कोड करने के लिए बहुत आसान था। और यह अधिक बाद में सामान्य करने के लिए एक बड़ा काम नहीं होगा।

तो यह एक गंध हो सकता है लेकिन कुछ अन्य डीबी डिजाइन में गंध की अपनी रमणीय सरणी होगी।

Comments

+1 यह इंगित करने के लिए कि अक्सर, कोई सही तरीका नहीं है।

— परिक्रमा

Answer 6

तकनीकी ऋण के बारे में इस लेख को पढ़ने के लिए उसे प्राप्त करें । यदि वह अभी भी इसे इस तरह रखने का फैसला करता है, तो कम से कम आपने एक रचनात्मक राय पेश की है।

Answer 7

(संपादित) पोस्ट को देखकर, यह स्पष्ट है कि यह एक बुरी तरह से अपसामान्य तालिका है। आपको क्या करना चाहिये? जैसा कि मैंने इसे देखा है, आपको कुछ विकल्प मिले हैं:

1. अपने सहकर्मी पर चिल्लाएं कि वह अपने काम को कैसे करें। अनौपचारिक रूप से उत्पादक होने के लिए लेकिन शायद अन्य सहकर्मियों को आपके साथ गड़बड़ नहीं करने के लिए मना लेंगे। चिल्लाने वाली पागल के रूप में एक प्रतिष्ठा उपयोगी हो सकती है (मुझे मत पूछो कि मैं कैसे जानता हूं)।
2. बॉस पर चिल्लाओ कि सहकर्मी एक बेवकूफ है। आपदा की भविष्यवाणी करें, फिर सक्रिय रूप से तोड़फोड़ परियोजना के लिए काम करें। दोषपूर्ण सहकर्मी द्वारा उत्पादित डेटाबेस डिजाइन पर सब कुछ दोष। सीधे नेतृत्व कर सकते हैं ...
3. बाहर निकलें। सबसे अच्छा अगर यह आपका विचार है, लेकिन # 2 अनैच्छिक इस्तीफा दे सकता है। गुस्से में बॉस और / या सहकर्मियों द्वारा खिड़की से फेंकने पर डामर / कंक्रीट / बजरी पर घुटनों को खुरचने की कोशिश न करें। (ध्यान दें कि पूर्व अध्ययन यहां महत्वपूर्ण है। आपके जीवित रहने की संभावना स्पष्ट रूप से घट जाती है अगर बॉस का कार्यालय भूतल से ऊपर है और आप पाते हैं कि आप खुद को खिड़की से बाहर निकाल रहे हैं। आगे की योजना बनाएं !! )
4. जमकर पिएं - या, कैलिफ़ोर्निया में जाएँ और प्रकाश करें (मान लेते हैं कि प्रो। 19 (या जो भी) गुजरता है)। कुछ शॉट और एक डोबी की तरह कुछ भी एक के सहकर्मियों पर किसी के दृष्टिकोण को बेहतर बनाने के लिए (या तो मैंने सुना है)। (सार्वजनिक सेवा की घोषणा: किड्स! ये लोग पेशेवर हैं! घर पर यह कोशिश मत करो!)

साझा करें और आनंद लें।

Comments

मैंने # 4 की कोशिश की, लेकिन अब यह सोमवार है और जब मैं काम की जगह

— एरिक

बिंदु एक पढ़ें। Upvoted। बिंदु दो पढ़ें, मेरे अपवित्र को उजागर करें। सच में भाई?

— ज़ोरान पावलोविच

Answer 8

मैं यहां एक अंग पर जा रहा हूं और मान रहा हूं कि वह इस "न्यू" टेबल के साथ काम करने के लिए बहुत सारे कोड को काटने और पेस्ट करने जा रहा है।

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

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

Answer 9

स्कीमा का उपयोग करने जा रहे एप्लिकेशन के उपयोग के मामलों पर पूरी तरह से निर्भर करता है, एक समय में डेटा का कौन सा हिस्सा आवश्यक है। किसी तरह से यह टेबल डिजाइन को सही ठहरा सकता है।

Answer 10

मैं उसे पाषाण युग में भेजूँगा और उसे फ़ाइलों का उपयोग करने के लिए मजबूर करूँगा या कम से कम उसे सिखाने का उपयोग कैसे करूँगा।

वास्तव में, 96columns ... वह खिचड़ी भाषा कभी भी सही हो सकती है। शायद एक ORM मदद करेगा। (जब तक आपको प्रदर्शन की आवश्यकता है लेकिन आपके पास कोई ऐसा व्यक्ति हो सकता है जो DB को बेहतर तरीके से समझता है)

Answer 11

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

हालांकि इस डिज़ाइन के वास्तविक कारणों को जाने बिना (मैंने मौसम सेंसर पर काम किया है, जिसमें 96 से अधिक विभिन्न संख्यात्मक आउटपुट = बड़ी संख्या में टेबल कॉलम हैं ...) यह सिर्फ एक पालतू जानवर को पेशाब करने जैसा लगता है।