"एक्स और वाई के बीच" क्या कम्यूटेटिव होना चाहिए?

26

मेरे आवेदन में कुछ पूर्वनिर्धारित अभिव्यक्ति टेम्पलेट हैं जिनका उपयोग डेटा को फ़िल्टर करने के लिए किया जा सकता है। उनमें से एक " between x and y" है। एक क्यूए इंजीनियर का दावा है कि इसकी परिभाषा में एक दोष है, क्योंकि " between 100 and 200" " " की तुलना में अलग परिणाम देता है between 200 and 100। अभिव्यक्ति आंतरिक रूप से " value >= x and value <= y" के लिए अनुवादित है , इसलिए स्पष्ट रूप से कोई परिणाम नहीं है जब दूसरी सीमा पहले की तुलना में कम है। मैंने जाँच की है कि समान व्यवहार SQL में है - " between x and y" मानता है कि y> = x या कोई परिणाम नहीं है। इसका मतलब है कि ऑपरेटर कम से कम एसक्यूएल में कम्यूटेटिव नहीं है।

तो, क्या QA सही है कि " between x and y" कम्यूटेटिव होना चाहिए?

requirements

— pkalinow
स्रोत

11

नहीं, लेकिन शायद आपके उई को लाल होना चाहिए जब कोई इसे गलत तरीके से भरता है।

— इवान

3

इसके अलावा, यह उन लोगों में से एक है = = <= अनन्य होना चाहिए ताकि आप 100-> 200 200-> 300 आदि को ओवरलैप किए बिना श्रृंखला बना सकें

— ईवान

23

यह स्पष्ट नहीं है betweenकि निम्न और उच्च मूल्यों को शामिल करना चाहिए या बाहर करना चाहिए। क्यूए व्यक्ति पांडित्य हो सकता है लेकिन जब तक अनिश्चितता है किसी को उपयोगकर्ता की कहानियों / आवश्यकताओं को स्पष्ट करने की आवश्यकता है। यह पता चल सकता है कि वे ऐसा कर रहे हैं कि यह कैसे होना चाहिए, लेकिन एक निर्णय किया जाना है।

— बेंट

11

यह सही या गलत का मामला नहीं है। यह एक मामला है ... व्यापार कैसे आवेदन व्यवहार करना चाहता है? उत्तर वह है जो कार्यक्षमता अपेक्षित है। तकनीकी बहस आवश्यक कार्यक्षमता नहीं चलाती है। आवश्यक कार्यक्षमता तकनीकी बहस ड्राइव करती है और उम्मीद है कि व्यवसाय के लिए सबसे अच्छा समाधान प्रेरित करती है।

— ब्रैड थॉमस

2

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

— मकेन

32

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

SQL मानक का यथासंभव निकटता से पालन करना
एर्गोनॉमिक्स, विशिष्ट उपयोग के मामलों, या अन्य आवश्यकताओं के कारण इसका पालन नहीं कर रहा है

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

— डॉक्टर ब्राउन
स्रोत

57

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

— मैथ्यू एम।

1

@MatthieuM। मुझे लगता है कि इसका एक अलग उत्तर है, जिसके 33 उत्थान होने चाहिए। ;)

— jpmc26

1

बग को सुधार में बदलें और इसे सदा के लिए बैकलॉग में छोड़ दें। उनकी परिश्रम के लिए QA को धन्यवाद।

— सैंडी चैपमैन

1

@MatthieuM। हां, आदर्श दुनिया में हर विवरण के लिए एक स्पष्ट आवश्यकता होगी। ऐसे मामले में मुझे स्टैक एक्सचेंज पर सवाल पूछने की आवश्यकता नहीं होगी :)

— पल्किनो

@pkalinow: मुझे लगता है कि आपने मेरी टिप्पणी को गलत समझा। मेरा कहना था कि बग को बंद करने से पहले , आपको (1) QA के आदमी को एक अंडरस्क्राइब किए गए कोड को इंगित करने के लिए धन्यवाद देना चाहिए और (2) जो भी वास्तव में व्यवहार को निर्दिष्ट करने के लिए इच्छुक है, उसके साथ बैठें। इसका मतलब यह हो सकता है कि क्यूए रिपोर्ट को जिसे भी निर्दिष्ट करना है, उत्पाद स्वामी को विनिर्देशों को लिखने के आरोप में है, यदि आपके पास ऐसी चीजें हैं आदि ... तो, एक बार जब यह व्यवहार पर सहमत होना चाहिए था, तो आप मूल्यांकन कर सकते हैं कि क्या सॉफ्टवेयर में बदलाव की जरूरत है या नहीं। शायद इसका मतलब सॉफ्टवेयर बदलना होगा, हो सकता है इसका मतलब रिपोर्ट को बंद करना हो ...

