SQL सर्वर 2005 तालिका के लिए कितने कॉलम हैं?

Question

मैं एक गतिशील तालिका 1000 स्तंभों की अनुमति के लिए एक अनुरोध (बेतरतीब ढंग से मेरी अंत उपयोगकर्ताओं द्वारा चयनित) की है। यह मेरे लिए एक बुरा विचार लगता है। यह एक अनुकूलन तालिका है, इसलिए इसमें varchar(200) और float कॉलम का एक मिश्रण होगा (सबसे अच्छा मैचों नाव अनुप्रयोगों C++ डबल प्रकार)। यह डेटाबेस ज्यादातर विरासत अनुप्रयोग के लिए एक सूचकांक है और एक रिपोर्टिंग भंडार के रूप में कार्य करता है। यह रिकॉर्ड की प्रणाली नहीं है। इस एप्लिकेशन में हजारों डेटा पॉइंट हैं जिनमें से बहुत कम सामान्यीकृत किए जा सकते हैं।

इस बारे में कोई विचार क्या है कि इसका प्रदर्शन प्रभाव क्या है? या इसे नीचे विभाजित करने के लिए एक आदर्श टेबल आकार भी?

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

Answer 1

यह मेरे लिए एक बुरा डिजाइन की तरह बदबू आ रही है।

विचारणीय बातें:

उन स्तंभों में से सबसे अधिक हो जाएगा शून्य मान हैं?

क्या कई को संपत्ति001, संपत्ति 002, संपत्ति 300, आदि नामित किया जाएगा ...?

यदि ऐसा है, तो मैं आपको अपने डेटा सामान्यीकरण पर पुनर्विचार करने की सलाह देता हूं।

Answer 2

नियम के रूप में: तालिका को व्यापक रूप से प्रदर्शन को धीमा कर दें। एक टेबल की एक वसा गड़बड़ी के लिए कई पतली टेबल बेहतर हैं।

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

Answer 3

एक बहुत भयानक लगता है। मैं पहले यह सुनिश्चित करता हूं कि डेटा सामान्यीकृत है। यह आपकी समस्या का हिस्सा हो सकता है। यह डेटा किस प्रकार का उद्देश्य करेगा? क्या यह रिपोर्ट के लिए है? क्या डेटा बदल जाएगा?

मुझे लगता है कि एक टेबल जो व्यापक रूप से एक दुःस्वप्न प्रदर्शन और रख-रखाव के रूप में होगा।

Answer 4

कि बहुत अधिक है। 50 से अधिक कॉलम चौड़े और आप समस्याएं, कोड रखरखाव, और समस्या होने पर समस्या निवारण में परेशानी के लिए पूछ रहे हैं।

Answer 5

SQL2005 प्रलेखन से

:

SQL सर्वर 2005 डेटाबेस प्रति दो अरब टेबल और तालिका के अनुसार 1,024 कॉलम हो सकता है। (...) प्रति पंक्ति बाइट्स की अधिकतम संख्या 8,060 है। यह प्रतिबंध varchar, nvarchar, varbinary, या sql_variant कॉलम कि कारण कुल परिभाषित तालिका चौड़ाई 8060 बाइट्स से अधिक होने की साथ तालिकाओं के लिए ढील दी है। इन स्तंभों में से हर एक की लंबाई अभी भी 8,000 बाइट की सीमा में आते हैं चाहिए, लेकिन ये संयुक्त रूप से चौड़ाई एक तालिका में 8060 बाइट सीमा को पार कर सकता है।

इन स्तंभों की कार्यक्षमता क्या है? उन्हें मास्टर टेबल, गुण (लुकअप टेबल) और मूल्यों में बेहतर क्यों नहीं विभाजित करें?

Answer 6

एमएस एसक्यूएल सर्वर तालिका के अनुसार 1024 स्तंभों की एक सीमा होती है, ताकि आप सही इस के किनारे पर चल रहा हो जा रहे हैं। varchar (200) कॉलम का उपयोग करके आप के बाद से SQL डेटा पृष्ठ पर 8k स्टोर करेगा, और फिर पेज के बाहर डेटा अतिप्रवाह, पिछले पंक्ति सीमा प्रति 8k बाइट जाने में सक्षम हो जाएगा।

एसक्यूएल 2008 यह की तरह परिदृश्यों के लिए विरल कॉलम जोड़े गए - आप उन्हें में शून्य मान वाले स्तंभ का एक बहुत होगा जहां।

का प्रयोग विरल कॉलम http://msdn.microsoft.com/en-us/library/cc280604.aspx

Answer 7

इसमें बड़े प्रदर्शन और डेटा समस्याएं होंगी। इसे शायद सामान्यीकृत करने की जरूरत है।

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

यह पूछना भी एक वास्तविक समस्या होगी। डेटा के लिए देखने के लिए 1000 कॉलम में से कौन सा आपको पता चलेगा? क्या प्रत्येक प्रश्न खंड में सभी 1000 स्तंभों के लिए पूछना चाहिए?

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

कभी-कभी डेवलपर के रूप में आपको बस खड़े होना और कहना नहीं है, यह एक बुरा विचार है। यह उस काल में से एक है।

इसके बजाए आप क्या करते हैं (सामान्यीकृत करने के अलावा), मुझे लगता है कि आपको सही दिशा में आपको इंगित करने के लिए हमें और जानकारी चाहिए।

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

Answer 8

जब भी आपको यह पूछने की आवश्यकता महसूस होती है कि सिस्टम की सीमाएं क्या हैं, तो आपके पास डिज़ाइन समस्या है।

यदि आप पूछ रहे थे "मैं एक वर्चर्स में कितने पात्र फिट कर सकता हूं?" तो आपको बिल्कुल वर्चर्स का उपयोग नहीं करना चाहिए।

यदि आप गंभीरता से जानना चाहते हैं कि 1000 कॉलम ठीक है, तो आपको डेटा को पुनर्गठित करने की जरुरत है। (सामान्यीकरण)

Answer 9

क्या आप क्रॉसस्टैब क्वेरी के परिणामस्वरूप अपनी अंतिम (1000 कॉलम) तालिका देखने के बारे में सोचते थे? आपकी मूल तालिका में केवल कुछ कॉलम होंगे लेकिन कई हजार रिकॉर्ड होंगे।

क्या आप अपनी समस्या पर विस्तार से बता सकते हैं? मुझे लगता है कि कोई भी वास्तव में समझता है कि आपको इन 1000 कॉलम की आवश्यकता क्यों है!

Answer 10

मुझे यहां सभी के साथ असहमत होना है ..... मुझे पता है कि यह पागल लगता है लेकिन सैकड़ों कॉलम वाले टेबल का उपयोग करना सबसे अच्छी बात है जो मैंने कभी किया है।

हाँ कई कॉलम में अक्सर शून्य मान होते हैं; हां मैं इसे केवल कुछ तालिकाओं और ट्रांसफर करने के लिए सामान्य कर सकता हूं; हाँ, यह अक्षम

है हालांकि यह अविश्वसनीय रूप से तेजी से और अंतहीन अलग अलग तरीकों से में स्तंभ डेटा का विश्लेषण करने के लिए आसान है

व्यर्थ और असजीला - आप उपयोगी के रूप में कुछ भी निर्माण नहीं करेंगे!