प्रश्नों में अतिरिक्त रिक्त स्थान और लाइनब्रेक क्यों खराब हैं?

Question

मैं समय-समय पर देखता हूं कि लोग कहते हैं कि क्लाइंट अनुप्रयोग से सर्वर पर भेजे गए SQL क्वेरी में कोई अतिरिक्त लाइनब्रेक या रिक्त स्थान नहीं होना चाहिए। मैंने सुना है कि एक कारण है "नेटवर्क यातायात बर्बाद क्यों?"।

वहाँ कोई वास्तविक कोड को पढ़ने के लिए कठिन बनाने के लिए सभी रिक्त स्थान को हटाने के पक्ष में और संपादित कारण है?

रिक्त स्थान के साथ

:

$q = 'SELECT 
      `po`.*, 
      `u`.`nickname`, 
      `u`.`login` 
     FROM 
      `postponed_operations` AS `po` 
      LEFT JOIN `users` AS `u` ON `u`.`id` = `po`.`user_id` 
     ORDER BY `will_be_deleted_after`'; 
return mysql_query($q); 

बिना रिक्त स्थान:

$q = 'SELECT '. 
      '`po`.*,'. 
      '`u`.`nickname`,'. 
      '`u`.`login`'. 
     'FROM '. 
      '`postponed_operations` AS `po` '. 
      'LEFT JOIN `users` AS `u` ON `u`.`id`=`po`.`user_id` '. 
     'ORDER BY `will_be_deleted_after`'; 
return mysql_query($q); 

Answer 1

यह सच है, यह नेटवर्क यातायात और सर्वर के समय की लागत होगी; लेकिन यह सबसे चरम मामलों को छोड़कर सभी पर नगण्य होगा। अब, यदि आप फेसबुक (या Google, या इसी तरह) के कोड को संपादित कर रहे हैं, और इस तरह से 10 सबसे आम प्रश्नों को अनुकूलित करते हैं, तो एक बिंदु है, क्योंकि वे प्रति दिन अरबों बार चलाएंगे। लेकिन अन्य सभी मामलों में मुझे लगता है कि यह रिक्त स्थान को हटाने पर विचार करने का समय बर्बाद है।

Answer 2

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

Answer 3

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

अगर हम वेब के बारे में बात कर रहे थे, तो मैं कहूंगा कि करने में अतिरिक्त लागत संभावित सामग्री (स्क्रिप्ट फाइलें जो शायद ही कभी बदलती हैं और इस तरह के लिए) के लायक हो सकती हैं लेकिन मुझे गतिशील सामग्री के लिए ऐसा करने के बारे में संदेह होगा।

सभी मामलों में:

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

शायद आपके मामले में प्रासंगिक नहीं है, लेकिन मैं इसे किसी भी तरह से जिक्र करूंगा: हर बार क्वेरी को स्थानांतरित करने के बजाय एक क्वेरी आईडी के साथ कसकर पैक किए गए संदेश प्रारूप का उपयोग करने के लिए एक पूरी तरह से अलग दृष्टिकोण हो सकता है।

Answer 4

बिल्कुल। मैं हर समय ऐसा करता हूँ। मैं भी:

• बैकक्वॉट हटाएं। उन्हें किसकी जरूरत है?

इसलिए

, डेटाबेस, टेबल, खेतों, सूचकांक, आदि के लिए संभव के रूप में नाम

`po` ----- becomes -----> po 

• उपयोग के रूप में छोटे

इसलिए,

postponed_operations --- becomes ---> po --- p is already taken for posts 
will_be_deleted_after --- becomes ---> wi --- w is already taken for words 

• पूरी तरह से AS तरह अनावश्यक खोजशब्द छोड़ने।

  $q='SELECT po.*,ni,lo FROM po LEFT JOIN u ON i=ui ORDER BY wi' 
  

  ---

  टैग: सभी तालिका नाम वैसे भी कम (! नियम 2)

इसलिए,

LEFT JOIN `users` AS `u` --- becomes ---> LEFT JOIN u 

नतीजतन हैं, मैं के रूप में ऊपर क्वेरी लिखा है | :

joke

Answer 5

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

बल्कि आप पठनीयता और कोड के रख-रखाव के बारे में परेशान करना चाहिए। सॉफ़्टवेयर कोड लिखते समय ये दो महत्वपूर्ण चीजें हैं जिन्हें आपको ध्यान में रखने की आवश्यकता है!

तो नेटवर्क ट्रैफिक को कम ही अच्छी बात थी, तो हम बहस सकता है कि आप हर क्वेरी आपके द्वारा लिखी जाने के लिए एक Stored Procedure बनाना चाहिए।

उदाहरण के लिए। आप

CALL GetLoginData(); 

को 80-95% की कमी निम्न क्वेरी

SELECT 
      `po`.*, 
      `u`.`nickname`, 
      `u`.`login` 
     FROM 
      `postponed_operations` AS `po` 
      LEFT JOIN `users` AS `u` ON `u`.`id` = `po`.`user_id` 
     ORDER BY `will_be_deleted_after`; 

बदल सकता है अब जब कि हो सकता है ~। क्या यह इतना कीमती है?

निश्चित रूप से नहीं।

इन तरह बातें नहीं बल्कि किसी भी महत्वपूर्ण मूल्य जोड़ने के बिना डेवलपर्स के जीवन दुखी होगा करना!

कहा जा रहा है, केवल स्थानों पर जहां कोई भी कोड को बदलने की जाएगी पर कोड की minified संस्करण का उपयोग करें। उदाहरण के लिए। सीएसएस पुस्तकालयों और जेएस पुस्तकालयों कि आप कभी बदल नहीं होगा!

मुझे आशा है कि आप बिंदु मिल गया है, और आप पठनीय और अनुरक्षणीय कोड लिखने के लिए जारी रहेगा!