— Matthieu M.

13

यह एक प्रयोज्य या उपयोगकर्ता अनुभव प्रश्न है। SQL या कोई अन्य सिस्टम कैसे व्यवहार करता है यह अप्रासंगिक है, सवाल यह है कि उपयोगकर्ताओं के दृष्टिकोण से सबसे अधिक समझ में आता है।

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

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

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

— JacquesB
स्रोत

11

कुछ समझदार विकल्प हैं, और जो चुनना है वह बाकी सिस्टम और आपके उपयोगकर्ताओं की अपेक्षाओं पर निर्भर है।

जैसा कि QA इंजीनियर बताते हैं, आप केवल अभिव्यक्ति को सकारात्मक बना सकते हैं, और तब अनुवाद होगा

between x and y => value >= min(x, y) and value <= max(x, y)

आप वैध उपयोग को प्रतिबंधित कर सकते हैं x <= y, जिसके लिए आवश्यक है कि आपका UI "जितनी जल्दी हो सके एक वैध अभिव्यक्ति नहीं" प्रदर्शित कर सकता है।

उपरोक्त भिन्नता के रूप में, x < yयदि आपके पास एक अभिव्यक्ति है equals xऔर प्रतिबंध है कि मूल्यांकन करना पसंद करते हैंvalue >= x and value <= x

— Caleth
स्रोत

नोट: कृपया खुद ही बयान न करें value >= min(x, y) and value <= max(x, y)। अपने डेटाबेस सर्वर के काम को बचाने के लिए आप जो कर सकते हैं उसे पहले से बताएं, खासकर अगर यह उस तरह से बेमानी है (आप एक बार संबंधित ऑपरेशन कर सकते हैं और तदनुसार दोनों परिणाम सेट कर सकते हैं)। डेटाबेस सर्वर और आपके द्वारा फीड किए जा रहे विशिष्ट मूल्यों के आधार पर यह मायने नहीं रख सकता है, लेकिन खराब-लिखा SQL सर्वर अच्छी तरह से minऔर हर रिकॉर्ड केmax लिए प्रदर्शन कर सकता है यदि आप उन्हें डालते हैं , और यदि आप उस प्रयास को समाप्त कर सकते हैं , कोई कारण नहीं है। where

— निधि मोनिका का मुकदमा

6

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

— डॉक्टर ब्राउन

@DocBrown मैं मानता हूं कि हमें माप के बिना संभावित प्रदर्शन लाभ के लिए बदलाव नहीं करना चाहिए, लेकिन आपके दावे के विपरीत मुझे एक-लाइनर की तुलना में पहले से गणना की गई सीमाओं को अधिक पठनीय लगेगा, और इस तरह अधिक बनाए रखने योग्य।

— जैकब राइले

@JacobRaihle: यह माना जा सकता है, लेकिन मेरे स्वाद के value >= min(x, y) and value <= max(x, y)लिए पठनीय है value >= minXY and value <= maxXY, जहां minXYऔर जहां पहले maxXYसे निर्धारित सीमाएं हैं। हालाँकि, बाद वाले के लिए सिस्टम में इन नए दो वेरिएबल्स को जोड़ने के लिए कुछ कोड लिखना होगा, उन्हें पहले से भरना होगा, जब x और y में परिवर्तन होता है, और इसी तरह इन मूल्यों को अपडेट करना न भूलें। निरर्थक डेटा हमेशा त्रुटियों का एक निश्चित जोखिम पेश करता है।

— डॉक ब्राउन

5

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

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

Backwards range given, OK to swap (y/n)?

यदि आपके QA इंजीनियर के पास UX के रास्ते में कुछ भी नहीं था, तो उसे यह दिखाने के लिए कि एक औंधा रेंज अवांछनीय होगा, तो उसने एक उचित धारणा बनाई।

— कार्ल बेवफेल्ड
स्रोत

2

