सवाल आपके कुछ सबसे उपयोगी डेटाबेस मानकों में से कुछ क्या हैं?


मेरे पास कुछ विचार हैं, कुछ जो मैंने समय के साथ जमा किया है, लेकिन मैं वास्तव में जानना चाहता हूं कि मॉडलिंग डेटाबेस के दौरान चीजें आपके लिए आसानी से कैसे चलती हैं:

  1. तालिका का नाम प्राथमिक कुंजी नाम और विवरण कुंजी से मेल खाता है
  2. Schemas कार्यात्मक क्षेत्र द्वारा हैं
  3. जहां संभव हो समग्र समग्र कुंजी से बचें (अद्वितीय बाधाओं का उपयोग करें)
  4. ऊंट केस टेबल नाम और फ़ील्ड नाम
  5. Tbl_ के साथ तालिकाओं को उपसर्ग न करें, या SP_ के साथ procs (कोई हंगेरी नोटेशन नहीं)
  6. OLTP डेटाबेस बीसीएनएफ / 4 एनएफ में कम से कम होना चाहिए

44


मूल


"जहां संभव हो सके समग्र प्राथमिक कुंजी से बचें" - उनसे बचने के लिए आप कितनी लंबाई तक जाएंगे? मैं, ज्यादा नहीं। इसके अलावा "अद्वितीय इंडेक्स का उपयोग करें" - क्या आपका मतलब "अद्वितीय बाधाएं" (संकेत: सभी एसक्यूएल उत्पाद इंडेक्स का उपयोग नहीं करते हैं) या क्या आपके पास विशेष उत्पाद दिमाग में हैं? - onedaywhen
चूंकि लोग मेरे जवाब को कम कर रहे हैं, इसलिए मैं जल्द ही इसे हटा दूंगा, मैं इसे टिप्पणी में डाल दूंगा। सामान्यीकरण आप सर्वोत्तम मानकों में से एक है जिसे आप अपना सकते हैं। - Lance Roberts
@ तापाई: नंबर 5 क्यों नहीं करते? मैं यह नहीं कह रहा कि यह गलत है, मैं बस जानना चाहता हूं जैसे ही हम इसे हमारी कंपनी में करते हैं छुपाते हैं - Kezzer
मेरे अनुभव में, नियमित रूप से समग्र प्राथमिक कुंजी का उपयोग करके आपको ऐसी स्थिति में ले जाता है जहां आप दो टेबल के बीच 8-कुंजी जुड़ने के साथ चार स्तर गहरे होते हैं। ऐसी तालिकाओं के खिलाफ एसक्यूएल लिखना कठिन है जब तक आप कोड जनरेटर का उपयोग नहीं करते। मैं अद्वितीय बाधाओं का उपयोग करने का सुझाव देता हूं। - Raj More
मानकों के बारे में सबसे अच्छी बात यह है कि चुनने के लिए बहुत सारे लोग हैं! - araqnid


