एकल टेबल w / अतिरिक्त कॉलम बनाम कई टेबल जो स्कीमा की नकल करते हैं

Question

मैं एक ऐसी परियोजना पर काम कर रहा हूं, जहां कुछ बिंदु पर, मुझे इस बात पर निर्णय लेने की आवश्यकता है कि क्या डेटाबेस में, मेरे पास एक एकल तालिका होनी चाहिए जिसमें कई स्तंभ हैं जो हर रिकॉर्ड का उपयोग नहीं करते हैं, या डुप्लिकेट स्कीमा के साथ कई तालिकाएं हैं।

मैं एक खेल सूचना एप्लिकेशन बना रहा हूं जो कई खेलों को संभाल सकता है। हम उदाहरण के लिए एनबीए, एनएचएल, एमएलबी, एनएफएल को संभाल सकते हैं। प्रत्येक खेल की अवधारणाएँ समान होती हैं - टीम, शेड्यूल, चोट, खिलाड़ी की जानकारी ..

हमारे डेटा स्रोत बेशक हमें एक ही स्कीमा में डेटा का प्रत्येक टुकड़ा नहीं देते हैं। प्रत्येक खेल का एक अलग स्कीमा होता है जिससे हम अपने विक्रेता से डेटा प्राप्त करते हैं।

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

परिणाम कई तालिकाओं में डुप्लिकेट स्कीमा है, और इसलिए डुप्लिकेट किए गए इंटरफेस को डेटाबेस (जैसे संग्रहीत प्रोक्स) के रूप में अच्छी तरह से। मेरे पास NBA_Game, NFL_Game, NBA_Team, NFL_Team, इत्यादि कुछ हैं। प्रत्येक तालिका में कुछ गुण हो सकते हैं जो अन्य नहीं है, और कई जो साझा किए गए हैं। यह 4 या 5 खेलों में 5-10 टेबल कहने के लिए जाता है। मुझे अभी भी यकीन नहीं है कि यह पूरी तरह से एक बुरी बात है - विकल्प, तालिकाओं का एक एकल सेट होने पर जो उस पर गुण थे जो कि सभी खेलों का उपयोग नहीं करेंगे, हो सकता है कि यह अपने आप में अनिर्दिष्ट हो।

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

क्या कुछ विकल्प जैसे टेबल इनहेरिटेंस है जो आपने अतीत में इस्तेमाल किया है जो बेहतर काम करता है?

धन्यवाद

Answer 1

अंततः, यह उपयोग और वास्तुकला के लिए नीचे आता है।

आर्किटेक्चर

क्या सिस्टम "किसी भी खेल" को संभालता है? क्या यह विचार है कि आप अपनी वास्तुकला अंतरिक्ष यात्री टोपी पर रखते हैं, और एक सामान्य प्रणाली का निर्माण करते हैं जो भविष्य के किसी भी प्रकार के खेल को संभाल सकता है जो आज भी मौजूद नहीं हो सकता है?

यदि हां, तो स्पष्ट रूप से गतिशील रूप से नामित तालिकाओं में बहुत बड़ा दर्द होता है, इसलिए यदि आवश्यक हो, तो यह एक स्कीमा है जो एन खेलों का समर्थन करता है।

उस ने कहा, मेरे पास इस दृष्टिकोण के खिलाफ एक बहुत मजबूत पूर्वाग्रह है: यह लगभग हमेशा अधिक काम होता है और खराब परिणामों की ओर जाता है। प्रत्येक खेल के लिए एक अलग यूआई, स्कीमा, आदि बनाने से अंततः बेहतर उपयोगकर्ता अनुभव और कोड को बनाए रखना आसान हो जाएगा, भले ही इसका मतलब कुछ सतही मात्रा में दोहराव हो (कैसे बचें / इसे कम करें यह एक अलग सवाल है)।

आप ऐसे खिलाड़ियों को कैसे संभालते हैं जो कई खेल खेलते हैं? क्या उन्हें दो प्रविष्टियाँ मिलती हैं (जैसे, आप विभिन्न लोगों के रूप में व्यवहार करते हैं) या आप उनके साथ कुछ विशिष्ट करने की कोशिश कर रहे हैं?

उपयोग

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

क्या कभी ऐसा समय होता है जहाँ आप एक समय में एक से अधिक खेलों से खिलाड़ियों (या आपके द्वारा उल्लिखित किसी अन्य वस्तु) को प्रदर्शित कर रहे हैं?

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

यदि आपको कभी ऐसा करने की आवश्यकता नहीं है, तो आपका दृष्टिकोण पूरी तरह से ठीक है। आप यहां पढ़ना बंद कर सकते हैं।

वैकल्पिक योजनाएँ

दृश्य

मैं KISS के एक प्रशंसक रहा हूँ। सॉफ्टवेयर विकास के 15+ वर्षों में, मैं "काम करने वाली सबसे सरल चीज़ का निर्माण" दर्शन पर वापस जाना जारी रखता हूं।

तो मेरी प्रारंभिक प्रतिक्रिया, एक क्रॉस-स्पोर्ट खोज फ़ंक्शन मानकर वास्तव में केवल उपयोग का मामला है, विचार बनाने के लिए है:

