चयन न करने का क्या कारण है *?


136

मैंने कई लोगों को यह दावा करते हुए देखा है कि आपको विशेष रूप से प्रत्येक कॉलम का नाम चाहिए जिसे आप अपनी चुनिंदा क्वेरी में चाहते हैं।

मुझे लगता है कि मैं वैसे भी सभी स्तंभों का उपयोग करने जा रहा हूं, मैं क्यों नहीं उपयोग करूंगा SELECT *?

यहां तक ​​कि प्रश्न पर विचार करते हुए * SQL क्वेरी - देखने से * का चयन करें या col1, col2,… देखने से colN * का चयन करें , मुझे नहीं लगता कि यह एक सटीक डुप्लिकेट है क्योंकि मैं इस मुद्दे को थोड़ा अलग दृष्टिकोण से आ रहा हूं।

हमारे सिद्धांतों में से एक यह समय से पहले अनुकूलन नहीं करना है। इसे ध्यान में रखते हुए, ऐसा लगता है कि जब तक यह एक संसाधन मुद्दा साबित नहीं हो जाता है या स्कीमा पत्थर में बहुत अधिक सेट हो जाता है, तब तक पसंदीदा तरीका SELECT *होना चाहिए । जैसा कि हम जानते हैं, विकास पूरी तरह से होने तक नहीं होगा।

उस ने कहा, वहाँ का उपयोग नहीं करने के लिए एक अधिभावी मुद्दा है SELECT *?

जवाबों:


168

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

जब आप सेलेक्ट * का उपयोग करते हैं, तो आप प्रोफ़ाइल करना असंभव बना देते हैं, इसलिए आप स्पष्ट और सीधा कोड नहीं लिख रहे हैं और आप उद्धरण की भावना के खिलाफ जा रहे हैं। select *एक विरोधी पैटर्न है।


इसलिए कॉलम का चयन करना समय से पहले का अनुकूलन नहीं है। मेरे सिर के ऊपर से कुछ चीजें ...।

  1. यदि आप किसी SQL कथन में कॉलम निर्दिष्ट करते हैं, तो SQL निष्पादन इंजन त्रुटि करेगा यदि उस स्तंभ को तालिका से हटा दिया गया है और क्वेरी निष्पादित की गई है।
  2. आप अधिक आसानी से कोड को स्कैन कर सकते हैं जहां उस कॉलम का उपयोग किया जा रहा है।
  3. आपको कम से कम जानकारी वापस लाने के लिए हमेशा क्वेरी लिखनी चाहिए।
  4. जैसा कि अन्य लोग उल्लेख करते हैं कि यदि आप क्रमिक कॉलम का उपयोग करते हैं तो आपको कभी भी चयन का उपयोग नहीं करना चाहिए *
  5. यदि आपका एसक्यूएल स्टेटमेंट टेबल से जुड़ता है, तो * ज्वाइन में सभी टेबलों से आपको सभी कॉलम सेलेक्ट करें

कोरोलरी है कि का उपयोग कर select *...

  1. एप्लिकेशन द्वारा उपयोग किए जाने वाले कॉलम अपारदर्शी हैं
  2. DBA और उनके क्वेरी प्रोफाइलर्स आपके एप्लिकेशन के खराब प्रदर्शन में मदद करने में असमर्थ हैं
  3. परिवर्तन होने पर कोड अधिक भंगुर होता है
  4. आपका डेटाबेस और नेटवर्क पीड़ित हैं क्योंकि वे बहुत अधिक डेटा वापस ला रहे हैं (I / O)
  5. डेटाबेस इंजन अनुकूलन कम कर रहे हैं क्योंकि आप सभी डेटा को वापस ला रहे हैं, भले ही (तार्किक)।

सही एसक्यूएल लिखना राइटिंग जितना आसान है Select *। इसलिए असली आलसी व्यक्ति उचित SQL लिखता है क्योंकि वे कोड को फिर से लिखना नहीं चाहते हैं और यह याद रखने की कोशिश करते हैं कि जब उन्होंने ऐसा किया था तो वे क्या कर रहे थे। वे DBA के हर बिट कोड के बारे में समझाना नहीं चाहते हैं। वे अपने ग्राहकों को यह समझाना नहीं चाहते हैं कि आवेदन कुत्ते की तरह क्यों चलता है।