जवाब:


  • उसी उपसर्ग के साथ समान रूप से लक्षित संग्रहित प्रोसेस का नाम दें, उदाहरण के लिए यदि आपके पास व्यक्ति के लिए 3 संग्रहीत प्रक्रियाएं हैं। इस तरह व्यक्ति के लिए सबकुछ एक ही स्थान पर समूहीकृत किया जाता है और आप उन्हें ढूंढने के लिए अपनी सभी प्रोसेस को देखे बिना आसानी से पा सकते हैं।
    • PersonUpdate
    • PersonDelete
    • PersonCreate
  • टेबल के लिए समान चीजें करें जब आपके पास संबंधित डेटा वाले तालिकाओं के समूह हों। उदाहरण के लिए:
    • InvoiceHeaders
    • InvoiceLines
    • InvoiceLineDetails
  • यदि आपके पास अपने डेटाबेस में स्कीमा का विकल्प है, तो उनका उपयोग करें। यह देखने के लिए बहुत अच्छा है:
    • Invoice.Header
    • Invoice.Line.Items
    • Invoice.Line.Item.Details
    • Person.Update
    • Person.Delete
    • Person.Create
  • ट्रिगर्स का उपयोग न करें जब तक कि उस लक्ष्य को प्राप्त करने के लिए कोई अन्य उचित दृष्टिकोण न हो।
  • फ़ील्ड नामों को एक सार्थक उपसर्ग दें ताकि आप बता सकें कि किसी भी व्यक्ति को समझाने की आवश्यकता के बिना वे कौन सी तालिका आती हैं। इस तरह जब आप संदर्भित फ़ील्ड नाम देखते हैं, तो आप आसानी से बता सकते हैं कि यह किस तालिका से है।
  • समान डेटा वाले फ़ील्ड के लिए लगातार डेटा प्रकारों का उपयोग करें, यानी फ़ोन नंबर को एक तालिका में संख्यात्मक और दूसरे में वर्चर के रूप में स्टोर न करें। असल में, इसे संख्यात्मक के रूप में स्टोर न करें, अगर मैं एक नकारात्मक फोन नंबर पर आउंगा तो मैं पागल हो जाऊंगा।
  • तालिका / फ़ील्ड नामों में रिक्त स्थान या अन्य अस्पष्ट वर्णों का उपयोग न करें। वे पूरी तरह से अल्फान्यूमेरिक होना चाहिए - या अगर मेरे अंडरस्कोर के अपवाद के साथ पूरी तरह से वर्णमाला है। मैं वर्तमान में विरासत प्रणाली पर काम कर रहा हूं जहां टेबल और फ़ील्ड नामों में रिक्त स्थान, प्रश्न चिह्न और विस्मयादिबोधक चिह्न होते हैं। मुझे रोज़ाना डिजाइनर को मारना चाहता है!
  • सिंटैक्स कीवर्ड का उपयोग ऑब्जेक्ट नामों के रूप में न करें, इससे सिरदर्द उनसे डेटा पुनर्प्राप्त करने का प्रयास कर देगा। मुझे ऑब्जेक्ट नामों को [इंडेक्स] के रूप में लपेटने से नफरत है, जो दो अनावश्यक वर्ण हैं जिन्हें मुझे आपको टाइप करने की आवश्यकता नहीं है!

19



@balabaster: मैं यह भी करता हूँ। चीजों को अच्छी तरह संगठित रखने में मदद करता है। अधिकांशतः, आपके पास एकाधिक खोज हैं PersonGetByPersonId, PersonGetByName, PersonGetByOderId, PersonGetByCity .. इकाई नाम के साथ उपसर्ग कोड इसे बहुत तंग रखता है। - Raj More
@balabaster: टेबल और कॉलम नामों में प्रश्न चिह्न और विस्मयादिबोधक चिह्न? मैंने उम्र में नहीं देखा है। मैं तुम्हारे लिए महसूस करता हूँ, दोस्त! - Raj More
@ टापोरी: हाँ, यह मुझे कुछ लोगों के बारे में आश्चर्यचकित करता है, लॉल - BenAlabaster
+1 100 usp_Insert देखने के लिए डेटाबेस खोलने की तरह कुछ नहीं ... sprocs - blu
ट्रिगर्स पर नकारात्मक टिप्पणी क्यों ?? - leora


एक बात मैंने अभी तक नहीं देखी है:

ऑब्जेक्ट नामों के रूप में डेटाबेस कीवर्ड का कभी भी उपयोग न करें। हर बार जब आप उनका इस्तेमाल करते हैं तो आप उन्हें अर्हता प्राप्त नहीं करना चाहते हैं

यदि आप इसे बनाते समय कुछ गलत वर्तनी करते हैं, तो जैसे ही आप इसे देखते हैं इसे ठीक करें। याद रखने के वर्षों को खर्च न करें कि इस तालिका में उपयोगकर्ता नाम वास्तव में Usernmae है। यह ठीक करने के लिए बहुत आसान है जब इसके खिलाफ बहुत अधिक कोड लिखा नहीं गया है।

कभी भी अंतर्निहित जॉइन (कॉमा सिंटैक्स) का उपयोग न करें, हमेशा जुड़ें निर्दिष्ट करें।


13