SELECT PlayerName, 'NFL' as [Sport], TeamName FROM NFL_Players JOIN NFL_Teams ... 
UNION  
SELECT PlayerName, 'NHL' as [Sport], TeamName FROM NHL_Players JOIN NHL_Teams ... 
UNION ....

बेशक, यदि आप एक नया खेल जोड़ते हैं, तो आपको दृश्य में जोड़ना होगा। यह अन्य सामान्य जानकारी को शामिल करने के लिए भी उपयोगी हो सकता है लेकिन वास्तव में यह निर्भर करता है कि क्या दिखाया जाना चाहिए।

इसलिए खोज कोड (के अलावा शायद कैसे लिंक करने के लिए जानते हुए भी ज्यादा या किसी विशिष्ट कोड की आवश्यकता नहीं है मैं, देखें परिभाषा में सभी खेल विशेष सामान रखने की कोशिश करता हूँ /nhl/players/player-nameबनाम /nfl/...या फिर भी अपने अनुप्रयोग है कि करता है)।

टेबल इनहेरिटेंस

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

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

खेल-विशिष्ट विशेषताओं के लिए अलग टेबल

आप एक एकल playersतालिका कर सकते हैं, जिसमें सभी खेलों के सभी खिलाड़ियों के लिए सामान्य गुण होते हैं, और फिर टेबल का एक और सेट जैसे nhl_players_detailsकि एक खिलाड़ी और अतिरिक्त जानकारी वाले स्तंभ खिलाड़ी पर होता है। यदि आम विशेषताओं का एक टन है, या आपके पास "सभी खेलों के सभी खिलाड़ियों" के कई उपयोग हैं तो यह समझ में आ सकता है।

खेल-विशिष्ट विशेषताओं के लिए मुख्य मूल्य जोड़े

पूरी तरह से वैकल्पिक दृष्टिकोण: एक है playersतालिका (फिर से, नाम की तरह आम विशेषताओं के साथ) और फिर एक player_dataहै कि मेज PlayerId, Sport, Attribute, Value। दर्ज किए गए विशेषता नाम खेल-विशिष्ट होंगे। यह आपको स्कीमा को संशोधित किए बिना अनिवार्य रूप से नई विशेषताओं को जोड़ने की अनुमति देता है (आपके कोड को अभी भी उन्हें लोड करने / प्रदर्शित करने के लिए जानना होगा)। दोष यह है कि आप कुछ अखंडता खो देते हैं: मूल्य आमतौर पर एक स्ट्रिंग फ़ील्ड होगा, इसलिए आपके ऐप कोड को लचीला होना होगा और स्ट्रिंग valueको एक विशिष्ट डेटा प्रकार (जैसे पूर्णांक) में परिवर्तित करने में संभावित विफलताओं को संभालना होगा ।

यह अवधारणा निश्चित रूप से टीमों, खेलों आदि पर लागू हो सकती है।

Comments

एक विरासत परियोजना के समाधान की खोज में कई प्रामाणिक प्रकार और टेबल होंगे, यहां उन विचारों का उल्लेख है, जिनके बारे में मैं भूल गया था, ने वास्तव में मेरे शोध के लिए एक और संभावित समाधान प्रदान करने में मदद की है। धन्यवाद।

— FullStackFool

Answer 2

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

सतह पर, आपके उदाहरण अवधारणा में समान (X_Game बनाम Y_Game और X_Team बनाम Y_Team) समान प्रतीत होते हैं कि कुछ स्तंभों का अतिरिक्त ओवरहेड अनुचित नहीं लगता है। अगर प्रत्येक खेल मेज पर कई दर्जन अतिरिक्त स्तंभ जोड़ने जा रहा है, तो यह वास्तव में बेमानी होगा।

उस मामले में, आप एक हाइब्रिड मॉडल पर विचार करना चाह सकते हैं, जहां सामान्य डेटा को केंद्रीय तालिका में रखा जाता है, लेकिन खेल-विशिष्ट डेटा को एक लिंक किए गए डेटा संरचना में रखा जाता है। कुछ इस तरह:

table Game {
    gameId int,
    teamId1 int fk,
    teamId2 int fk
}

table HockeyGame {
    gameId int fk,
    penaltyMinutes int
}

table BasketballGame {
    gameId int fk,
    freeThrows int
}

Comments

यह वह है जो मैं प्रस्तावित करने जा रहा था, साथ ही शायद खेल तालिका में एक स्तंभ खेल के प्रकार को दर्शाता है। मुझे पता है कि अन्य तालिकाओं में शामिल होने से इसका अनुमान लगाया जा सकता है, लेकिन अगर गेम के प्रकार की संख्या बढ़ती है, तो थकाऊ होना शुरू हो जाता है।

— रोरी हंटर

बिल्कुल - यह केवल एक कंकाल मॉडल है जो मुख्य रिश्तों और कुछ उदाहरणों के उदाहरण के लिए सामान्य डेटा बनाम खेल-विशिष्ट डेटा हो सकता है।

— मिडनियन