transactional database normalized होते हैं तो reporting table आमतौर पर denormalized क्यों होती हैं?

normalization write और अखंडता के लिए बेहतर बनाता है, इसलिए transactional database डेटा दोहराने से बचता है और एक ही जगह एक पंक्ति अपडेट करता है। reporting बड़े scan पर read के लिए बेहतर बनाई जाती है, जहां हर join वक्त खाता है और हर अतिरिक्त table एनालिस्ट की स्पष्टता खाती है। denormalized star schema का मतलब है कम join, columnar storage पर तेज query, और ऐसे column नाम जिन्हें एनालिस्ट बिना data dictionary के समझ सके।

वे अलग अलग समस्याएं हल कर रहे हैं। transactional database सख्त अखंडता के साथ बहुत सारे छोटे write के लिए बना है, तो normalize करने का मतलब है कि किसी ग्राहक का पता एक ही बार मौजूद है और उसे अपडेट करना एक write है। analytics table एक बार में लाखों पंक्तियां scan करने के लिए बनी है, जहां हर join एक लागत है और पंद्रह table का join धीमा भी है और सही करना मुश्किल भी। इसलिए हम fact और conformed dimension में denormalize करते हैं, जिससे join कटते हैं और एनालिस्ट को schema का आरेख और तीन lookup table के बजाय पढ़ने लायक column नाम मिलते हैं। columnar storage इसे सस्ता बनाता है, क्योंकि लाखों पंक्तियों में एक ही country की string दोहराना compress होकर लगभग कुछ नहीं रह जाता। दूसरी वजह ऑपरेशनल है। production database के खिलाफ कोई भारी analytical scan चलाना application के साथ संसाधनों की होड़ करता है, और मैंने एक ad hoc query को checkout service गिराते देखा है। modeling को पूरी तरह छोड़ भी दें, तो analytics का workload वहीं होना चाहिए जहां वह ग्राहकों को नुकसान न पहुंचा सके।