यह आपके उपयोग पर थोड़ा सा निर्भर करता है। सामान्यीकृत दृष्टिकोण (पार्क एक टेबल है) निम्नलिखित प्रश्नों को आसान बना देगा:
- प्रत्येक पार्क में कितने पक्षी देखे गए हैं
- आप किस पार्क में XYZ पक्षी देखने की सबसे अधिक संभावना रखते हैं
- शायद इस तरह की कुछ और क्वेरीज़ हैं
लेकिन हाँ, आप कुछ चिपचिपे मुद्दों में भाग लेते हैं। पैटर्न "यदि पार्क XYZ मौजूद नहीं है तो इसे पार्क टेबल में डालें" एक दौड़ की स्थिति से ग्रस्त है जिससे आपको निपटना होगा।
अब, यहां सामान्यीकरण के खिलाफ कुछ तर्कों के बारे में कैसे ... अधिकांश ग्राहक डेटाबेस शायद सड़क के नाम को गतिशील रूप से सामान्य किए बिना मेरे सड़क के पते को "123 फू स्ट्रीट" के रूप में संग्रहीत करते हैं (हम एक सड़क तालिका रख सकते हैं और वहां "फू स्ट्रीट" डाल सकते हैं, फिर संदर्भ इसे अन्य तालिकाओं से। मैं इसे क्यों लाऊं, यह दिखाने के लिए कि जो लोग किसी भी दोहराए गए डेटा से नफरत करते हैं, वे शायद स्वीकार करेंगे कि कुछ ऐसी रेखा है जिसे आपको पार करने की आवश्यकता नहीं है।
एक और मूर्खतापूर्ण उदाहरण यह होगा कि हम उपनाम साझा कर सकते हैं। क्या हमें वास्तव में अद्वितीय अंतिम नामों के लिए एक तालिका और फिर अन्य तालिकाओं से विदेशी कुंजी की आवश्यकता है? कुछ एप्लिकेशन हो सकते हैं जहां यह सहायक होता है लेकिन 99% एप्लिकेशन के लिए, यह बहुत दूर जाता है। यह केवल अधिक काम है और कम या बिना किसी लाभ के कम प्रदर्शन करने वाला है।
तो मैं इस बात पर विचार करता हूं कि मैं तालिका से डेटा को वापस क्वेरी करने में सक्षम होना चाहता हूं। ईमानदारी से इस मामले में मैं शायद पार्कों के लिए एक अलग टेबल करूँगा। लेकिन अन्य मामलों में मैंने नहीं चुना है।
यह मेरे दो सेंट हैं, करों के बाद एक प्रतिशत।