2
आपके पहले खंड में, बिंदु # 5 को "चयन करें" आपको जुड़ने के सभी तालिकाओं से सभी कॉलम देता है । आपके दूसरे खंड में, अंक # 2 और # 5 आवश्यक नहीं हैं, और "चयनित *" का उपयोग न करने के कारणों के रूप में सूचीबद्ध नहीं होना चाहिए।
जिमीमोर

1
@uglysmurf - सुधार के लिए धन्यवाद, लेकिन 2 और 5 के संबंध में - जबकि वे जरूरी सभी डेटाबेस / dba के लिए सभी मामलों में सही नहीं हो सकते हैं, मुझे लगता है कि वे महत्वपूर्ण हैं और अधिकांश मामलों के लिए वैध हैं और उन्हें इसमें छोड़ देंगे। 'सेलेक्ट *' के इस्तेमाल से कभी भी डीबीए का काम आसान नहीं हुआ।
रॉबर्ट पॉलसन

11
मैं तर्क देता हूं कि # 3 (भंगुर कोड) वास्तव में सच नहीं है। कार्यान्वयन के आधार पर, चयन * इसे कम भंगुर बना सकता है, लेकिन मैं यह नहीं देखता कि यह अधिक कैसे हो सकता है।
जॉन एफएक्स

2
@ जॉनफैक्स, मुझे लगता है कि आप भंगुर को अलग तरह से परिभाषित करते हैं। भंगुर को आमतौर पर 'आसानी से टूटता' के रूप में परिभाषित किया जाता है। अज्ञात या हार्ड-टू-फ़ाइंड निर्भरता होने के कारण क्योंकि प्रत्येक कोड अलग-अलग कॉलम का उपयोग करेगा, इसका मतलब है कि मैं आसानी से पूर्ण प्रतिगमन के बिना डेटा स्तर पर कुछ भी नहीं बदल सकता .. जो भंगुर लगता है।
रॉबर्ट पॉलसन

9
@ mavnn, wrt brittleness, मुझे डर है कि यह शब्द भंगुर शब्द की मेरी पसंद पर एक शब्दार्थ अंक में विकसित हो रहा है। मेरा अंतिम शब्द यह कहना है कि इससे कुछ भी फर्क नहीं पड़ता है। एकमात्र परिदृश्य का नाम बदला / हटाए गए स्तंभ हैं। जब आप परिणामों का उपभोग कर रहे हों तो sql निष्पादित (स्पष्ट) बनाम ब्रेकिंग होने पर आप केवल ब्रेक को स्थानांतरित कर रहे हैं। जिस तरह से क्वेरी परिणाम का सेवन किया जाता है वह भिन्न हो सकता है, और कोड चुपचाप विफल हो सकता है या नहीं, लेकिन sql निष्पादन इंजन निश्चित रूप से अमान्य sql के साथ विफल हो जाएगा। तो क्या चयन * ने आपकी मदद की? एक DB मुद्दे के लिए DB के करीब IMO स्पष्ट विफलता बेहतर है। Thx
रॉबर्ट पॉलसन

42

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

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

यह योजना निष्पादन कैशिंग के लिए भी ओवरहेड जोड़ता है क्योंकि इसे यह जानने के लिए तालिका के बारे में मेटा डेटा प्राप्त करना है कि कॉलम * में क्या हैं।


4
अच्छा जवाब, लेकिन मैं "कोड तोड़ दूंगा" को "कोड मे तोड़ दूंगा"। यहाँ असली परेशानी यह है कि, "सेलेक्ट *" का उपयोग हमेशा एक ब्रेकिंग परिवर्तन नहीं करता है। और जब ब्रेक होता है, तो आमतौर पर उपयोग से बहुत कम कर दिया जाता है जो टूट जाता है।
बीक्यू।

4
यदि कोई व्यक्ति अपने कोड में कॉलम को संदर्भित कर रहा है, तो वे इस बात की परवाह किए बिना परेशान हैं कि वे SELECT * का उपयोग करते हैं या नहीं। योजना का निष्पादन ओवरहेड तुच्छ है, और इस योजना के पूरा होने के बाद वैसे भी कोई फर्क नहीं पड़ेगा।
मुसिएनेसिस

