पृष्ठभूमि
मैं कई बड़ी रिपोर्टें लिखता हूं और आम तौर पर एक बड़े स्वास्थ्य रिकॉर्ड डीबी (एसपी, फ़ंक्शन, नौकरियां, आदि लिखता हूं) को बनाए रखता हूं। मूल स्कीमा, और इसका उपयोग करने वाला सॉफ्टवेयर एक अलग विक्रेता से है, इसलिए मैं इसके बारे में संरचनात्मक रूप से बहुत कुछ नहीं बदल सकता। ऐसे कई रिकॉर्ड हैं जिन्हें लैब, प्रक्रिया, टीके, आदि जैसे ट्रैकिंग की आवश्यकता होती है और वे दर्जनों तालिकाओं में बिखर जाते हैं, जिनमें से कई फूला हुआ है और खराब रूप से अनुक्रमित है (मैं इसे कुछ हद तक ठीक करने में सक्षम हूं)।
समस्या
मुद्दा यह है कि क्योंकि हमारे पास DB पर थोड़ा नियंत्रण है, और चूंकि यह किसी भी अपडेट या पैच से बदल सकता है, यह इन रिपोर्टों को लिखना और बनाए रखना कठिन और थकाऊ है - खासकर जब ओवरलैप की एक बड़ी मात्रा होती है। यह सब एक पैच है और मैं एक दर्जन रिपोर्टों के बड़े हिस्से को फिर से लिख रहा हूं। इसके अतिरिक्त, प्रश्न जल्दी से मोटे और धीमे हो जाते हैं जैसे कि जोड़, नेस्टेड चयन, और ढेर को लागू करता है।
मेरा "समाधान"
मेरी योजना इन सभी रिकॉर्डों को एक "कैच-ऑल" तालिका में लिखने की थी, और इस समग्र तालिका में रिकॉर्ड बनाए रखने के लिए मूल तालिकाओं पर ट्रिगर लिखें। बेशक मुझे यह सुनिश्चित करना होगा कि अपडेट के बाद मेरे ट्रिगर्स बरकरार रहे, लेकिन यह एक स्थिरता के दृष्टिकोण से बहुत आसान होगा, और सिर्फ डेटा को संदर्भित करना होगा।
तालिका पतली और लंबी होगी, केवल आवश्यक डेटा संग्रहीत करते हुए, कुछ इस तरह से:
CREATE TABLE dbo.HCM_Event_Log (
id INT IDENTITY,
type_id INT NULL,
orig_id VARCHAR(36) NULL,
patient_id UNIQUEIDENTIFIER NOT NULL,
visit_id UNIQUEIDENTIFIER NULL,
lookup_id VARCHAR(50) NULL,
status VARCHAR(15) NULL,
ordered_datetime DATETIME NULL,
completed_datetime DATETIME NULL,
CONSTRAINT PK_HCM_Event_Log PRIMARY KEY CLUSTERED (id)
)तब मैं type_id और आइटम समूह जैसी चीज़ों के लिए विभिन्न संबंधपरक तालिकाएँ रखूँगा।
मैं इस विचार को दूसरी बार शुरू कर रहा हूं क्योंकि इनमें से कई तालिकाओं को काफी कुछ लिखा गया है, जो एसपी और रिपोर्ट मैं लिख रहा हूं वह डेटा को भी संदर्भित करेगा। इसलिए मुझे इस बात की चिंता है कि यह तालिका एक रिकॉर्ड लॉकिंग और प्रदर्शन के साथ बहुत अधिक आई / ओ होगी।
मेरा प्रश्न
एक बुरा या एक अच्छा विचार है? मुझे एहसास है कि हर स्थिति SQL सर्वर (2008 r2 मानक संस्करण BTW), और "कभी-कभी" नियम में भिन्न होती है, लेकिन मैं वास्तव में सामान्य सलाह की तलाश में हूं।
मैंने एक सेवा दलाल का उपयोग करने पर विचार करना शुरू किया, लेकिन मैं केवल सरल अपडेट / आवेषण प्रदर्शन करूंगा ( स्वीकृत उत्तर का विकल्प देखें )। कई मामलों में डेटा को वास्तविक समय की आवश्यकता होती है, इसलिए बैकअप DB का उपयोग करना वास्तव में काम नहीं करेगा। प्रदर्शन हमारे लिए पहले से ही एक मुद्दा है, लेकिन इसमें से अधिकांश हार्डवेयर से संबंधित है जो जल्द ही हल हो जाएगा।