हमने एक फाइल सिस्टम का उपयोग किया है जो कि श्रेणीबद्ध तरीके से आयोजित किया गया है: - भौगोलिक सीमा (देश या महाद्वीप) - डेटा प्रदाता, लाइसेंसकर्ता - डोमेन / डेटासेट - दिनांक / संस्करण
उसके बाद हमारे पास स्रोत डेटा को अलग करने की नीति है (उसी प्रारूप में जो किसी सीडी / डीवीडी पर थी जो हमें प्रदाता से मिली थी) किसी भी व्युत्पन्न डेटासेट से जो हमने अपनी कंपनी के भीतर उत्पादित किया था।
फ़ाइल सिस्टम ग्राहक के किसी भी डेटा को निगलना वास्तव में आसान बनाता है और भौतिक भंडारण के संदर्भ में कुछ लचीलेपन के लिए भी अनुमति देता है - हम अपने अभिलेखागार को बड़े, धीमे डिस्क पर रखते हैं और हमारे पास विशेष फ़ाइल सर्वर हैं (पारदर्शी रूप से पदानुक्रम में जुड़ा हुआ है) अधिक बार उपयोग किए जाने वाले डेटासेट।
परियोजनाओं के भीतर प्रबंधन की सुविधा के लिए, हम प्रतीकात्मक लिंक का उपयोग करते हैं। हम अपने वैक्टर को एक डेटाबेस (ओरेकल) में रखते हैं और हम इसे प्रति ग्राहक कम से कम एक डेटाबेस उदाहरण (और परियोजनाओं के लिए कई उपयोगकर्ता / स्कीमा) रखने का नियम बनाते हैं। हम एक डेटाबेस में कई आपदाओं को नहीं रख रहे हैं, हालांकि, वे एक के बाहर भी बहुत अधिक स्थान लेते हैं। इसके अलावा, हम अपने डेटाबेस उदाहरणों को यथासंभव हल्के रखना पसंद करते हैं।
और हां, हमारे पास पूरी चीजों को 'पुलिसिंग' के प्रभारी के रूप में रखा गया है ताकि यह बहुत गड़बड़ न हो।
वर्तमान में हमारे पास इस सेटअप के साथ सबसे बड़ा मुद्दा एक अच्छे उपयोगकर्ता इंटरफ़ेस की कमी है जो हमें पूरी चीज़ पर बेहतर अवलोकन करने में मदद करेगा, और हम सभी के शीर्ष पर मेटाडेटा स्टोरेज को शामिल करने की योजना बना रहे हैं। हम अभी भी अपने विकल्पों पर विचार कर रहे हैं।
हम अपने कोड के लिए संस्करण नियंत्रण का उपयोग कर रहे हैं और हमने इसे दस्तावेज़ों के लिए उपयोग किया है, लेकिन यह पता चला है कि संस्करण नियंत्रण वास्तव में बड़े डेटासेट के लिए नहीं बनाया गया है, खासकर यदि वे ज्यादातर बाइनरी फ़ाइलें हैं, इसलिए मैं इसकी अनुशंसा नहीं करूंगा , सिवाय अगर आप GML या कुछ इसी तरह के पाठ के साथ काम कर रहे हैं (समस्याओं में सर्वर-साइड डिस्क के उपयोग के साथ-साथ विशाल रिपॉजिटरी की जाँच करते समय दुर्घटनाग्रस्त होने वाले ग्राहकों पर भारी ओवरहेड शामिल हैं)।