1
फिर प्रोग्रामर त्रुटि लेखन कोड में निहित है जो कॉलम के अनुक्रम पर निर्भर करता है। आपको ऐसा करने की कभी जरूरत नहीं है।
dkretz

1
@doofledorfer - कभी मत कहो। यह क्रमिक स्तंभों तक पहुंचने के लिए तेज़ है, और यह कई बार व्यावहारिक है। क्रमिक पहुँच का उपयोग करने के लिए चयन * का उपयोग करना एक बड़ी त्रुटि है।
रॉबर्ट पॉलसन

23

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


3
आपको कभी भी कोड नहीं लिखना चाहिए जो वैसे भी लौटे कॉलम की संख्या पर निर्भर करता है।
dkretz

4
लेकिन हर कोई कोड लिख रहा है जिसके लिए प्रोग्रामर्स को पता है कि कौन सा डेटा वापस आ रहा है। यदि आप किसी सेलेक्ट * में छिपे हैं तो आप अपने कॉलम का नाम Ctrl + F नहीं कर सकते।
लोटस नोट्स

17
  1. एक राउंडअबाउट तरीके से आप जहां भी संभव हो, सख्त टाइपिंग का उपयोग करने के बारे में मॉड्यूलरिटी नियम को तोड़ रहे हैं। स्पष्ट रूप से सार्वभौमिक लगभग बेहतर है।

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

    • आप तार पर अधिक डेटा खींच रहे हैं; तथा
    • क्योंकि आप तालिका के एक लुकअप को करने के बजाय इंडेक्स से डेटा को सही तरीके से खींचने के लिए अनुक्रमणिका (स्तंभों के प्रश्नों के लिए जो कि अनुक्रमणिका के सभी भाग हैं।) को हरा सकते हैं।

जब चुनें * का उपयोग करने के लिए

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


1
उपयोग करने का एक और समय SELECT *होगा जब आप db क्लाइंट का उपयोग करके परीक्षण क्वेरी कर रहे हों।
cdmckay

यह प्रश्न के संदर्भ को देखते हुए एक अजीब अपवाद जैसा लगता है। कुछ टाइपिंग को बचाने के अलावा, टेस्ट क्वेरी के लिए ऐसा करने से क्या फायदा है?
जॉन एफएक्स

इसके अलावा सेलेक्ट करें * FROM (सेलेक्ट ए, बी, सी फ्रॉम टेबल) ठीक है।
किमीकपलन

12

कुछ कारण हैं:

  1. यदि किसी डेटाबेस में कॉलम की संख्या बदल जाती है और आपका आवेदन एक निश्चित संख्या होने की उम्मीद करता है ...
  2. यदि डेटाबेस में कॉलम का क्रम बदलता है और आपका आवेदन उन्हें एक निश्चित क्रम में होने की उम्मीद करता है ...
  3. मेमोरी ओवरहेड। 8 अनावश्यक INTEGER कॉलम व्यर्थ स्मृति के 32 बाइट्स जोड़ देगा। यह बहुत अधिक ध्वनि नहीं करता है, लेकिन यह प्रत्येक क्वेरी के लिए है और INTEGER छोटे कॉलम प्रकारों में से एक है ... अतिरिक्त कॉलम VARCHAR या TEXT कॉलम होने की अधिक संभावना है, जो जल्दी जोड़ता है।
  4. नेटवर्क ओवरहेड। मेमोरी ओवरहेड से संबंधित: यदि मैं 30,000 प्रश्न जारी करता हूं और 8 अनावश्यक INTEGER कॉलम हैं, तो मैंने 960kB बैंडविड्थ को बर्बाद कर दिया है। VARCHAR और TEXT कॉलम काफी बड़े होने की संभावना है।

नोट: मैंने उपरोक्त उदाहरण में INTEGER को चुना क्योंकि उनका 4 बाइट का निश्चित आकार है।


1 और 2 एक कोड गंध और समय से पहले अनुकूलन की तरह 3 और 4 ध्वनि होगी
NikkyD

7

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

कहा जा रहा है, ऐसी कई स्थितियाँ हैं जिनमें SELECT * वांछनीय है। एक ऐसी स्थिति है जिसका मैं हर समय सामना करता हूं, जहां मुझे एक पूरी तालिका को किसी अन्य डेटाबेस (जैसे SQL सर्वर से DB2, उदाहरण के लिए) में दोहराने की आवश्यकता होती है। एक अन्य एक एप्लिकेशन है जिसे उदारतापूर्वक टेबल प्रदर्शित करने के लिए लिखा गया है (यानी किसी विशेष तालिका के ज्ञान के बिना)।


