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