एक ही पंक्ति के साथ एसक्यूएल टेबल?

Question

डेटाबेस में एक तालिका केवल एक पंक्ति के साथ रखने के लिए बिंदु (यदि कोई है) क्या है?

नोट: मैं किसी तालिका में केवल एक पंक्ति रखने की संभावना के बारे में बात नहीं कर रहा हूं, लेकिन जब कोई डेवलपर जानबूझकर एक टेबल बनाता है जिसका उद्देश्य हमेशा एक पंक्ति है।

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

बिक्री कर उदाहरण के लिए एक अच्छा एक है।

मैंने अभी कुछ कोड में देखा है, मैं तीन अलग-अलग तालिकाओं की समीक्षा कर रहा हूं जिसमें तीन अलग-अलग प्रकार के प्रमाणपत्र (एक ला एसएसएल) हैं, जिनमें से प्रत्येक में एक पंक्ति है। मुझे समझ में नहीं आता कि यह एक बड़ी मेज में क्यों नहीं बनाया गया है; मुझे लगता है कि मुझे कुछ याद आ रहा है।

Answer 1

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

मैंने अभी कुछ कोड में देखा है, मैं तीन अलग-अलग तालिकाओं की समीक्षा कर रहा हूं जिसमें तीन अलग-अलग प्रकार के प्रमाणपत्र (एक ला एसएसएल) हैं, जिनमें से प्रत्येक में एक पंक्ति है। मुझे समझ में नहीं आता कि यह एक पंक्ति में क्यों नहीं बनाया गया है; मुझे लगता है कि मुझे कुछ याद आ रहा है।

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

Answer 2

डाटाबेस सिस्टम प्रदान नहीं करता कुछ सुविधाओं को अनुकरण करने के लिए कभी-कभी उपयोगी हो सकता है। उदाहरण के लिए मैं MySQL में अनुक्रमों के बारे में सोच रहा हूं।

Answer 3

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

Answer 4

यह एक बुरा विचार नहीं है।

क्या होगा यदि आपके पास कुछ वैश्विक स्थिति (कहना, एक बूलियन) था जिसे आप कहीं स्टोर करना चाहते थे? और आप चाहते थे कि आपकी संग्रहीत प्रक्रियाएं आसानी से इस राज्य तक पहुंच सकें?

आप एक प्राथमिक कुंजी के साथ एक तालिका बना सकते हैं जिसका मूल्य सीमा बिल्कुल एक मान तक सीमित थी।

Answer 5

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

Answer 6

डेटाबेस में केवल एक पंक्ति के साथ तालिका रखने में बिंदु (यदि कोई है) क्या है?

एक रिलेशनल डेटाबेस चीजों को संबंधों के रूप में संग्रहीत करता है: डेटा के एक tuples कुछ संबंध संतुष्ट।

पसंद है, यह एक: " यह कई प्रतिशत मेरे देश में अब प्रभावी है"।

यदि केवल एक टुपल इस संबंध को संतुष्ट करता है, तो हाँ, यह तालिका में केवल एक ही होगा।

SQL चर को स्टोर नहीं कर सकता: यह 1 तत्व युक्त एक सेट स्टोर कर सकता है, यह एक पंक्ति वाली तालिका है।

इसके अलावा, SQL एक सेट आधारित भाषा है, और कुछ परिचालनों के लिए आपको निरंतर अभिव्यक्ति का चयन करने के लिए केवल एक पंक्ति का नकली सेट चाहिए।

Oracle में आप कुछ भी नहीं SELECT नहीं कर सकते हैं, तो आपको FROM खंड की आवश्यकता है।

Oracle में एक छद्म, dual है, जिसमें केवल एक पंक्ति और केवल एक कॉलम है।

एक बार, बहुत समय पहले, यह दो पंक्तियों (इसलिए नाम dual) किया करते थे, लेकिन संस्करण 7 की राह पर कहीं न कहीं अपनी दूसरी पंक्ति खो दिया है।

MySQL में यह छद्म भी है, लेकिन MySQLFROM खंड के बिना चयन करने में सक्षम है। फिर भी, यह उपयोगी है जब आप एक खाली rowset की जरूरत है: SELECT 1 FROM dual WHERE NULL

मैं बस कुछ कोड मैं तीन अलग-अलग टेबल कि प्रमाण पत्र के तीन अलग अलग प्रकार के होते हैं की समीक्षा कर रहा हूँ में मनाया गया है (एक ला SSL), प्रत्येक ठीक एक होने पंक्ति। मुझे समझ में नहीं आता कि यह एक बड़ी मेज में क्यों नहीं बनाया गया है; मुझे लगता है कि मुझे कुछ याद आ रहा है। यदि कोई हो प्रमाण पत्र याद आ रही है, पूरे क्वेरी कुछ भी नहीं देता है, तो