सवाल यह नहीं है कि "चयन * कभी वांछनीय है", इसलिए आपके उत्तर का दूसरा भाग अप्रासंगिक है। प्रश्न में कहा गया है कि 'चयन *' का उपयोग करना बेहतर होना चाहिए, जो निश्चित रूप से पूरा बोलबाला है।
रॉबर्ट पॉलसन

हां, मेरा दूसरा भाग अप्रासंगिक है। OQ ने प्रश्न को स्टेटस में बदल दिया है।
मुशीनेसिस

आह हाँ क्षमा करें - आपके उत्तर के बाद यह दिशा बदल गई।
रॉबर्ट पॉलसन

वह ठीक है। यहां तक ​​कि मोजार्ट एक संपादक था ( stackoverflow.com/questions/292682/… )। मेरी मूल पोस्ट ने सुझाव दिया कि SELECT * के उपयोग से नरभक्षण होता है। :)
मुशीनेसिस नोव

3

जब मैंने select *SQL Server 2005 में विचारों का उपयोग किया तो मुझे वास्तव में एक अजीब व्यवहार दिखाई दिया ।

निम्नलिखित क्वेरी चलाएँ और आप देखेंगे कि मेरा क्या मतलब है।

IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[starTest]') AND type in (N'U'))
DROP TABLE [dbo].[starTest]
CREATE TABLE [dbo].[starTest](
    [id] [int] IDENTITY(1,1) NOT NULL,
    [A] [varchar](50) NULL,
    [B] [varchar](50) NULL,
    [C] [varchar](50) NULL
) ON [PRIMARY]

GO

insert into dbo.starTest
select 'a1','b1','c1'
union all select 'a2','b2','c2'
union all select 'a3','b3','c3'

go
IF  EXISTS (SELECT * FROM sys.views WHERE object_id = OBJECT_ID(N'[dbo].[vStartest]'))
DROP VIEW [dbo].[vStartest]
go
create view dbo.vStartest as
select * from dbo.starTest
go

go
IF  EXISTS (SELECT * FROM sys.views WHERE object_id = OBJECT_ID(N'[dbo].[vExplicittest]'))
DROP VIEW [dbo].[vExplicittest]
go
create view dbo.[vExplicittest] as
select a,b,c from dbo.starTest
go


select a,b,c from dbo.vStartest
select a,b,c from dbo.vExplicitTest

IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[starTest]') AND type in (N'U'))
DROP TABLE [dbo].[starTest]
CREATE TABLE [dbo].[starTest](
    [id] [int] IDENTITY(1,1) NOT NULL,
    [A] [varchar](50) NULL,
    [B] [varchar](50) NULL,
    [D] [varchar](50) NULL,
    [C] [varchar](50) NULL
) ON [PRIMARY]

GO

insert into dbo.starTest
select 'a1','b1','d1','c1'
union all select 'a2','b2','d2','c2'
union all select 'a3','b3','d3','c3'

select a,b,c from dbo.vStartest
select a,b,c from dbo.vExplicittest

अंतिम 2 चुनिंदा कथनों के परिणामों की तुलना करें। मेरा मानना ​​है कि आप जो देखेंगे, वह नाम के बजाय इंडेक्स द्वारा सेलेक्ट * संदर्भित कॉलम का परिणाम है ।

यदि आप दृश्य को फिर से बनाते हैं तो यह फिर से ठीक काम करेगा।

संपादित करें

मैंने एक अलग प्रश्न जोड़ा है, * अधिक विवरण में उस व्यवहार को देखने के लिए SQL सर्वर 2005 में दिलचस्प व्यवहार "बनाम तालिका से" का चयन करें


2

आप दो तालिकाओं में शामिल हो सकते हैं और दूसरी तालिका से स्तंभ A का उपयोग कर सकते हैं। यदि आप बाद में पहली तालिका में स्तंभ A को जोड़ते हैं (एक ही नाम से, लेकिन संभवतः अलग-अलग अर्थों में) तो आपको सबसे पहले तालिका से मान प्राप्त होगा और पहले की तरह दूसरा नहीं। यदि आप उन कॉलमों को स्पष्ट रूप से निर्दिष्ट करते हैं जो आप चुनना चाहते हैं।

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


