बुलेटिन बोर्ड - डेटाबेस अनुकूलन

भाग I

संशोधित 09 दिसंबर 10 01:00 EST

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

• ऐसा करने का तरीका है, निम्नलिखित प्रश्नों के उत्तर दें (संक्षिप्त उत्तर ठीक हैं)। ये प्रश्न संस्थाओं और व्यावसायिक नियमों को स्पष्ट कर रहे हैं . आप सामान्य रूप से डेटाबेस को कैसे समझते हैं, और विशेष रूप से आपका डेटा महत्वपूर्ण है। आप अपने दम पर एक लंबा सफर तय कर चुके हैं, इसलिए हम इसे वहां से ले जा सकते हैं।

• मुझे लगता है कि ▶यह पोस्ट◀ मजबूत> औपचारिक चरणों को समझने के लिए जिनका पालन किया जाना चाहिए, आपके लिए सहायक हो सकता है; जिसे हम यहां शॉर्ट-सर्किट कर रहे हैं।

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

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

सुंदर चित्रों के लिंक अंत में हैं।

क्षमा करें:संपादन कार्य नहीं करता है; सब-नंबरिंग असंगत है

बंद मुद्दे

1. users.bb_locations_csv, उपयोगकर्ताओं और स्थानों के बीच अनेक-से-अनेक संबंध है:
   • उन तत्वों में से प्रत्येक एक असतत कॉलम में एक असतत पंक्ति में एक प्रविष्टि होनी चाहिए
   • एक उपयोगकर्ता के पास कई स्थान हो सकते हैं और 1 स्थान में कई उपयोगकर्ता कई-से-अनेक हो सकते हैं
   • पढ़ें ▶यह पोस्ट◀ इस पर चर्चा करने के लिए कि इसका इलाज कैसे किया जाता है और इससे किस स्तर पर निपटा जाता है
   • इस तार्किक स्तर पर, यह सिर्फ एक n::n संबंध है, जैसा कि मैंने खींचा है, आप इसके बारे में अभी के लिए भूल सकते हैं, यह आपूर्ति की जाएगी, बस, जब हम भौतिक चरण में पहुंचेंगे।
   • मेरा विश्वास करो, मैं कोड प्रदान करूंगा जो ...WHERE IN () से अधिक जटिल नहीं है। आपके घोषित उद्देश्य के लिए।
   • दूसरे विचार पर, अगर मैं आपकी उंगलियों को तोड़ दूं, तो आप और भी धीमे टाइप करेंगे, इसलिए मैं बेहतर नहीं हूं
   • ठीक है, आपका ऐप ब्राउज़र आधारित है, और पृष्ठ गतिशील है (मेरी सलाह स्थिर पृष्ठों के लिए थी जिन्हें स्पर्श करने की आवश्यकता है); चेक बॉक्स के साथ आगे बढ़ें।
     .
2. users.bb_categories_csv, उपयोगकर्ताओं और श्रेणियों के बीच अनेक-से-अनेक संबंध है
   • ऐसा ही।
     ।

3. पुष्टि:एक बुलेटिन (बीबीएस) एक उपयोगकर्ता के बिना मौजूद नहीं है; एक उपयोगकर्ता एक बुलेटिन जारी करता है, और वह पूरे चक्र को शुरू करता है; फिर जवाब और रेटिंग आमंत्रित करता है।

   3.1 पुष्टि की गई:वास्तव में केवल एक बुलेटिन बोर्ड है और यह डेटाबेस में एक चीज़ के रूप में मौजूद नहीं है।

   3.2 पुष्टि:कि संगठन में एक से अधिक बुलेटिन बोर्ड नहीं होंगे, और वर्गीकरण और वर्गीकरण सभी को पर्याप्त रूप से श्रेणी तालिका/कार्य द्वारा नियंत्रित किया जाता है

4. हटा दिया गया।

5. पुष्टि:बुलेटिन और उत्तरों के बीच का अंतर यह है कि उत्तर मौजूद होने के लिए बुलेटिन पर निर्भर होते हैं, उनका कोई शीर्षक नहीं होता है और उन्हें स्थान या श्रेणी के आधार पर वर्गीकृत नहीं किया जाता है क्योंकि वे मौजूद होने के लिए बुलेटिन पर ही निर्भर होते हैं।

6. हटा दिया गया।

7. टिप्पणियाँ नोट की गईं। हल किया गया।

7.1 किसी अन्य उपयोगकर्ता द्वारा सबमिट किए गए प्रत्येक बुलेटिन के लिए, प्रत्येक उपयोगकर्ता एक से अधिक उत्तर पोस्ट कर सकता है।