SELECT * 
FROM ssl1 
CROSS JOIN 
     ssl2 
CROSS JOIN 
     ssl3 

:

यह एक तरह का परिदृश्य, जब सभी तीन प्रमाण पत्र एक ही बार में की जरूरत है हो सकता है "यह सब है या खो" ।

Answer 7

एक पंक्ति के साथ एक तालिका का उपयोग सभी स्तर उपयोगकर्ताओं के लिए साझा किए गए एप्लिकेशन स्तर सेटिंग्स को संग्रहीत करने के लिए किया जा सकता है। उदाहरण के लिए 'अधिकतम अनुमत उपयोगकर्ता'।

Answer 8

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

Answer 9

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

Answer 10

यदि आपका डेटाबेस आपका एप्लिकेशन है, तो संभवतः यह कॉन्फ़िगरेशन डेटा संग्रहीत करने के लिए समझ में आता है जो व्यावसायिक तर्क को लागू करने वाली संग्रहीत प्रक्रियाओं द्वारा आवश्यक हो सकता है।

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

Answer 11

विरासत में प्राप्त एक परियोजना में इस तरह की एक सारणी स्थापित की गई थी। यह कॉन्फ़िगरेशन डेटा के लिए था, और कारण दिया गया था कि यह बहुत ही सरल प्रश्नों के लिए बनाया गया था:

SELECT WidgetSize FROM ConfigTable 
SELECT FooLength FROM ConfigTable 

ठीक है ठीक है। हमने एक सामान्यीकृत कॉन्फ़िगरेशन तालिका में परिवर्तित किया:

ID Name IntValue StringValue TextValue 

इसने हमारे उद्देश्यों को अच्छी तरह से सेवा दी है।

Answer 12

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

Settings.admin_password = 'supersecret' 
    Settings.date_format = '%m %d, %Y' 
    Settings.cocktails  = ['Martini', 'Screwdriver', 'White Russian'] 
    Settings.foo   = 123 

सभी सेटिंग्स की एक सूची चाहते हैं:

Answer 13

मैं इस http://github.com/Squeegy/rails-settings/tree/master

यह स्थापित करने के लिए वास्तव में आसान है और एक अच्छा वाक्य रचना प्रदान करता है के लिए पूरी तरह से भयानक रेल-सेटिंग्स प्लगइन का उपयोग?

Settings.all   # returns {'admin_password' => 'super_secret', 'date_format' => '%m %d, %Y'} 

अपने ऐप की कुछ सेटिंग्स के लिए डिफ़ॉल्ट सेट करें। इससे परिभाषित सेटिंग्स निर्दिष्ट मान के साथ वापस आ जाएंगी भले ही वे डेटाबेस में न हों। निम्नलिखित के साथ config/initializers/settings.rb में एक नई फ़ाइल बनाएँ:

Settings.defaults[:some_setting] = 'footastic' 

Answer 14

CREATE TABLE VERSION (VERSION_STRING VARCHAR2(20 BYTE)) 

?

Answer 15

मैंने एक गतिशील वेब पेज में एक काउंटर के रूप में SQLite डेटाबेस में एक एकल डेटाम का उपयोग किया। यह सबसे आसान तरीका है जिसे मैं इसे थ्रेड-सुरक्षित (या सटीक होने के लिए प्रक्रिया-सुरक्षित) बनाने के बारे में सोच सकता हूं। लेकिन मुझे यकीन नहीं है कि यह एक अच्छा विचार है या नहीं।

Answer 16

एकल पंक्ति सिंगलटन कक्षा की तरह है। उद्देश्य: किसी अन्य प्रक्रिया को नियंत्रित या प्रबंधित करने के लिए।

एकल पंक्ति तालिका एक महत्वपूर्ण अनुभाग या के रूप में नियतात्मक आटोमैटिक मशीन (डिस्पैचर की तरह पंक्ति मूल्यों पर आधारित)

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

एकल पंक्ति का उपयोग वैट या दिनांक या समय जैसे वास्तविक मूल्य को पूरा करने के लिए किया जाता है, और इसी तरह।

Answer 17

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

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

Answer 18

इसका उपयोग डेटाबेस के वर्तमान संस्करण को संग्रहीत करने के लिए किया जा सकता है।

यदि कोई स्कीमा परिवर्तनों के लिए डेटाबेस संस्करण संग्रहीत कर रहा था तो उसे डेटाबेस के भीतर ही रहना होगा।

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

मैं vb.net और sql एक्सप्रेस