2

मैं समझता हूं कि आप समयपूर्व अनुकूलन के बारे में कहां जा रहे हैं, लेकिन यह वास्तव में केवल एक बिंदु पर जाता है। अनावश्यक से बचने का इरादा है शुरुआत में अनुकूलन । क्या आपकी टेबल अनइंस्टैंडेड हैं? क्या आप ज़िप कोड स्टोर करने के लिए nvarchar (4000) का उपयोग करेंगे?

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


2

जब आप कॉलम निर्दिष्ट कर रहे हैं, तो आप अपने आप को स्तंभों के एक विशिष्ट सेट में बांध रहे हैं और अपने आप को कम लचीला बना रहे हैं, जिससे फेउरस्टीन रोल कर रहे हैं, अच्छी तरह से, जहां भी वह है। सिर्फ एक विचार।


1
मुझे पूरी तरह से पता नहीं है कि फुएरस्टीन कौन है। गुगली करने की कोशिश की और एक मनोवैज्ञानिक, एक टेलीविजन चरित्र और एक ब्लॉगर पाया, तो सबसे अच्छा मैं एक मजाक के साथ आ सकता था।
NotMe 22

पीएल / एसक्यूएल पर ओ रेली पुस्तकों के लेखक। केवल "फ़्यूएर्स्टीन" के बजाय "फ़्यूअरस्टीन एसक्यूएल" को गोग्लिंग करने का प्रयास करें।
18

2

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

उदाहरण के लिए, मैं एक "सामान्य" तालिका से भौगोलिक ज्यामिति की गणना करना चाहता हूं, जो कि किसी भी ज्यामिति क्षेत्र के बिना एक तालिका है, लेकिन निर्देशांक वाले क्षेत्रों के साथ। मैं postgresql, और इसके स्थानिक विस्तार postgis का उपयोग करता हूं। लेकिन सिद्धांत कई अन्य मामलों के लिए लागू होता है।

एक उदाहरण:

  • x, y, z वाले क्षेत्रों में संग्रहीत निर्देशांक के साथ स्थानों की एक तालिका:

    रचना स्थान (पूर्णांक, x संख्यात्मक (10, 3), y सांख्यिक (10, 3), z संख्यात्मक (10, 3), विवरण varchar);

  • आइए इसे कुछ उदाहरण मूल्यों के साथ खिलाएं:

    INSERT INTO जगहें (place_id, x, y, z, description) VALUES
    (1, 2.295, 48.863, 64, 'पेरिस, प्लेस डे ल \' iletoile '),
    (2, 2.945, 48-858, 40,' पेरिस, टूर एफिल) '),
    (3, 0.373, 43.958, 90,' कंडोम, कैथेड्रल सेंट-पियरे ');

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

    बनाएँ या स्थानों को देखें_स्थानों का
    चयन करें *,
    GeomFromewkt ('SRID = 4326; POINT (' || x || '' || y || '' || z || ')')
    FROM स्थानों से।

    GeomFromewkt () फ़ंक्शन उपयोग के लिए पोस्टगिस का संदर्भ लें।

  • यहाँ परिणाम है:

    स्थानों से चुनें *

place_id | x | y | z | विवरण | geomfromewkt                            
---------- + ------- + -------- + -------- + ------------- ----------------- + -------------------------------- ------------------------------------  
        1 | २.२ ९ ५ | 48.863 | 64.000 | पेरिस, प्लेस डे l'iletoile | 01010000A0E61000005C8FC2F5285C02405839B4C8766E48400000000000005040  
        2 | 2.945 | 48.858 | 40.000 | पेरिस, टूर एफिल | 01010000A0E61000008FC2F5285C8F0740E7FBA9F1D26D48400000000000004440
        3 | 0.373 | 43.958 | 90.000 | कंडोम, कैथेड्रल सेंट-पियरे | 01010000A0E6100000AC1C5A643BDFD73FB4C876BE9FFA45400000000000805640
(3 लिग्नेस)

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

  • यदि, भविष्य में, कुछ फ़ील्ड्स तालिका में जुड़ जाती हैं: कोई चिंता नहीं है, मुझे बस फिर से वही VIEW परिभाषा चलाना है।

