जब दो टेबल बहुत समान होते हैं, तो उन्हें कब जोड़ा जाना चाहिए?

Question

मेरे पास घटनाएं और तस्वीरें हैं, और फिर दोनों के लिए टिप्पणियां हैं। अभी, मेरे पास दो टिप्पणियां सारणी हैं, एक घटनाओं से संबंधित टिप्पणियों के लिए, और फोटो टिप्पणियों के लिए दूसरा। स्कीमा इस के समान है:

CREATE TABLE EventComments 
(
    CommentId int, 
    EventId int, 
    Comment NVarChar(250), 
    DateSubmitted datetime 
) 

CREATE TABLE PhotoComments 
(
    CommentId int, 
    PhotoId int, 
    Comment NVarChar(250), 
    DateSubmitted datetime 
) 

मेरे सवालों का है या नहीं, मैं उन्हें गठबंधन करना चाहिए, और एक अलग पार संदर्भ तालिका जोड़ने के लिए, लेकिन मैं इसे ठीक से करने के लिए एक तरह से सोच भी नहीं सकते है। मुझे लगता है कि यह ठीक होना चाहिए, आपके विचार क्या हैं?

संपादित

वाल्टर के जवाब (और कुछ प्रकाश पढ़ने) के आधार पर, मैं इस के साथ आ गया है:

CREATE TABLE Comments 
(
    CommentId int, 
    Comment NVarChar(250), 
    DateSubmitted datetime 
    CONTRAINT [PK_Comments] PRIMARY KEY 
    (
    CommentId 
) 
) 

CREATE TABLE EventComments 
(
    CommentId int, 
    EventId int 
) 

CREAT TABLE PhotoComments 
(
    CommentId int, 
    PhotoId int 
) 

ALTER TABLE EventComments ADD CONSTRAINT FK_EventComments FOREIGN KEY (CommentId) REFERENCES Comments(CommentId) 

ALTER TABLE PhotoComments ADD CONSTRAINT FK_PhotoComments FOREIGN KEY (CommentId) REFERENCES Comments(CommentId) 

वहाँ वास्तव में संरचनाओं के बीच किसी भी प्रदर्शन अंतर है? मेरे लिए, यह थोड़ा वरीयता की तरह लगता है। मुझे दूसरी स्कीमा में लाभ दिखाई देते हैं, अगर मैं ईवेंट टिप्पणियों या फोटो टिप्पणियों में कुछ विशिष्टता जोड़ना चाहता हूं, तो मेरे पास ऐसा करने के लिए एक अलग टेबल है, और यदि मैं दोनों को एक नई संपत्ति साझा करना चाहता हूं, तो एक ही टेबल है नई संपत्ति जोड़ें।

Answer 1

टिप्पणियां, फोटोकॉममेंट्स और इवेंट कॉमेंट्स "सामान्यीकरण विशेषज्ञता" नामक पैटर्न में संबंधित हैं। यह पैटर्न वस्तु उन्मुख भाषाओं में सरल विरासत द्वारा संभाला जाता है। यह टेबल की एक स्कीमा सेट अप करने के लिए थोड़ा और जटिल है जो समान पैटर्न को कैप्चर करेगा।

लेकिन यह अच्छी तरह से समझा जाता है। "सामान्यीकरण विशेषज्ञता संबंधपरक मॉडलिंग" पर एक त्वरित Google खोज आपको इस विषय पर कई अच्छे लेख देगी।

Answer 2

आप उन्हें जोड़ सकते हैं और एक फ़ील्ड जोड़ सकते हैं जो इंगित करता है कि यह एक फोटो या किसी ईवेंट के लिए है या नहीं।

आपको दो विदेशी कुंजी की आवश्यकता होगी; एक तस्वीरों के लिए और घटनाओं के लिए एक, लेकिन उन्हें एक टेबल में रखने से आप सभी टिप्पणियों को संभालने के लिए कोड का एक सेट लिख सकते हैं।

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

Answer 3

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

Answer 4

यदि आप उन्हें जोड़ते हैं तो यह महत्वपूर्ण संरचना को गड़बड़ कर रहा है। आपको शून्य और सक्षम विदेशी कुंजी या कुंजी और प्रकार की "मुलायम" कुंजी संरचना होनी होगी। मैं उन्हें अलग रखूंगा।