हमारी स्कीमा में शाखाओं। बर्नचिड की तरह ... मैं पहले से ही इसका उपयोग कर चुका हूं लेकिन शुरुआत में मुझे सिरदर्द का कारण बन गया। स्कीमा का उपयोग दो अलग-अलग उत्पादों द्वारा किया जाता है, इसलिए इसे नामकरण करना वास्तव में एक विकल्प नहीं था। लेकिन मैं तुमसे सहमत हूँ। जितनी जल्दी हो सके फिक्स मिस्सेलिंग! - Peter Perháč
मुझे लगता है कि हमारे पास अभी भी हमारी तालिका में से एक में "care_hire_driver_id" प्राथमिक कुंजी है ... कई सालों बाद: ओ - araqnid
निहित जॉइन के लिए +1, मैं इस तरह के प्रश्नों को ठीक करने से थक गया हूं। - SqlACID
ईमानदारी से मुझे लगता है कि "अंतर्निहित शामिल" बहुत आसान और उपयोग करने में आसान है। आप तुरंत देख सकते हैं कि आप कौन सी टेबल चुन रहे हैं क्योंकि वे एक दूसरे के बगल में सूचीबद्ध हैं उदा। "तालिका 1 से, तालिका 2"। जब तक आप पहली बार शामिल फ़ील्ड निर्दिष्ट करते हैं, जहां खंड में कोई समस्या नहीं है, उदा। "जहां table1.id = table2.table1id और ..." - DisgruntledGoat
ओह और भूलें, तालिका / फ़ील्ड नाम जो आपके नामकरण प्रणाली से विचलित हो जाते हैं - उदाहरण के लिए "उपयोगकर्ता" तालिका के लिए बहुवचन लेकिन "संदेश" तालिका के लिए एकवचन - गलत वर्तनी के रूप में गिनती भी, और ASAP को ठीक किया जाना चाहिए। - DisgruntledGoat


सभी की एक सूची को एक सूची में एक साथ रखना।

नामकरण मानकों

  • स्कीमा का नाम कार्यात्मक क्षेत्र (उत्पाद, आदेश, शिपिंग) द्वारा किया जाता है
  • कोई हंगेरियन नोटेशन: ऑब्जेक्ट नामों में कोई प्रकार का नाम नहीं (कोई strFirstName नहीं)
  • ऑब्जेक्ट नामों के लिए पंजीकृत कीवर्ड का उपयोग न करें
  • ऑब्जेक्ट नामों में कोई रिक्त स्थान या कोई विशेष वर्ण नहीं है (Alphanumber + Underscore केवल एकमात्र चीजें हैं)
  • वस्तुओं को प्राकृतिक तरीके से नाम दें (नाम फर्स्ट के बजाय फर्स्टनाम)
  • तालिका का नाम प्राथमिक कुंजी नाम और विवरण फ़ील्ड से मेल खाना चाहिए (सेल्सटाइप - सेल्सटाइप आईडी, सेल्सटाइप डिस्क्रिप्शन)
  • Tbl_ या sp_ के साथ उपसर्ग न करें
  • ऑब्जेक्ट नाम से नाम कोड (ग्राहक खोज, ग्राहक गेटबैलेंस)
  • CamelCase डेटाबेस ऑब्जेक्ट नाम
  • कॉलम नाम एकवचन होना चाहिए
  • तालिका के नाम बहुवचन हो सकते हैं
  • सभी बाधाओं के लिए व्यवसाय नाम दें (MustEnterFirstName)

जानकारी का प्रकार

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

