डेटाबेस तालिकाओं/क्षेत्रों आप हमेशा अपने हत्यारा में उपयोग एप्लिकेशन

Question

मैं कुछ सामूहिक अनुभव यहाँ का दोहन करने की उम्मीद कर रही है, इसलिए क्या (यदि हो तो) उपयोगिता टेबल, या सामान्य फ़ील्ड अपने डेटाबेस डिजाइन में आप हमेशा शामिल करते हैं?

एक उदाहरण है कि मैं हमेशा किसी भी न आया हुआ अपवाद जानकारी स्टोर करने के लिए एक App_Errors मेज, और एक App_Audit तालिका जो सभी संपादित जानकारी संग्रहीत करता है शामिल है।

मैंने प्रत्येक डेटा तालिका पर RecordCreatedDate और RecordLastEditedDate सहित लाभ (मेरे अपने दिमाग में) का लाभ उठाया है, लेकिन किसी भी निष्कर्ष पर नहीं आया है कि जानकारी वास्तव में उपयोगी होगी या नहीं।

सवाल थोड़ा अधिक दिशा देने के लिए - मेरे वर्तमान फोकस विश्व स्तर पर सुलभ वेब अनुप्रयोग (लगता है सामाजिक नेटवर्किंग) है।

ता!

Answer 1

1 एक तालिका जिसमें संस्करण संख्या है, इसलिए ऐप आसानी से स्कीमा के संस्करण की जांच कर सकता है।

2 तालिका एक विन्यास फाइल की तरह मनमाने ढंग से चर/मान युग्म धारण करने के लिए, है, लेकिन डेटाबेस में। हर तालिका, पूर्णांक (आप संस्करण संख्या यहाँ में डाल सकते हैं ....)

Answer 2

यह क्या करता है की परवाह किए बिना, हमेशा एक "आईडी" क्षेत्र के साथ शुरू होता है,।

मैं भी एक त्रुटियाँ तालिका, जो आईडी, दिनांक, विफल विधि और अधिभार, और एक स्टैक ट्रेस उपलब्ध करता है, तो भी शामिल है को बचाने के।

कभी-कभी मेरे पास सेटिंग्स/आंकड़े तालिका होती है, लेकिन हमेशा नहीं।

Answer 3

मैंने डेटा को बदलने और किसके द्वारा ट्रैक किया गया है, इसका ट्रैक रखने के लिए मैंने अक्सर ऑडिट लॉग तालिका का उपयोग किया है।

आप आश्चर्यचकित होंगे कि यह कितना नियमित रूप से लाभान्वित रहा है।

कुछ अन्य जो मॉडल मैं काम करता हूं, उसमें कुछ और है जो स्थिति तालिका पर भिन्नता है, आमतौर पर प्राथमिक इकाई की स्थिति जीवन चक्र से संबंधित है।

Answer 4

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

Answer 5

रिपोर्टिंग के लिए, एक संख्या तालिका (1mil 0 से पूर्णांकों) और (दिनों की कीमत 30 वर्ष) स्थिर तिथियों की एक मेज।

Answer 6

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

फिर आम तौर पर सिस्टम में भूमिका निभाने वाली भूमिका सूचीबद्ध करने वाली तालिका होती है। एक जॉइन टेबल इंगित करता है कि कौन करने की अनुमति है। यह सेटअप आम तौर पर व्यवसाय डोमेन में एप्लिकेशन-विशिष्ट नियमों की चीजों के साथ अधिक जटिल हो जाता है।

एक ऑडिट तालिका एक बहुत अच्छा विचार है। मैं एक मानव-पठनीय कॉलम शामिल करता हूं ताकि गैर-तकनीकी लोगों को यह पता लगाने का मौका मिले कि क्या हो रहा है, साथ ही विभिन्न कुंजी और महत्वपूर्ण मूल्यों को संग्रहित करना भी है।

Answer 7

मुझे लगता है यह निम्नलिखित क्षेत्रों को शामिल करने के alway काम है:

• निष्क्रिय (या दर्शनीय/बंद/आदि)
• InactiveReason

बस यह वास्तव में 'नरम नष्ट' करने के लिए आसान बनाता है आइटम इसलिए डेटा अखंडता बनाए रखा जाता है और आप उस मूल्यवान ऐतिहासिक जानकारी को खोना नहीं चाहते हैं।

और गैलरी ने ऑडिट लॉग तालिका के लिए +1 का उल्लेख किया।

Answer 8

एक सदस्यता तालिका। अमूल्य।

Answer 9

कोई भी डेटा धारण करने वाला उपयोगकर्ता डेटा (आपके सिस्टम डेटा के विपरीत) की सृजन तिथि और अंतिम अपडेट की गई तारीख है। यदि कोई 1% मौका है तो आपको कुछ पता होना चाहिए कि कुछ कब हुआ। यह भविष्य में बहुत सारे सिरदर्द बचाएगा। जबकि मुझे ट्रिगर्स पसंद नहीं हैं, इन दोनों क्षेत्रों को बनाए रखने के लिए उनका उपयोग करना इसके लायक है। यदि आप वास्तविक डेटाबेस लॉग इन का उपयोग करते हैं, तो create_user और update_user भी उपयोगी हैं।