डेटाबेस में विरासत?

आप प्रबंधन स्टूडियो में टेम्पलेट फलक में एक टेम्पलेट बना सकते हैं। और उसके बाद हर बार जब आप एक नई टेबल बनाना चाहते हैं तो उस टेम्पलेट का उपयोग करें।

विफल होने पर, आप मूल तालिका और आईडी का संदर्भ देने वाली ऑडिट ट्रेल तालिका में बनाया गया और बनाया गया फ़ील्ड स्टोर कर सकते हैं।

यह विफल हो रहा है, इसे मैन्युअल रूप से करें।

हमारे पास एक एसपीआरसी है जो किसी दिए गए तालिका में ऑडिट कॉलम जोड़ती है, और (वैकल्पिक रूप से) किसी मान में परिवर्तनों को ट्रैक करने के लिए इतिहास तालिका और संबंधित ट्रिगर बनाता है। दुर्भाग्यवश, कंपनी नीति का अर्थ है कि मैं साझा नहीं कर सकता, लेकिन यह वास्तव में हासिल करना मुश्किल नहीं है।

एसक्यूएल सर्वर 2005 में टेबल के बीच विरासत जैसी कोई चीज नहीं है, और जैसा कि अन्य लोगों द्वारा नोट किया गया है, आप जब तक उन्हें बनाते हैं तो तालिका में आवश्यक कॉलम जोड़ने में सहायता प्राप्त कर सकते हैं, लेकिन यह आपके जैसा विरासत नहीं होगा पता है।

इसे अपने स्रोत कोड फ़ाइलों के लिए टेम्पलेट की तरह सोचें।

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

निचली पंक्ति: मैन्युअल काम।

PostgreSQL में यह सुविधा है। बस इसे अपनी तालिका परिभाषा के अंत में जोड़ें:

INHERITS FROM (tablename[, othertable...])

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

जहां तक ​​मुझे पता है, यह एक सुविधा का उपयोग अक्सर नहीं किया जाता है।

ओ-आर मानचित्रण में, विरासत मानचित्र एक अभिभावक तालिका में जहां माता-पिता और बाल सारणी एक ही पहचानकर्ता का उपयोग करती हैं

उदाहरण के लिए

create table Object (
    Id int NOT NULL --primary key, auto-increment
    Name varchar(32)
)
create table SubObject (
    Id int NOT NULL  --primary key and also foreign key to Object
    Description varchar(32)
)

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

यदि आप GUID का उपयोग कर रहे हैं तो आप कॉलम GUID, MadeOn, MadeBy के साथ CreateHistory तालिका बना सकते हैं। तालिका को पॉप्युलेट करने के लिए आपको अभी भी प्रत्येक तालिका के लिए एक ट्रिगर बनाना होगा या इसे एप्लिकेशन तर्क में संभालना होगा।

ऐसा करने के लिए आप विरासत का उपयोग नहीं करना चाहते हैं! जब तालिका बी, सी और डी तालिका ए से विरासत में आती है, तो इसका मतलब है कि पूछताछ तालिका ए आपको बी, सी और डी से रिकॉर्ड देगी। अब विचार करें ...

एक से हटा दें;

विरासत के बजाय, इसके बजाय LIKE का उपयोग करें ...

CREATE TABLE blah (
    blah_id     serial       PRIMARY KEY
    , something text         NOT NULL
    , LIKE template_table    INCLUDING DEFALUTS
);

आप डेटा मॉडलिंग टूल जैसे ईआर / स्टूडियो या ईआरविन का उपयोग कर सकते हैं। दोनों टूल्स में डोमेन कॉलम होते हैं जहां आप एक कॉलम टेम्पलेट को परिभाषित कर सकते हैं जिसे आप किसी भी टेबल पर लागू कर सकते हैं। जब डोमेन बदलता है तो संबंधित कॉलम करें। ईआर / स्टूडियो में टेम्पलेट ट्रिगर भी हैं जो आप किसी भी तालिका में बना सकते हैं और आवेदन कर सकते हैं। इस प्रकार हम सैकड़ों ट्रिगर स्क्रिप्ट बनाने और बनाए रखने के बिना हमारे LastUpdatedBy और LastUpdatedDate कॉलम को अपडेट करते हैं।

यदि आप ऑडिट तालिका बनाते हैं तो आपके पास ऑडिट तालिका का उपयोग करने वाली प्रत्येक तालिका में प्रत्येक पंक्ति के लिए एक पंक्ति होगी। वह गन्दा हो सकता है। मेरी राय में, आप प्रत्येक तालिका में ऑडिट कॉलम डालने से बेहतर हैं। आप अपनी सभी टेबलों में टाइमस्टैम्प कॉलम भी डाल सकते हैं। आप कभी नहीं जानते कि सहमति कब एक समस्या बन जाती है। हमारे डीबी ऑडिट कॉलम जिन्हें हम प्रत्येक तालिका में डालते हैं: MadeDt, LastUpdatedBy, LastUpdatedDt और Timestamp हैं।

उम्मीद है की यह मदद करेगा।

रमेश - मैं अपने ई-आर मॉडल में सुपरटेप और उप प्रकार के रिश्तों का उपयोग करके इसे लागू कर दूंगा। आपके संबंधों को लागू करने के कुछ अलग-अलग भौतिक विकल्प भी हैं।