कोड में

  • हमेशा अपरकेस में कीवर्ड
  • कभी भी अंतर्निहित जॉइन (कॉमा सिंटैक्स) का उपयोग न करें - हमेशा स्पष्ट INNER जॉइन / बाहरी जॉइन का उपयोग करें
  • प्रति पंक्ति एक जॉइन
  • प्रति पंक्ति एक कहां खंड
  • कोई लूप नहीं - सेट आधारित तर्क के साथ प्रतिस्थापित करें
  • ए, बी, सी के बजाय उपनामों के लिए तालिका नामों के छोटे रूपों का उपयोग करें
  • ट्रिगर्स से बचें जब तक कोई सहारा नहीं है
  • प्लेग जैसे कर्सर से बचें (पढ़ें http://www.sqlservercentral.com/articles/T-SQL/66097/)

प्रलेखन

  • डेटाबेस आरेख बनाएँ
  • एक डेटा शब्दकोश बनाएँ

सामान्यीकरण और संदर्भित ईमानदारी

  • जितना संभव हो सके एकल कॉलम प्राथमिक कुंजी का प्रयोग करें। जहां आवश्यक हो वहां अद्वितीय बाधाओं का प्रयोग करें।
  • संदर्भित अखंडता हमेशा लागू की जाएगी
  • हटाए गए कैस्केड से बचें
  • OLTP कम से कम 4 एनएफ होना चाहिए
  • संभावित रूप से कई से अधिक रिश्तों के रूप में हर एक से कई रिश्तों का मूल्यांकन करें
  • गैर उपयोगकर्ता उत्पन्न प्राथमिक कुंजी
  • अद्यतन आधारित के बजाय सम्मिलित आधारित मॉडल बनाएं
  • पीके से एफके एक ही नाम होना चाहिए (कर्मचारी। कर्मचारी Id कर्मचारी Salary.EmployeeId के समान क्षेत्र है)
  • छोड़ने के अलावा जब कोई डबल जॉइन होता है (व्यक्ति। PersonId PersonRelation.PersonId_Parent और PersonRelation.PersonId_Child में शामिल हो जाता है)

रखरखाव: खोजने के लिए आवधिक स्क्रिप्ट चलाएं

  • टेबल के बिना स्कीमा
  • अनाथ रिकॉर्ड
  • प्राथमिक कुंजी के बिना टेबल्स
  • इंडेक्स के बिना टेबल्स
  • गैर निर्धारिती यूडीएफ
  • बैकअप, बैकअप, बैकअप

अच्छा बनो

  • निरतंरता बनाए रखें
  • त्रुटियों को ठीक करें अभी व
  • जो सेल्को की एसक्यूएल प्रोग्रामिंग स्टाइल पढ़ें (आईएसबीएन 978-0120887972)

11





ओरेकल के लिए मेरे मानकों हैं:

  • कीवर्ड हमेशा अपरकेस में होते हैं;
  • डेटाबेस ऑब्जेक्ट नाम हमेशा लोअरकेस में होते हैं;
  • अंडरस्कोर रिक्त स्थान को प्रतिस्थापित करेगा (यानी कोई ऊंट केस सम्मेलन नहीं होगा जो सामान्य हैं, कहें, SQL सर्वर);
  • प्राथमिक कुंजी को हमेशा 'id' नाम दिया जाएगा;
  • संदर्भित अखंडता लागू की जाएगी;
  • इंटीजर मान (तालिका आईडी सहित) आमतौर पर हमेशा NUMBER (1 9 0) होंगे। इसका कारण यह है कि यह 64-बिट हस्ताक्षरित पूर्णांक में फिट होगा जिससे इस प्रकार जावा लम्बी प्रकार को अधिक अजीब बिगइंटर के बजाय उपयोग किया जा सकेगा;
  • कुछ कॉलम नामों में "_number" जोड़ने के गलत नाम के बावजूद, ऐसे कॉलम का प्रकार VARCHAR2 एक प्रकार का नहीं होगा। संख्या कुंजी प्राथमिक कुंजी और कॉलम के लिए आरक्षित हैं जो आप अंकगणित करते हैं;
  • मैं हमेशा तकनीकी प्राथमिक कुंजी का उपयोग करता हूं; तथा
  • प्रत्येक तालिका में मुख्य पीढ़ी के लिए अपना अनुक्रम होगा। उस अनुक्रम का नाम _seq होगा।

SQL सर्वर के साथ, डेटाबेस ऑब्जेक्ट नामों (यानी party_name के बजाय PartyName) के लिए ऊंट केस का उपयोग करने का एकमात्र संशोधन है।

प्रति पंक्ति एक खंड या शर्त के साथ क्वेरीज़ बहु-पंक्ति लिखी जाएगी:

SELECT field1, field2, field2
FROM tablename t1
JOIN tablename2 t2 ON t1.id = t2.tablename_id
WHERE t1.field1 = 'blah'
AND t2.field2 = 'foo'

यदि चयन खंड पर्याप्त रूप से लंबा है तो मैं इसे प्रति पंक्ति एक फ़ील्ड में विभाजित कर दूंगा।


10



ओरेकल के साथ लगभग विशेष रूप से काम करना, मुझे हर बिंदु पर आपसे सहमत होना चाहिए। हालांकि, मुझे बहुत सारे अंडरस्कोर टाइप करने के विपरीत कैमेलकेस का अधिक उंगली-अनुकूल उपयोग मिलता है। हमारे पास एक थर्ड-पार्टी सिस्टम है जिसमें इसकी स्कीमा में लगभग 200 टेबल हैं और उन्होंने अंडरस्कोर का उपयोग न करने का फैसला किया है। जैसे PROJECT_TASK_TYPE के बजाय PROJECTTASKTYPE, और हालांकि इसे पढ़ने में कुछ मुश्किल है, मुझे टाइपिंग प्रश्नों को स्वीकार करना इतना आसान है। - Peter Perháč
हम SQL सर्वर के लिए भी "old_school_names" का उपयोग करते हैं। इसके अलावा, हमारा मुख्य अंतर यह होगा कि मैं "आईडी" की बजाय प्राथमिक कुंजी-अनावश्यक के रूप में "tablename_id" का उपयोग करना पसंद करता हूं, लेकिन समय-समय पर उपयोगी होता हूं; इसका मतलब यह भी है कि अधिकांश समय, तालिका ए और तालिका बी के बीच का लिंक समान नामित कॉलम पर बनाया जाता है, उदा। purchase.purchase_type_id = purchase_type.purchase_type_id। हम यह भी निर्दिष्ट करते हैं कि तालिका के नाम एकवचन होना चाहिए, बहुवचन नहीं ("खरीद", "खरीद नहीं")। - araqnid
मेरे वास्तुकार का कहना है कि वह उन टेबल में शामिल होने के लिए अंडरस्कोर का उपयोग करना चाहता है जहां नाम स्पष्ट नहीं है। उदाहरण के लिए, यदि ग्राहक और उत्पाद ऑर्डर आईडी के पीके के साथ आदेश में शामिल हो जाते हैं, तो हम सेट हैं! लेकिन अगर उत्पाद और श्रेणी में शामिल हों, और इसमें शामिल होने के लिए कोई व्यावसायिक नाम नहीं है, तो हमें Product_Category_Id के साथ Product_Category मिलती है। (एस क्यू एल सर्वर) - Raj More


  • सभी बाधाओं का नाम दें

9



मुझे बाधाओं को सार्थक नाम देने का विचार पसंद है। - Raj More


नियमित रूप से अपने डेटाबेस का बैक अप लेने के लिए मत भूलना।


8



मैं इसे एक कदम आगे ले जाऊंगा। प्रतिदिन बैकअप, साप्ताहिक बहाल करें। हमेशा दोबारा जांचें कि आप वास्तव में बैकअप को पुनर्स्थापित कर सकते हैं अन्यथा आपको मुश्किल समय पर पता चल जाएगा कि आपके बैकअप पर्याप्त नहीं हैं। - Raj More


  1. फ़ील्ड नामों में टाइप नामों का उपयोग न करें। पुराने लोग lpszFieldName के पुराने एमएस मानक और उस मूर्खता को याद करेंगे।

  2. वर्णनात्मक फ़ील्ड नामों का प्रयोग करें जो सामान्य भाषा सम्मेलनों का पालन करते हैं। उदाहरण के लिए "NameFirst" के बजाय "फर्स्टनाम"

  3. क्षेत्र के नाम में प्रत्येक शब्द पूंजीकृत है

  4. कोई अंडरस्कोर नहीं

  5. "इंडेक्स" जैसे सामान्य कीवर्ड का उपयोग न करें

  6. ऑब्जेक्ट प्रकार के साथ कुछ भी उपसर्ग न करें। उदाहरण के लिए हम tblCustomers या spCustomersGet का उपयोग नहीं करते हैं। ये अच्छे सॉर्टिंग की अनुमति नहीं देते हैं और शून्य मान प्रदान करते हैं।

  7. डेटाबेस के अलग-अलग क्षेत्रों को परिभाषित करने के लिए स्कीमा का उपयोग करें। जैसे बिक्री। ग्राहक और घंटा कर्मचारी। यह लोगों द्वारा उपयोग किए जाने वाले अधिकांश उपसर्गों से छुटकारा पा जाएगा।

  8. किसी भी प्रकार के लूप्स को संदेह के साथ देखा जाना चाहिए। आमतौर पर एक बेहतर सेट आधारित तरीका है।

  9. जटिल जोड़ों के लिए विचारों का प्रयोग करें।

  10. जब संभव हो तो जटिल जुड़ाव से बचें। ग्राहकफ़ोन नंबर्स तालिका रखने के लिए यह अधिक अस्थिरता हो सकती है; लेकिन ईमानदारी से, हमें वास्तव में कितने फोन नंबर स्टोर करने की ज़रूरत है? बस फ़ील्ड को ग्राहक तालिका में जोड़ें। आपके डीबी प्रश्न तेजी से होंगे और यह समझना बहुत आसान है।

  11. यदि एक तालिका "कर्मचारी आईडी" फ़ील्ड कहती है तो प्रत्येक सिंगल टेबल जो संदर्भ देता है उसे उस नाम का उपयोग करना चाहिए। इसे केवल ग्राहक सेवा RepId कहा जाने की आवश्यकता नहीं है क्योंकि यह एक एक्सटेंशन तालिका में है।

  12. लगभग सभी तालिकाओं में "एस" समाप्त होता है। उदाहरण के लिए: ग्राहक, आदेश, आदि। सभी तालिकाओं के बाद कई रिकॉर्ड हैं ...

  13. एक विश्लेषण उपकरण के साथ अपने प्रश्न, अनुक्रमणिका और विदेशी कुंजी संबंधों का मूल्यांकन करें। यहां तक ​​कि जो आपके लिए उत्पन्न हो सकते हैं। आप आश्चर्यचकित हो सकते हैं।

  14. कई संबंधों में कई लोगों का समर्थन करने वाली तालिकाओं को जोड़ने से दोनों नामों से तालिकाओं को जोड़ दिया जाता है। उदाहरण के लिए, स्कूलग्रेड्स। टेबल नाम से यह कहना बहुत आसान है कि यह क्या करता है।

  15. निरतंरता बनाए रखें। यदि आप अपने सम्मेलनों के साथ एक रास्ता शुरू करते हैं, तो घोड़ों को आधे रास्ते में न बदलें जब तक कि आप पिछले सभी कार्यों को दोबारा तैयार करने के इच्छुक नहीं हैं। इस पर ब्रेक को किसी भी "अगर यह अच्छा नहीं होगा .." विचारों को भ्रम और बड़ी मात्रा में पुनर्विक्रय के कारण समाप्त करना चाहिए।

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


7



# 10 के साथ असहमत असहमत, यह ज्यादातर समय एक बहुत ही खराब प्रथा है, आपको एक नया फोन प्रकार जोड़ने के लिए टेबल संरचना बदलनी है। आपको आश्चर्य होगा कि कुछ लोगों के लिए आपको कितने फोन नंबर स्टोर करना होगा। मैं दृढ़ता से # 8 के साथ सहमत हूं। - HLGEM
# 10 के लिए +1। आप अतिसंवेदनशीलता की लागत को अतिरंजित नहीं कर सकते हैं। - Andomar
@ जो, मैं कुछ सार्थक जानकारी के साथ उपसर्ग करना होगा। आईई, जिम्मेदार कर्मचारी, या सहायकEmployeeId - Nathan Koop
@ टापोरी, मैं मानता हूं कि # 10 शायद सिस्टम आवश्यकताओं पर कुछ हद तक निर्भर करता है। हालांकि, मुझे नहीं लगता कि आपके उदाहरण अच्छे हैं। कॉल इतिहास के लिए, इतिहास तालिका में वास्तविक फोन नंबर को पते के बारे में ही रखना बेहतर होगा। यह ऑर्डर टेबल में होना चाहिए। इसका कारण यह है कि यह आपके इतिहास को बरकरार रखता है भले ही कोई आपके "फोन" या "पते" तालिका से रिकॉर्ड हटा देता है। डुप्लिकेट डेटा? संभवतः, लेकिन आपके डेटा पर रिपोर्ट करना बहुत आसान है और उन क्षेत्रों में डेटा कभी नहीं बदला जाना चाहिए। - NotMe
संपर्क: फोन नंबर को वास्तविक कॉल इतिहास के समान रिकॉर्ड में रखते हुए, फिर आपकी यूआई / डेटा परत हानिकारक इतिहास के संबंध में मुख्य ग्राहक खाते के साथ फोन नंबर प्रबंधित कर सकती है। पते और आदेश के साथ ही वही। - NotMe