हम्म, मैं भी इसके बारे में सोच रहा था।
- प्रति टेबल-टू-कीप संशोधनों के लिए एक टेबल होना मेरे लिए व्यक्तिगत रूप से इतनी समस्या नहीं होगी, लेकिन हे।
- उपयोगकर्ता नाम उपयोगकर्ता-परिभाषित चरों के साथ रखा जा सकता है जो मुझे विश्वास है, (सत्र शुरू होने के बाद
SET @user='someone'जैसे कुछ जारी करें। , और उसका उपयोग करें। - जब तक INSERT, UPDATE और DELETE के बाद ट्रिगर होते हैं, पिछले / अगले मान प्राप्त करना एक साधारण क्वेरी है, मैं केवल पुराने मानों को संग्रहीत करूंगा।
संक्षेप में, कॉलम वाली तालिका के लिए (ए, बी, सी) मैं कॉलम के साथ एक टेबल बनाउंगा (user_id,modtime,a,b,c)।
प्रमुख कमियां:
- बैच अपडेट धीमे हैं (इसलिए संशोधनों को ध्यान से रखने के लिए अपनी तालिकाएं चुनें)
- डेटा डुप्लीकेशन डीलक्स, आपके पास / मेरे पास पर्याप्त संग्रहण स्थान होना चाहिए
- 'संबंधित' डेटा एक संशोधन को ट्रिगर नहीं करता है (यानी:
group_membersको बदलना तालिका वास्तव मेंgroupsको परिवर्तित नहीं करती है तालिका, जबकि आप इसेgroups. के लिए समय पर एक बिंदु के रूप में रखना चाह सकते हैं इसके बजायgroup_members. की छानबीन करें बदलाव.
कुल मिलाकर यह मेरे लिए एक अच्छा सौदा लगता है, लेकिन जैसा कि मैंने इसे शायद ही कभी व्यवहार में देखा हो जरूरी इसके खराब होने के लिए मजबूर करने वाले कारण हो सकते हैं, इसलिए मैं उन उत्तरों की प्रतीक्षा करूंगा।