मेरी इच्छा है कि VIEW की परिभाषा "जैसा है" रखी जा सकती है, * के साथ, लेकिन hélas यह मामला नहीं है: यह है कि यह आंतरिक रूप से postgresql द्वारा कैसे संग्रहीत किया जाता है:

स्थानों का चयन करें ।place_id, places.x, places.y, places.z, places.description, geomfromewkt (((((((SRID = 4326; POINT (':: text || Places.x)' ': || : text) || Places.y) || '' :: पाठ) || Places.z) || ')' :: 'पाठ) AS geomfromewkt FROM स्थानों से?


1

यहां तक ​​कि अगर आप हर कॉलम का उपयोग करते हैं, लेकिन संख्यात्मक सूचकांक द्वारा पंक्ति सरणी को संबोधित करते हैं, तो आपको समस्या होगी यदि आप बाद में दूसरी पंक्ति जोड़ते हैं।

तो मूल रूप से यह स्थिरता का सवाल है! यदि आप * चयनकर्ता का उपयोग नहीं करते हैं, तो आपको अपने प्रश्नों के बारे में चिंता करने की आवश्यकता नहीं होगी।


1

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

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


1

यह आपके कोड को अधिक अस्पष्ट और बनाए रखने के लिए अधिक कठिन बनाता है; क्योंकि आप डोमेन में अतिरिक्त अप्रयुक्त डेटा जोड़ रहे हैं, और यह स्पष्ट नहीं है कि आपने क्या इरादा किया है और कौन सा नहीं। (यह भी पता चलता है कि आप नहीं जानते, या देखभाल कर सकते हैं।)


1

सीधे सवाल का जवाब देने के लिए: जब आप अपने कोड को अंतर्निहित तालिकाओं में परिवर्तन करने के लिए अधिक नाजुक बनाते हैं, तो "SELECT *" का उपयोग न करें। आपका कोड केवल तभी टूटना चाहिए जब एक परिवर्तन तालिका में किया जाता है जो सीधे आपके कार्यक्रम की आवश्यकताओं को प्रभावित करता है।

आपके एप्लिकेशन को एब्स्ट्रेक्शन लेयर का लाभ लेना चाहिए जो रिलेशनल एक्सेस प्रदान करता है।


1

मैं सिलेक्ट * का उपयोग केवल इसलिए नहीं करता क्योंकि यह देखना और जानना अच्छा है कि मैं किन क्षेत्रों को पुनः प्राप्त कर रहा हूं।


1

आम तौर पर विचारों के अंदर 'चयन *' का उपयोग करने के लिए बुरा है क्योंकि आप तालिका स्तंभ परिवर्तन की स्थिति में दृश्य को फिर से इकट्ठा करने के लिए मजबूर होंगे। किसी दृश्य के अंतर्निहित तालिका स्तंभों को बदलने से आपको गैर-विद्यमान स्तंभों के लिए एक त्रुटि मिलेगी जब तक कि आप वापस नहीं जाते और पुन: जमा नहीं करते।


1

यह ठीक है जब आप कर रहे हैं exists(select * ...)क्योंकि यह कभी विस्तारित नहीं होता है। अन्यथा यह वास्तव में केवल तब उपयोगी होता है जब अस्थायी चुनिंदा मूर्तियों के साथ तालिकाओं की खोज की जाती है या यदि आपके पास ऊपर एक सीटीई निर्धारित है और आप हर कॉलम को फिर से टाइप किए बिना चाहते हैं।


1

सिर्फ एक बात जोड़ने के लिए जिसका किसी और ने उल्लेख नहीं किया है। Select *सभी कॉलमों को लौटाता है, कोई व्यक्ति बाद में एक कॉलम जोड़ सकता है जो आप नहीं चाहते हैं कि उपयोगकर्ता ऐसे देख सकें, जिन्होंने आखिरी बार डेटा अपडेट किया हो या टाइमस्टैम्प या नोट जो केवल प्रबंधकों को ही नहीं देखना चाहिए, आदि।

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


0

क्योंकि "select *" मेमोरी को बेकार कर देगा जब आपको सभी फ़ील्ड की आवश्यकता नहीं होगी। लेकिन sql सर्वर के लिए, उनका प्रदर्शन समान है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.