सच कहूं? "बीच" का उपयोग न करें। बिलकुल।

पहला, यह शब्द अविश्वसनीय रूप से अस्पष्ट है, खासकर अंग्रेजी में। क्या यह सराहनीय है? क्या शब्द अनन्य हैं? समावेशी?

दूसरा, यदि आप बैकएंड से तलाकशुदा इंटरफ़ेस कर रहे हैं, तो बैकएंड व्यवहार के बारे में चिंता न करें; और अपने उपयोगकर्ताओं को विरासत में मिले व्यवहार को मानने न दें। निश्चित रूप से, SQL BETWEENइसे समावेशी के रूप में परिभाषित करता है , लेकिन यह लगभग कभी भी वांछित व्यवहार नहीं है (उदाहरण के लिए - यदि आप कुछ ऐसा करते हैं जैसे rows BETWEEN :start and :start + :strideआप stride + 1पंक्तियों को प्राप्त करने जा रहे हैं )।

इसके बजाय, आपको एंडपॉइंट के लिए तुलनाओं को स्पष्ट रूप से सूचीबद्ध करना चाहिए। "X के बराबर या उससे अधिक"। "आज से पहले"। इससे अस्पष्टता दूर होती है। यह क्लीनर कोड लिखने में भी मदद करता है, और कुछ कपटी त्रुटियों से बचता है। पहले से पंक्तियाँ उदाहरण के लिए अनिवार्य रूप से अनुक्रमण के बारे में जिक्स्ट्रा का पद है । और SQL को कुछ प्रकारों पर एक समावेशी ऊपरी बाउंड का उपयोग करने की अनुमति देने से गलत डेटा का चयन किया जा सकता है ।

— घड़ी की कल-विचार
स्रोत

खैर, यह सोचने लायक है। और लिंक के लिए धन्यवाद। दिज्क्स्ट्रा का पद शायद बहुत प्रासंगिक नहीं है, लेकिन दिलचस्प है :)

— pkalinow

यह वास्तव में ओपी प्रश्न का उत्तर नहीं देता है, इसके बजाय, यह भ्रम में जोड़ता है।

— रोलैंड टीप

1

यह आपके क्यूए के साथ बहस करने के लिए गैर-उत्पादक है कि कौन "सही" है और कौन "गलत" है। आपने कल्पना की थी कि वे क्या करते हैं। इसका मतलब है कि यह कल्पना पर्याप्त अस्पष्ट है कि इसे स्पष्टीकरण की आवश्यकता है।

यदि उपयोगकर्ता इंटरफ़ेस कल्पना है, और यह वह व्यवहार नहीं है जो QA की अपेक्षा है, तो यह कम से कम कुछ उपयोगकर्ताओं द्वारा अपेक्षित व्यवहार नहीं होने वाला है। यह एक प्रयोज्य समस्या को इंगित करता है (भले ही आप PEBKAC बहस करना चाहते हैं)। उस के लिए एक संतोषजनक समाधान खोजने के लिए अपने QA के साथ काम करें।

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

— Martijn
स्रोत

1

मैं एक यूनिक्स सिद्धांत को कांटा करूँगा जो सरल इंटरफेस के बारे में बात करता है।

जहां कहीं भी एक इंटरफ़ेस है जो आप बाहरी दुनिया को दे रहे हैं, तो कम से कम आश्चर्य की बात रखें!

अब जब मैंने समस्या बयान को और अधिक व्यावहारिक रूप से कम कर दिया है, मुझे लगता है कि आपको यह महसूस करने में कुछ ही क्षण लगेंगे कि जब संख्या सीमा निर्दिष्ट की जाती है, तो यह स्पष्ट है कि *** छोटे को पूर्व *** के रूप में रखें। यदि यह अभी भी एक पहेली है, तो इस तरह से सोचें- आपने कितनी बार बच्चों की तुलना करते हुए दो नंबर का प्रतिनिधित्व करने के रिवर्स तरीके का उपयोग किया है?

यदि आपका QA इंजीनियर इसे बग कहता है, तो उसे विनम्रता से बताएं कि आप कुछ वास्तविक बगों की उम्मीद कर रहे हैं , न कि तुच्छ चीजों पर महंगी ऊर्जा बीम करने के तरीके।

— an4
स्रोत

0

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

— ग्रिमाल्डी
स्रोत