7.2. किसी उपयोगकर्ता द्वारा सबमिट किए गए प्रत्येक बुलेटिन के लिए, वह उपयोगकर्ता एक या एक से अधिक उत्तर पोस्ट कर सकता है।

7.3. हटा दिया गया।

7.4. हटा दिया गया।

.
8. पुष्टि की गई:प्रत्येक उपयोगकर्ता बुलेटिन में अधिकतम एक रेटिंग पोस्ट कर सकता है (जिसे निरस्त/बदला जा सकता है)
।
9. पुष्टि की गई:प्रत्येक उपयोगकर्ता उत्तर के लिए अधिकतम एक रेटिंग पर पोस्ट कर सकता है (ठीक इसी तरह)

10.1. दिया गया:उपयोगकर्ता नाम संगठन से आता है और यह अद्वितीय नाम है जो कर्मचारियों की पहचान करता है। उदाहरण के लिए ईमेल हैं [email protected] - प्रमाणीकरण ldap के साथ किया जाता है और कर्मचारियों के बारे में अन्य जानकारी प्राप्त करने के लिए कनेक्ट करने के लिए इसकी आवश्यकता होती है

• पुष्टि की गई:उपयोगकर्ता नाम एक उत्कृष्ट पहचानकर्ता है

10.2 पुष्टि:प्रथम नाम, अंतिम नाम ... जन्मस्थान, आदि People सुनिश्चित करने के लिए (पारंपरिक) कॉलम के रूप में बने रहते हैं डुप्लीकेट नहीं हैं।
.
11. दिया गया:फिलहाल हम अपने कार्यालयों को आकस्मिक नामों से पहचान सकते हैं जो आमतौर पर संगठन के भीतर जाने जाते हैं, क्योंकि हमारे पास केवल 3 मुख्य कार्यालय और कई फील्ड कार्यालय हैं। तो उदाहरण वाशिंगटन डीसी या वर्जीनिया फील्ड ऑफिस होंगे। कुल मिलाकर मुझे लगता है कि हम कोशिश करेंगे और कुल 20 से नीचे रखेंगे। मैं प्रत्येक स्थान का सटीक पता भी रिकॉर्ड करना चाहता हूं क्योंकि इसका उपयोग उपयोगकर्ताओं के लिए विशिष्ट रूप से कार्यालयों की पहचान करने के लिए किया जा सकता है।

• प्रदान किया गया:StateCode+Town पीके के रूप में; IsMainOffice बूलियन के रूप में।

.
12. पुष्टि की गई:Description और Name Category . के लिए आवश्यक हैं।
.
13. दिया गया:उपयोगकर्ता कुछ श्रेणियों में पोस्ट नहीं कर पाएंगे। केवल पर्याप्त उच्च अधिकार वाले उपयोगकर्ताओं को ही कुछ श्रेणियों में पोस्ट करने का अधिकार होगा।

• प्रदान किया गया:Permission User, Location, Category . में ऐसे अधिकारों के मूल्यांकन का एक तरीका है।

.
14. पुष्टि की गई:Location.Administrator है UserId Location . के लिए व्यवस्थापक का .
.
15. दिया गया:कभी भी केवल पसंद या नापसंद की आवश्यकता होगी। मुझे नहीं लगता कि किसी तटस्थ स्थिति की आवश्यकता है क्योंकि यह मतदान न करने जैसा ही है? पसंद करना बुलेटिन के जवाबों के लिए अधिक प्रासंगिक लगता है जो ईमानदार होने के लिए पोस्ट करता है। यानी 'मैं आपकी प्रतिक्रिया देखता हूं और अपनी खुद की लिखने के बजाय मैं आपसे सहमत हूं - मौजूदा बुलेटिन बोर्ड कुछ हद तक संगठन में एक सामाजिक पहलू है और मुझे लगता है कि पसंद और नापसंद/सहमत और असहमत विवाद का एक स्तर बनाता है जो भागीदारी को प्रोत्साहित करता है . हालांकि किसी बुलेटिन को पसंद या नापसंद करना हमेशा पूरी तरह से उचित नहीं हो सकता है।

15.1 प्रदान किया गया:Like BulletinRating . में बूलियन के रूप में और ResponseRating . इसके लिए प्रत्येक एक्सेस पर व्याख्या की आवश्यकता होगी।
15.2. जब यह बूलियन नहीं रह जाता है, तो इसे RatingCode . में बदला जा सकता है , और लुकअप तालिका के रूप में कार्यान्वित किया गया। नाम तब जॉइन द्वारा निर्धारित किए जाते हैं, और व्याख्या समाप्त हो जाती है। मैंने इसे फर्स्ट डेटा मॉडल में ड्रा किया, ताकि आप देख सकें कि मेरा क्या मतलब है15.3. दूसरे डेटा मॉडल में निकाला गया.
.
16. पुष्टि की गई:प्रत्येक उपयोगकर्ता का एक घर होता है Location (Locations की सूची के अलावा जिसमें वे रुचि रखते हैं)।
.
17. पुष्टि की गई:Permission (13) के अनुसार।
.
18. पुष्टि की गई:डेटा मॉडल के अनुसार और अनुमतियों की आवश्यकता हो सकती है।

18.1. यदि आप इसे अभी करते हैं, तो आपको इस बात की चिंता करने की आवश्यकता नहीं होगी कि संगठन कब किसी निश्चित Person को रोकने का निर्णय लेता है। Responses पोस्ट करने से या Bulletins , या उन्हें रेटिंग दें; और चाहता है कि वह सुविधा कल लागू हो।

18.2. यहां तक ​​कि अगर आप इसे लागू नहीं भी करते हैं, तो उन मूल्यों के बीच अंतराल छोड़ दें जिन्हें आप लागू करते हैं।
।
19 पुष्टि की गई:एक Bulletins के बारे में है एक Location .

19.1. पुष्टि की गई:कोई Bulletins नहीं हैं बिना किसी Location . के

19.2. पुष्टि की गई:कोई Bulletins नहीं हैं बिना किसी Location . के ।

19.3 पुष्टि की गई:कोई Bulletins नहीं हैं बिना User . के (घोषणात्मक)। लेकिन अभी तक हमारे पास उस User . को प्रतिबंधित करने का कोई तरीका नहीं है; इसलिए कोई भी User एक Bulletinsइनसेट कर सकते हैं किसी भी Location . के लिए (आप इसे कोड में सीमित कर सकते हैं, उदाहरण के लिए Locations प्रत्येक User Is Interested In ।

19.4 पुष्टि की गई:कोई BulletinRatings नहीं है बिना Bulletins . के और एक रेटिंग User ।

19.5 पुष्टि की गई:कोई Responses नहीं हैं बिना Bulletins . के ।

19.4 पुष्टि की गई:कोई ResponseRatings नहीं हैं बिना Response . के और एक रेटिंग User ।

19.7. लेकिन, User हो सकते हैं , स्थान, and श्रेणियाँ`, स्वतंत्र रूप से।

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

20.1. मेरा अनुभव है table_name जैसा कि tableName के विपरीत वास्तव में तकनीकी रूप हैं, और उपयोगकर्ता उन्हें पसंद नहीं करते हैं; लगातार मिले-जुले केस सभी को पसंद आते हैं। यह उन चीजों में से एक है जिसे बदलना असंभव है, इसलिए सावधानी से चुनें।
.
21. तालिकाओं को एक साथ समूहबद्ध करने की आपकी आवश्यकता के लिए, जो अच्छा है, ध्यान रखें कि यह एक भौतिक समस्या है। तार्किक डेटा मॉडल स्तर पर, तालिकाओं के सामान्य नाम होते हैं, जो भौतिक समस्याओं से मुक्त होते हैं। कल्पना करें कि भौतिक तालिकाओं के पहले कुछ इस तरह है (और कृपया इसके लिए बड़े अक्षरों का उपयोग करें):
- REF_ संदर्भ के लिए (जैसे उपयोगकर्ता) और लुकअप टेबल
- BUL_ बुलेटिन प्रणाली के लिए
।
मैं बड़े अक्षरों वाली तालिकाओं का नाम नहीं बता पा रहा हूँ? मुझे यकीन नहीं है कि क्यों। मुझे नहीं पता कि मेरे पास अपरकेस टेबल नाम क्यों नहीं हो सकते हैं। क्या इसका संबंध MyIsam डेटाबेस तालिकाओं के उपयोग से है?

.
22. rank (सभी) सीधे डेटाबेस से प्राप्त किए जा सकते हैं (याद रखें, डेटा मॉडलिंग के दौरान कोड के बारे में चिंता न करें)। यदि आप इसे स्टोर करते हैं, तो यह एक सामान्यीकरण त्रुटि है; एक डुप्लिकेट कॉलम; जिसे अप-टू-डेट रखना होता है; जो व्युत्पन्न मूल्य के साथ समकालिकता से बाहर निकल सकता है; जिसे अद्यतन विसंगति कहा जाता है। पाँचवाँ सामान्य प्रपत्र अद्यतन विसंगतियों को समाप्त करता है। यह मेरा सामान्यीकरण का न्यूनतम स्तर है, इसलिए आपको मुझसे यही मिलेगा।

22.1. मैं सॉर्ट ऑर्डर या लोकप्रियता के मुद्दे में बिल्कुल भी हस्तक्षेप नहीं कर रहा हूं; वास्तव में, इसकी आवाज़ से, आपने उस कार्यक्षमता को बंद नहीं किया है। मैं केवल अनावश्यक डेटा ले रहा हूं, रैंक कॉलम , बाहर, सामान्यीकरण प्रक्रिया के भाग के रूप में।

22.2 यह रहा एक ▶त्वरित ट्यूटोरियल◀ मजबूत> रैंक() ऑपरेटर पर (जैसा कि आमतौर पर जाना जाता है)। यह एएनएसआई एसक्यूएल नहीं है; यह एक Oracle और MS एक्सटेंशन है। हालाँकि, यदि आप उपश्रेणियों को समझते हैं, तो इसकी आवश्यकता नहीं है, यही वजह है कि Sybase के पास यह नहीं है। मुझे संदेह है कि MySQL के पास है, इसलिए आपको इसके चारों ओर अपना सिर प्राप्त करने की आवश्यकता है। स्केलर सबक्वेरी को समझना एक पूर्व-आवश्यकता है। साइबेस सिंटैक्स, इसलिए अपने सेमी-कोलन को अंदर करें, आदि। बेझिझक विशिष्ट प्रश्न पूछें।
।
मैंने कभी भी लिखने का वह तरीका नहीं देखा है रैंक =(चुनें... क्या वह है रैंक के समान (चुनें ...)?

.
22.3. यह समझने की जरूरत है कि क्यों, कोई समस्या नहीं है। केवल बच्चे आँख बंद करके सरल नियमों का पालन करते हैं, और आप निश्चित रूप से उनमें से एक नहीं हैं।
.
23. पुष्टि की गई:users.total_bulletins बेमानी है; इसे व्युत्पन्न किया जा सकता है। हटाया गया.
.
24. आपके सभी पीके आईडी हैं। क्या आप अभी तक कोड में खो जाने से नहीं थके हैं? चिपकाने के बारे में भूल जाओ Id आईओटी पीके हर चीज पर चलता है, आइए जानें कि आपके उपयोगकर्ता उनकी संस्थाओं की पहचान करें; कौन सी संस्थाएं वास्तव में स्वतंत्र हैं, और दूसरी जो स्वतंत्र संस्थाओं पर निर्भर हैं।

24.1. कभी भी Id का उपयोग न करें या ऐसा कोई रूप। जहां यह PK है, वहां पूर्ण रूप का प्रयोग करें।

24.2. पीके टेबल सहित, लोकेशन_आईडी, लोकेशन_आईडी, जहां कहीं भी हो, पर कॉल करें। अपवाद तब होता है जब आपको भूमिका दिखाने की आवश्यकता होती है। यह डेटा मॉडल में स्पष्ट हो जाएगा.
.
25. आपके पास कोई घोषणात्मक संदर्भात्मक सत्यनिष्ठा नहीं है, कोई परिभाषित . नहीं है विदेशी कुंजी। यह कई अलग-अलग कारणों से बुरी खबर है। इन प्रश्नों के स्पष्ट हो जाने के बाद, कृपया इन्हें इसमें जोड़ें। DRI का अर्थ है कि जितना संभव हो सके, यदि सभी नहीं, तो SQL में सत्यनिष्ठा की घोषणा की जाती है। आईएसओ/आईईसी/एएनएसआई एसक्यूएल मानक इसके लिए अनुमति देता है, लेकिन बाजार का फ्रीवेयर अंत मानक प्रदान नहीं करता है, और धीरे-धीरे पकड़ रहा है। इसका मतलब है कि सर्वर एफके तालिका में एक पंक्ति को तब तक जोड़ने की अनुमति नहीं देगा जब तक कि पीके मूल तालिका में मौजूद न हो। MySQL ने हाल ही में विदेशी कुंजी के लिए DRI प्रदान किया है। FK के लिए, देखें ▶ यह लेख◀ .

25.1 CHECK बाधाओं और नियमों के लिए, आपको उन्हें कोड में लागू करना होगा।

मेरी विदेशी कुंजी इस तरह हैं, उपयोगकर्ता-आईडी (एफके) =उपयोगकर्ता। आईडी (पीके) मुझे यकीन नहीं है कि मैंने जो किया है उसे अन्य कैसे जोड़ा जाए, लेकिन निश्चित रूप से ऐसा करने के बाद मुझे पता चलेगा कि कैसे करना है।

पच्चीस। टिप्पणियां नोट की गईं। मैं एक MySQL विशेषज्ञ नहीं हूँ। हां, ये ऐसे मुद्दे हैं जिन्हें आपको अपने लिए समझना होगा। सामान्य तौर पर, मेरे विचार से, MySQL कानूनी नहीं है; SQL-ish किसी भी चीज़ के लिए, आपको InnoDB की आवश्यकता है।

.
27. दिया गया:मैंने बुलेटिन के लिए छँटाई आवश्यकताओं पर फिर से विचार किया है। उपयोगकर्ता कालानुक्रमिक रूप से क्रमबद्ध कर सकते हैं- आसान, समझ में आता है। उपयोगकर्ता बुलेटिन के नवीनतम उत्तर की तिथि के अनुसार बुलेटिनों को छाँट सकते हैं। तब हम रैंक के बारे में भूल सकते हैं और बुलेटिनों को उनकी अंतिम प्रतिक्रिया के समय तक कालानुक्रमिक रूप से क्रमबद्ध करना वास्तव में आसान होना चाहिए? आपके क्या विचार हैं।

खुले मुद्दे

(शून्य)

डेटा मॉडल

ठीक है, यह मानते हुए कि आपको ईआरडी में कोई समस्या नहीं है, और सभी बंद मुद्दों को लागू करते हुए, मैंने डेटा का मॉडल तैयार किया है, और एक पांचवां डेटा मॉडल 09 दिसंबर 10 तैयार किया है। आपकी समीक्षा के लिए। मुझे निश्चित रूप से और भी बहुत कुछ चाहिए इस पर प्रतिक्रिया, प्रश्न आदि। मुझे यह स्वीकार करने में कठिनाई हो रही है कि यह हो गया है। अपने समस्या क्षेत्रों के लिए वास्तविक कोड लिखना शुरू करना शायद सबसे अच्छा है।

लिंक

▶IDEF1X नोटेशन से लिंक करें◀ डेटा मॉडल को पढ़ने से पहले आपको वास्तव में इसे पढ़ना और समझना होगा।

▶पांचवें बुलेटिन डेटा का लिंक मॉडल◀ इकाई संबंध आरेख पहले पृष्ठ पर है, उसके बाद डेटा मॉडल . है ।

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

• नोटेशन दस्तावेज़ के अनुसार पहचानकर्ता (ठोस रेखाएँ) पर ध्यान दें। रीढ़ की हड्डी, प्रणाली की कशेरुका Location ... Bulletin ... Response . है ।

• ध्यान दें कि Keys वास्तव में कई व्यावसायिक नियम लागू करते हैं।

• मैंने जो प्राकृतिक पदानुक्रम प्रदान किया है, उस पर ध्यान दें। देखें कि क्या इसमें आपके लिए कोई अर्थ है।

• VerbPhrases वास्तव में महत्वपूर्ण हैं; देखें कि क्या उनका कुछ मतलब है।

पहले डेटा मॉडल और प्रतिक्रियाओं पर टिप्पणियां

मेरा एक प्रश्न यह है कि स्थान की प्राथमिक कुंजी का उपयोग बच्चे की प्राथमिक कुंजी बनाने के लिए किया जाएगा?(वे एक ठोस रेखा से जुड़े हुए हैं) मैं वास्तव में उस अवधारणा को नहीं समझता

• बुलेटिन के लिए एक अच्छा पहचानकर्ता क्या है? , आपके उपयोगकर्ता किसी बुलेटिन की पहचान करने के लिए स्वाभाविक रूप से क्या उपयोग करते हैं ...
• "क्या आपने कल वर्जीनिया एफओ का बुलेटिन देखा है?",
• "वाशिंगटन की सैली निश्चित रूप से अच्छे बुलेटिन लिखती है", आदि।

या वह संबंध उपयोगकर्ता और बुलेटिन के बीच क्यों नहीं है?

• ऊपर बताए गए इरादे के अनुसार, चूंकि मैंने अब रेटिंग को एक तालिका के रूप में दिखाया है और प्रतिपादन क्या होगा, एक बार, मैं इसे हटा दूंगा

• मुझे लगता है कि अनुमति एक इकाई होनी चाहिए।

• Bulletins PK अब (StateCode, Town, UserId, SequenceNo) . है . स्पष्ट होने के लिए, SequenceNo StateCode, Town, UserId . के भीतर है :यह सैली के 5वें बुलेटिन री MO/Billngs FO के लिए 5वां होगा।

• ध्यान दें कि उपयोगकर्ता सेटिंग्स BulletinsPerPage ,आदि, User . के साथ 1::1 हैं , इसलिए वे User . में हैं; चाइल्ड टेबल गलत होगी।

• टंकण संबंधी त्रुटियों को ठीक किया गया।

दूसरा डेटा मॉडल और प्रतिक्रियाओं की टिप्पणियां

• दोनों के लिए पीके Bulletins और Response प्रतिबिंबित करने के लिए बदल दिया गया है (7)। BulletinNo और ResponseNo BulletinDate . से बदल दिया गया है और ResponseDate (जो कि CreatedDate . हुआ करता था ), प्रति User . एकाधिक उत्तरों की अनुमति देने के लिए प्रति Bulletins ।

तीसरे डेटा मॉडल और प्रतिक्रियाओं की टिप्पणियां

विश्वास करें कि आपका ब्रेक अच्छा रहा।

1. कम से कम 30 साल पहले (जिसके बारे में मुझे पता है), उद्योग के दिग्गजों के बीच यह बहस हुई थी। नाम हमेशा एकवचन होते हैं। टेबल्स संज्ञा हैं। VerbPhrases क्रिया हैं। यह डीबी नामकरण सम्मेलनों तक ही सीमित नहीं है, यह दस्तावेजों, थीसिस, शोध प्रबंध आदि पर लागू होता है। दस्तावेज़ के अंत में आपके पास 5 निष्कर्ष हो सकते हैं, लेकिन टीओसी और पृष्ठ के शीर्ष दोनों में अनुभाग या अध्याय शीर्षक हो सकता है। "निष्कर्ष" है।

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

   वैसे भी, इस तरह के नियमों द्वारा समर्थित भाषा की आसानी (चर्चा, एसक्यूएल, दस्तावेज़ीकरण) को पर्याप्त रूप से समझाया नहीं जा सकता है; जैसे-जैसे आप अधिक से अधिक SQL कोड लिखेंगे, यह स्पष्ट होता जाएगा।

   आप जो कुछ भी चाहते हैं उसका उपयोग करने के लिए आप हमेशा स्वतंत्र हैं। मैं केवल एकवचन ही डिलीवर करता हूँ।

2. मेरे लिए उत्तम है।

   लेकिन आपको यह ध्यान रखने की आवश्यकता है कि पहचाने गए अनुक्रम में वे दो तत्व (अला गैर-पीके अद्वितीय सूचकांक, या वैकल्पिक कुंजी) सार्वभौमिक रूप से एक व्यक्ति के लिए विशिष्टता स्थापित करने के लिए आवश्यक हैं। उन्हें हटाने से दो चीजें होंगी। सबसे पहले, आप अब Users . में विशिष्टता की पहचान नहीं कर पाएंगे (और इस प्रकार आपके पास डुप्लिकेट पंक्तियां हो सकती हैं)। दूसरा, एके गैर-अद्वितीय बन जाता है, एक उलटा प्रविष्टि।

3. मुद्दा यह है (किसी एक पोस्ट के विपरीत), कोई भी कॉलम जो 1::1 हो User के साथ PK,User . में रहना चाहिए . सभी वरीयता सेटिंग्स। चूंकि हमने InterestedLocations . को साफ़ कर दिया है औरInterestedCategories , मैं केवलBulletinsPerPage . के बारे में जानता हूं बचा हुआ; लेकिन मुझे यकीन है कि अन्य भी हैं। IsPreference2 एक उदा है। एक बूलियन का;NumPreference3 एक उदा है। एक पूर्णांक का। आदि। आप मुझे बता सकते हैं कि वास्तविक प्राथमिकताएं क्या हैं।

   (आइए इसे बहुवचन में आजमाएं:... कोई भी कॉलम जो 1::1 हो User के साथ PK,Users . में रहना चाहिए . बस यह मेरे लिए नहीं करता है, मैं टूटी-फूटी अंग्रेजी में फंस जाता हूं, और मैं अपनी मातृभाषा के बारे में थोड़ा कीमती हूं।)

   डेटा मॉडल अपडेट किया गया।

4. उत्कृष्ट। जब आप इसके साथ सहज हों तो मुझे बताएं, और मैं आपको भौतिक मॉडल दूंगा।

   VerbPhrases के बारे में कैसे?

टिप्पणियां 06 दिसंबर 10 20:38 ईएसटी (छोटे अपडेट)

.
28. जहां एफके के रूप में पीके की केवल एक घटना होती है, निश्चित रूप से, एफके कॉलम नाम पीके कॉलम नाम के समान होता है। हालांकि, जब FK के एक से अधिक अवसर हों (ResponseRating पर एक नज़र डालें) ), तीन हैं UserIds ), हमें उन्हें अलग करने की जरूरत है। IDEF1X शब्दावली में इसे रोल्स कहा जाता है। User . की भूमिका Bulletins . को किसने जारी किया है Issuer , और इसी तरह। स्पष्ट रूप से उस नाम का उपयोग करना बेहतर है, और इसे पूरे पदानुक्रम में सुसंगत रखें (UserId . नहीं) Bulletins . में और फिर जब हम Response . पर पहुंचते हैं , जहां दो हैं, और एक भेदभाव की मांग की जाती है, इसे IssuerId में बदलें . मुझे लगा कि आपको इससे कोई समस्या हो सकती है; प्रारंभिक चरणों में, उपयोग Issuer.UserId . है ताकि यह बिल्कुल स्पष्ट हो कि यह UserId है एक FK के रूप में, और भूमिका है Issuer; जब हम भौतिक मॉडल पर पहुंचते हैं, तो यह सरल हो जाता है IssuerId .

इसी तरह, हमारे पास कई डेटटाइम कॉलम हैं (यदि आप चाहें तो संक्षिप्त तिथि; अन्यथा डीटीएम), जिन्हें अलग करने की आवश्यकता है।
।
29. क्या IDEF1X नोटेशन दस्तावेज़ का कोई मतलब नहीं था?

• प्रत्येक तालिका के लिए पीके निर्दिष्ट क्रम में पंक्ति के ऊपर है।
• याद रखें कि हम पैरेंट टेबल के पीके को वैसे भी ले जा रहे हैं, और यदि कोई अर्थ है, तो उन एफके का उपयोग करके बच्चे को पीके बनाना है।

• Bulletins . के लिए :

  • स्थान FK (StateCode, Town) जिसके लिए यह जारी किया गया है
  • UserId जारीकर्ता की
  • और दिनांक समय इसे अद्वितीय बनाने के लिए जारी किया गया था।
  • इसलिए (स्टेटकोड, टाउन, जारीकर्ता आईडी, बुलेटिन दिनांक)`

• सभी ResponseRatings को हटाने के लिए इसके लिए Bulletins , WHERE = . का उपयोग करें उन चार पर Bulletins स्तंभ।

.
30. क्योंकि (State, Town) Location . का PK है , कहीं भी ले जाना। और यह Bulletins . का हिस्सा है PK, इसलिए कोई भी आश्रित तालिका उन स्तंभों को ले जाती है क्योंकि वे Bulletins . ले जा रहे हैं पी.के.

हमने पहले पहचाना था कि (State, Town) पीके है, <स्ट्राइक>मैं इसे वैसे ही छोड़ दूंगा परिवर्तन के लिए (38) देखें।

.
33. चर्चा के लायक। हां, यदि आप इसे प्रदर्शित करने जा रहे हैं (उदाहरण के लिए) Responses , और उपयोगकर्ता UserName understand को समझते हैं . नहीं, अगर यह 30 बाइट्स है, और एक अद्वितीय 4 बाइट भी है UserId . विचार यह है कि इन विकल्पों को सचेत रूप से, इस बात से अवगत कराया जाए कि आप क्या छोड़ रहे हैं, जब आप अंततः यह निर्णय लेते हैं कि कुछ 6 कॉलम 30-बाइट कुंजी बच्चों के लिए माइग्रेट करने के लिए बहुत बोझिल है।

• मैंने शुरू में ही बता दिया था कि मैं UserId का उपयोग करूंगा एक विशिष्ट Id . के रूप में Pk, क्योंकि इसे कई चाइल्ड टेबल में ले जाया/माइग्रेट किया जाता है।
• हम यह छोड़ सकते हैं कि इसे बाद के लिए कैसे बनाया जाए। लेकिन यह एक शुद्ध सरोगेट पीके है।

.
34. कोई बात नहीं। Category पहले से ही है। मैं Order बदल दूंगा करने के लिए ListOrder .

.
35. ज़रूर। मैंने जो पढ़ा और सुना है, उसके आधार पर मैं उससे काफी खुश हूं। लेकिन मैं चाहूंगा कि आप कोड लिखने से पहले कुछ आत्मविश्वास हासिल करने के लिए आगे-पीछे हों। वैकल्पिक रूप से, इसे सीखने के अनुभव के रूप में देखें, और स्वीकार करें कि मॉडल और कोड बाद में बदल सकते हैं। क्या आप चाहते हैं कि मैं अभी फिजिकल प्रोड्यूस करूं? यदि आप मुझे कोई और सभी सुधार देते हैं, तो मैं अगला संस्करण प्रकाशित करूंगा। मैं User . में वरीयता की अपेक्षा कर रहा हूं . इसके अलावा, कार्यों के माध्यम से जल्दी से चलाएं और जांचें कि आपके पास सभी आवश्यक कॉलम हैं।

सीखने के उद्देश्य और रुचि के लिए कुछ अन्य उत्तरों को अवश्य देखें।

.
36. जुड़ता है। आप अभी <स्ट्राइक>चार में शामिल हों एक के विपरीत तीन कॉलम। SQL जॉइन के साथ बोझिल है, और नया सिंटैक्स जो इसे आसान बनाने वाला था, वास्तव में अधिक बोझिल है। मेरे कोडर्स कभी भी जॉइन नहीं लिखते हैं:हम समय और टाइपो को बचाते हैं। मेरे पास एक प्रो है जो दो या दो से अधिक टेबल देता है, सभी कॉलम और जॉइन के साथ कोड जेनरेट करेगा। मैं आपके लिए इसे रूपांतरित करने के लिए पर्याप्त MySQL नहीं जानता।

डेटा मॉडल अपडेट किया गया.
.

टिप्पणियां 08 दिसंबर 10 20:49, चौथा डेटा मॉडल और प्रतिक्रियाएं

.
उपरोक्त पिछले अनुभाग को तुरंत देखें, छोटे अपडेट हैं।

IDEF1X:आपकी गति ठीक है।

बच्चे पर ध्यान दें हमेशा एक एफके (या तो ठोस या टूटी हुई रेखा) के रूप में माता-पिता पीके "विरासत" प्राप्त करता है, अन्यथा उनके बीच कोई संबंध नहीं है। वैसे भी बच्चे में मौजूद इन स्तंभों का उपयोग करके, बच्चे को PK बनाने के लिए, हम अर्थ को आगे बढ़ाते हैं (और वह ठोस और टूटे के बीच का अंतर है)। और इस प्रकार हमें बच्चे के लिए एक स्वतंत्र पहचानकर्ता की तलाश करने की आवश्यकता नहीं है। इस पद्धति में संबंधपरक शक्ति बाद में स्पष्ट हो जाएगी, जब आप कोडिंग कर रहे होंगे।

जिस अनुभाग से हम निपट रहे हैं वह पहचानकर्ता . के बारे में है :प्राकृतिक बनाम अप्राकृतिक; अर्थहीन बनाम अर्थहीन। बाद में आप देखेंगे कि हम इंजन की रिलेशनल क्षमता का उपयोग कैसे कर सकते हैं, जब पैरेंट पीके से चाइल्ड पीके बनता है। (क्या आपका उपनाम आपके पिता के समान नहीं है?)

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

वैसे भी, मॉडल को लागू करने के लिए आगे बढ़ें। बस इस बात का एहसास करें कि हम शायद किसी बिंदु पर बदलाव करेंगे। अपने सभी डीडीएल को सेव करें। अपने सभी परीक्षण डेटा को इन्सर्ट स्टेटमेंट के रूप में या टेबल बैकअप या कैरेक्टर फॉर्मेट एक्सपोर्ट के रूप में सहेजें (पता नहीं MySQL इस क्षेत्र में क्या कर सकता है/नहीं कर सकता है) ..
37.1. संभाला, n::n Office के साथ संबंध &Category . आप केवल तभी "देखेंगे" जब हम भौतिक मॉडल पर पहुंचेंगे।

37.2. हो गया।

37.3 हो गया।
.
38. उत्कृष्ट। साथ ही छोटा। ध्यान दें कि उनके पास कभी भी दो Office नहीं हो पाएंगे उसी ज़िप कोड में। NUMERIC(5,0) अच्छा है, लेकिन मुझे लगा कि अमेरिका 7 अंकों की ओर बढ़ रहा है। कोई बात नहीं, आप इसे समझ सकते हैं; यह Office . के लिए एक उत्कृष्ट PK है . अब यह कॉलम, जो Address . का हिस्सा था , शायद ZipCode , दोहराव के बिना, एक उच्च उद्देश्य के लिए उन्नत किया गया है; चूंकि हम इसे 5 चाइल्ड टेबल में ले जा रहे हैं, और हम चाहते हैं कि पीके नाम स्पष्ट हो, जैसा कि पहले समझाया गया था, हम इसे OfficeCode कहेंगे।; OfficeZipCode मूर्खतापूर्ण हो सकता है।

हमें Name . पर एक अद्वितीय अनुक्रमणिका की आवश्यकता है यह सुनिश्चित करने के लिए कि वे दो Office नहीं जोड़ते हैं एक ही नाम के साथ। ध्यान दें, स्पष्टीकरण के उद्देश्य से, यह वास्तव में Office . की तार्किक कुंजी है , (StateCode, Town) . की जगह , और ऐसा ही रहता है।

मुझे अब भी लगता है कि आपको StateCode . की आवश्यकता हो सकती है और Town एक त्वरित संदर्भ के रूप में (Address . में कहीं बैठने के अलावा )

डेटा मॉडल अपडेट किया गया, पांचवां अब समीक्षा के लिए उपलब्ध है। आपने ...Date . के लिए अपनी पसंद नहीं बताई बनाम ...Dtm . मैं बाद वाले के साथ जा रहा हूं, क्योंकि यह अधिक विशिष्ट है, साथ ही समय घटक की पहचान करना। बदलने में आसान।

यह उत्तर अधिकतम लंबाई तक पहुंच गया है। "भाग II" में जारी है