संबंधपरक तालिका नामकरण सम्मेलन

Question

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

इसलिए, अगर मुझे एक तालिका "उपयोगकर्ता" मिली और फिर मुझे ऐसे उत्पाद मिले जो केवल उपयोगकर्ता के पास होंगे, तो क्या तालिका को "user_product" या सिर्फ "उत्पाद" नाम दिया जाना चाहिए? यह कई रिश्तों में से एक है।

और आगे, अगर मेरे पास (किसी कारण से) प्रत्येक उत्पाद के लिए कई उत्पाद विवरण होंगे, तो क्या यह "user_product_description" या "product_description" या सिर्फ "विवरण" होगा? निश्चित रूप से सही विदेशी कुंजी सेट के साथ .. इसका केवल नामकरण ही समस्याग्रस्त होगा क्योंकि मेरे पास उपयोगकर्ता विवरण या खाता विवरण या जो कुछ भी हो सकता है ..

क्या होगा अगर मैं केवल दो कॉलम के साथ एक शुद्ध संबंधपरक तालिका (कई से कई) चाहता हूं, तो यह कैसा दिखेगा? "user_stuff" या शायद "rel_user_stuff" जैसा कुछ? और अगर पहले वाला, इससे क्या अंतर होगा, उदाहरण के लिए "user_product"?

किसी भी मदद की बहुत सराहना की जाती है और अगर वहाँ कुछ नामकरण सम्मेलन मानक है कि आप लोग सलाह देते हैं, तो लिंक करने के लिए स्वतंत्र महसूस करें।

धन्यवाद

Comments

(ए) चार साल पहले सवाल पूछा गया था और जवाब दिया गया था। (b) प्रश्न और चयनित उत्तर दोनों में उच्च मत हैं। (c) हमारे पास एक नामकरण-सम्मेलनों का टैग है (d) यह उत्तर देने के लिए शुरुआती के लिए "राय-आधारित" हो सकता है, लेकिन यह अनुभवी तकनीकी लोगों के लिए मानक का मामला है, जिसे साधक चाह रहा है। फिर भी, कई नुस्खों में से प्रत्येक के लिए कारण दिए गए हैं। (() इसलिए, प्रमाण के आधार पर, primarily opinion-basedअसत्य है।

— प्रदर्शन

यह अनुभवी तकनीकी लोगों के लिए मानकों का मामला है या प्राचीन IDEF मानकों पर आए लोगों का मानना ​​है कि वे वास्तविक मानक हैं।

— 16:10

इसके अलावा, कई अन्य क्यू री नामकरण परंपराएं हैं, सभी का मूल्य है। संदर्भ में दाईं ओर स्थित कॉलम में देखें ..

— PerformanceDBA

Answer 1

तालिका नाम

हाल ही में सीखा गया विलक्षण सही है

हाँ। हीथ्स से सावधान रहें। तालिका के नामों में बहुवचन किसी ऐसे व्यक्ति का एक निश्चित संकेत है जिसने किसी भी मानक सामग्री को नहीं पढ़ा है और डेटाबेस सिद्धांत का कोई ज्ञान नहीं है।

मानकों के बारे में कुछ अद्भुत बातें हैं:

• वे सभी एक दूसरे के साथ एकीकृत हैं
• वे साथ साथ काम करते हैं
• वे हमारे दिमाग से बड़े दिमाग से लिखे गए थे, इसलिए हमें उनसे बहस करने की जरूरत नहीं है।

मानक तालिका का नाम तालिका में प्रत्येक पंक्ति को संदर्भित करता है , जिसका उपयोग सभी वर्बेज में किया जाता है, न कि तालिका की कुल सामग्री (हम जानते हैं कि Customerतालिका में सभी ग्राहक शामिल हैं)।

संबंध, क्रिया वाक्यांश

वास्तविक रिलेशनल डेटाबेस में जो मॉडल किए गए हैं (जैसा कि प्री-1970 के रिकॉर्ड फाइलिंग सिस्टम के विपरीत है [ Record IDsजिसके द्वारा विशेषता के लिए SQL डेटाबेस कंटेनर में कार्यान्वित किया जाता है):

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

Diagram_A

बेशक, संबंध SQL में CONSTRAINT FOREIGN KEYचाइल्ड टेबल (अधिक, बाद में) के रूप में कार्यान्वित किया जाता है । यहाँ है क्रिया वाक्यांश (मॉडल में), विधेय है कि यह प्रतिनिधित्व करता (मॉडल से पढ़ने के लिए), और FK बाधा नाम :

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

तालिका • भाषा

हालाँकि, तालिका का वर्णन करते समय , विशेष रूप से तकनीकी भाषा में जैसे कि Predicates, या अन्य दस्तावेज, अंग्रेजी भाषा में स्वाभाविक रूप से एकवचन और बहुवचन का उपयोग करते हैं। ध्यान में रखते हुए तालिका को एकल पंक्ति (संबंध) के लिए नाम दिया गया है और भाषा प्रत्येक व्युत्पन्न पंक्ति (व्युत्पन्न संबंध) को संदर्भित करती है:

    Each Customer initiates zero-to-many SalesOrders

नहीं

    Customers have zero-to-many SalesOrders 

इसलिए, अगर मुझे एक तालिका "उपयोगकर्ता" मिली और फिर मुझे ऐसे उत्पाद मिले जो केवल उपयोगकर्ता के पास होंगे, तो क्या तालिका को "उपयोगकर्ता-उत्पाद" या सिर्फ "उत्पाद" नाम दिया जाना चाहिए? यह कई रिश्तों में से एक है।

(यह एक नामकरण-सम्मेलन का प्रश्न नहीं है; यह एक db डिजाइन प्रश्न है।) user::product1 :: n क्या मायने रखता है कि क्या productएक अलग इकाई है और क्या यह एक स्वतंत्र तालिका है , अर्थात। यह अपने आप मौजूद हो सकता है। इसलिए product, नहीं user_product।

और अगर productकेवल एक के संदर्भ में मौजूद है user, यानी। यह एक निर्भर तालिका है , इसलिए user_product।

Diagram_B

और आगे, अगर मेरे पास (किसी कारण से) प्रत्येक उत्पाद के लिए कई उत्पाद विवरण होंगे, तो क्या यह "उपयोगकर्ता-उत्पाद-वर्णन" या "उत्पाद-वर्णन" या सिर्फ "विवरण" होगा? निश्चित रूप से सही विदेशी कुंजी सेट के साथ .. इसका केवल नामकरण ही समस्याग्रस्त होगा क्योंकि मेरे पास उपयोगकर्ता विवरण या खाता विवरण या जो भी हो सकता है।

ये सही है। या तो user_product_descriptionXor product_descriptionसही होगा, जो उपरोक्त के आधार पर होगा। इसे दूसरे से अलग नहीं करना है xxxx_descriptions, बल्कि यह नाम देना है कि यह कहां है, उपसर्ग मूल तालिका है।

क्या होगा अगर मैं केवल दो कॉलम के साथ एक शुद्ध संबंधपरक तालिका (कई से कई) चाहता हूं, तो यह कैसा दिखेगा? "उपयोगकर्ता-सामान" या शायद "rel-user-stuff" जैसा कुछ? और अगर पहले वाला, इससे क्या अंतर होगा, उदाहरण के लिए "उपयोगकर्ता-उत्पाद"?

1. उम्मीद है कि रिलेशनल डेटाबेस में सभी टेबल शुद्ध रिलेशनल, सामान्यीकृत टेबल हैं। नाम में यह पहचानने की कोई आवश्यकता नहीं है (अन्यथा सभी तालिकाएं होंगी rel_something)।

2. यदि इसमें केवल दो माता-पिता के PKs शामिल हैं (जो तार्किक n :: n संबंध को हल करता है जो तार्किक स्तर पर एक इकाई के रूप में मौजूद नहीं है, एक भौतिक तालिका में), तो वह एक सहयोगी तालिका है । हां, आमतौर पर नाम दो मूल तालिका नामों का एक संयोजन है।

   • ध्यान दें कि इस तरह के मामले Verb Phrase पर लागू होते हैं, और इसे माता-पिता से माता-पिता तक पढ़ा जाता है, बच्चे की मेज की अनदेखी करना, क्योंकि जीवन में इसका एकमात्र उद्देश्य दो माता-पिता से संबंधित है।

     Diagram_C

   • अगर ऐसा है नहीं एक साहचर्य तालिका (यानी। दो पीकेएस के अलावा, यह डेटा शामिल हैं), तो यह उचित रूप से नाम दें, और क्रिया वाक्यांश इसे करने के लिए, रिश्ते के अंत में नहीं माता पिता लागू होते हैं।

     Diagram_D

3. यदि आप दो user_productतालिकाओं के साथ समाप्त होते हैं , तो यह एक बहुत जोर से संकेत है कि आपने डेटा को सामान्य नहीं किया है। तो कुछ कदम पीछे जाएं और ऐसा करें, और तालिकाओं को सही और लगातार नाम दें। नाम फिर खुद को हल करेंगे।

नामकरण परंपरा

किसी भी मदद की बहुत सराहना की जाती है और अगर वहाँ कुछ नामकरण सम्मेलन मानक है कि आप लोग सलाह देते हैं, तो लिंक करने के लिए स्वतंत्र महसूस करें।

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

1. केस एड्रेस करने वाला पहला आइटम है। सभी कैप्स अस्वीकार्य हैं। मिश्रित मामला सामान्य है, खासकर यदि टेबल उपयोगकर्ताओं द्वारा सीधे सुलभ हैं। मेरे डेटा मॉडल देखें। ध्यान दें कि जब साधक कुछ डीएनएसडीसी का उपयोग कर रहा है, जिसमें केवल लोअरकेस है, तो मैं वह देता हूं, जिस स्थिति में मैं अंडरस्कोर (आपके उदाहरण के अनुसार) शामिल करता हूं।

2. डेटा फ़ोकस बनाए रखें , एप्लिकेशन या उपयोग फ़ोकस नहीं। यह सब 2011 के बाद है, हमारे पास 1984 से ओपन आर्किटेक्चर है, और डेटाबेस को उन ऐप से स्वतंत्र माना जाता है जो उनका उपयोग करते हैं।

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

3. बहुत विचारशील हो, और तालिकाओं और स्तंभों को बहुत सटीक रूप से नाम दें । UpdatedDateयदि यह DATETIMEडेटाटाइप है, तो उपयोग न करें UpdatedDtm। _descriptionअगर इसमें डोज़ है तो इसका इस्तेमाल न करें ।

4. डेटाबेस में संगत होना महत्वपूर्ण है । का प्रयोग न करें NumProductएक ही स्थान पर उत्पादों की संख्या और इंगित करने के लिए ItemNoया ItemNumकिसी अन्य स्थान पर आइटम की संख्या का संकेत करने के लिए। लगातार NumSomethingसंख्याओं के लिए, और SomethingNoया SomethingIdपहचानकर्ताओं के लिए उपयोग करें ।

5. स्तंभ नाम को किसी तालिका नाम या लघु कोड के साथ उपसर्ग न करें, जैसे कि user_first_name। SQL पहले से ही क्वालीफायर के रूप में टैबलेन के लिए प्रदान करता है:

       table_name.column_name  -- notice the dot
   

6. अपवाद:

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

     • ध्यान दें कि यह एक उपसर्ग के रूप में उपयोग किया जाने वाला एक तालिका नाम नहीं है, लेकिन कुंजी के घटक के लिए एक उचित वर्णनात्मक नाम है: user_idवह स्तंभ है जो किसी उपयोगकर्ता की पहचान करता idहै, userतालिका का नहीं।
       • (रिकॉर्ड फाइलिंग सिस्टम में पाठ्यक्रम को छोड़कर, जहां फाइलें सरोगेट्स द्वारा एक्सेस की जाती हैं और कोई संबंधपरक कुंजी नहीं हैं, वहां वे एक और एक ही चीज हैं)।
     • हमेशा एक ही नाम का उपयोग कुंजी कॉलम के लिए करें जहां पीके को एफके के रूप में (माइग्रेट) किया जाता है।
     • इसलिए user_productतालिका user_idमें इसके पीके के एक घटक के रूप में होगा (user_id, product_no)।
     • जब आप कोडिंग शुरू करेंगे तो इसकी प्रासंगिकता स्पष्ट हो जाएगी। सबसे पहले, idकई तालिकाओं के साथ, SQL कोडिंग में मिलाना आसान है। दूसरा, किसी और को जो शुरुआती कोडर का कोई पता नहीं है कि वह क्या करने की कोशिश कर रहा था। दोनों को रोकने के लिए आसान है, अगर कुंजी स्तंभ ऊपर के रूप में माना जाता है।

   • दूसरा अपवाद वह है जहां एक से अधिक FK समान पेरेंट टेबल टेबल का संदर्भ देते हैं, जो बच्चे में किया जाता है। संबंधपरक मॉडल के अनुसार , अर्थ या उपयोग को अलग करने के लिए भूमिका नाम का उपयोग करें, जैसे। AssemblyCodeऔर ComponentCodeदो के लिए PartCodes। और उस मामले में, उनमें से एक के लिए उदासीन का उपयोग न करें PartCode। सटीक होना।

     Diagram_E

7. उपसर्ग
   जहाँ आपके पास 100 से अधिक तालिकाएँ हैं, विषय क्षेत्र के साथ तालिका नामों को उपसर्ग करें:

   REF_
OE_ऑर्डर एंट्री क्लस्टर के लिए संदर्भ तालिका के लिए, आदि।

   केवल भौतिक स्तर पर, तार्किक नहीं (यह मॉडल को अव्यवस्थित करता है)।

8. प्रत्यय
   कभी भी तालिकाओं पर प्रत्ययों का उपयोग न करें, और हमेशा हर चीज पर प्रत्ययों का उपयोग करें। डेटाबेस के तार्किक, सामान्य उपयोग में इसका मतलब है कि कोई अंडरस्कोर नहीं हैं; लेकिन प्रशासनिक पक्ष पर, एक विभाजक के रूप में अंडरस्कोर का उपयोग किया जाता है:

   _Vदेखें ( TableNameसामने मुख्य के साथ )
   _fkविदेशी कुंजी (बाधा नाम, स्तंभ नाम नहीं)
   _cacकैश
   _segसेगमेंट
   _trलेनदेन (संग्रहीत या फ़ंक्शन)
   _fnफ़ंक्शन (गैर-लेन-देन), आदि।

   प्रारूप तालिका या FK नाम, एक अंडरस्कोर, और एक्शन नाम, एक अंडरस्कोर और अंत में प्रत्यय है।

   यह वास्तव में महत्वपूर्ण है क्योंकि जब सर्वर आपको एक त्रुटि संदेश देता है:

   ____blah blah blah error on object_name

   आप वास्तव में जानते हैं कि किस वस्तु का उल्लंघन किया गया था, और वह क्या करने की कोशिश कर रही थी:

   ____blah blah blah error on Customer_Add_tr

9. विदेशी कुंजी (बाधा, स्तंभ नहीं)। एक FK के लिए सबसे अच्छा नामकरण Verb Phrase ("प्रत्येक" और कार्डिनलिटी को घटाता है) का उपयोग करना है।

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

   Parent_Child_fkअनुक्रम का उपयोग करें , ऐसा नहीं Child_Parent_fkहै क्योंकि (ए) यह सही प्रकार के क्रम में दिखाई देता है जब आप उन्हें ढूंढ रहे हैं और (बी) हम हमेशा बच्चे को शामिल करते हैं, जो हम अनुमान लगा रहे हैं, वह कौन सा है। त्रुटि संदेश तब आनंदमय है:

   ____ Foreign key violation on Vendor_Offers_PartVendor_fk।

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

10. संकेत विशेष हैं, इसलिए उनके पास अपने स्वयं के नामकरण सम्मेलन है, जो क्रम में बना है , प्रत्येक वर्ण स्थिति 1 से 3 तक है:

    Uअनोखा, या _गैर-अद्वितीय
    Cक्लस्टर के लिए, या _गैर-क्लस्टर
    _विभाजक के लिए

    शेष के लिए:

    • यदि कुंजी एक कॉलम या बहुत कम कॉलम है:
      ____ColumnNames

    • यदि कुंजी कुछ स्तंभों से अधिक है:
      ____ PKप्राथमिक कुंजी (प्रति मॉडल के रूप में)
      ____ AK[*n*]वैकल्पिक कुंजी (IDEF1X शब्द)

    ध्यान दें कि सूचकांक नाम में तालिका नाम की आवश्यकता नहीं है, क्योंकि यह हमेशा के रूप में दिखाता हैtable_name.index_name.

    तो जब Customer.UC_CustomerIdया Product.U__AKएक त्रुटि संदेश में प्रकट होता है, तो यह आपको कुछ सार्थक बताता है। जब आप किसी तालिका पर सूचक देखते हैं, तो आप उन्हें आसानी से अलग कर सकते हैं।

11. किसी योग्य और पेशेवर को खोजें और उनका पालन करें। उनके डिजाइनों को देखें, और उनके द्वारा उपयोग किए जाने वाले नामकरण सम्मेलनों का सावधानीपूर्वक अध्ययन करें। उन चीजों के बारे में उनसे विशिष्ट प्रश्न पूछें जिन्हें आप नहीं समझते हैं। इसके विपरीत, ऐसे किसी भी व्यक्ति से नरक की तरह दौड़ें जो नामकरण परंपराओं या मानकों के लिए बहुत कम संबंध प्रदर्शित करता है। यहाँ कुछ आप शुरू करने के लिए है:

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

ऑर्डर-एंट्री और इन्वेंट्री मानक-मानक पते के साथ

PHP / MyNonSQL के लिए सरल अंतर-कार्यालय बुलेटिन प्रणाली

पूर्ण टेम्पोरल क्षमता के साथ सेंसर की निगरानी

सवालों के जवाब

^{टिप्पणी स्थान में इसका यथोचित उत्तर नहीं दिया जा सकता है।}

लैरी लस्टिग:
... यहां तक ​​कि सबसे तुच्छ उदाहरण से पता चलता है ...
यदि किसी ग्राहक के पास शून्य से कई उत्पाद हैं और एक उत्पाद में एक से कई घटक हैं और एक घटक में एक से कई आपूर्तिकर्ता हैं और एक आपूर्तिकर्ता शून्य बेचता है -कई घटकों और एक SalesRep के पास एक से कई ग्राहक होते हैं जो "प्राकृतिक" नाम रखते हैं जो ग्राहक, उत्पाद, घटक और आपूर्तिकर्ता की तालिकाओं को कहते हैं?

आपकी टिप्पणी में दो प्रमुख समस्याएं हैं:

1. आप अपने उदाहरण को "सबसे तुच्छ" घोषित करते हैं, हालांकि, यह कुछ भी है लेकिन उस तरह के विरोधाभास के साथ, यदि आप गंभीर रूप से सक्षम हैं, तो मैं अनिश्चित हूं।

2. उस "तुच्छ" अटकलें में कई सकल सामान्यीकरण (डीबी डिज़ाइन) त्रुटियां हैं।

   • जब तक आप उन को ठीक नहीं करते, वे अप्राकृतिक और असामान्य हैं, और उनका कोई मतलब नहीं है। आप उन्हें असामान्य नाम, असामान्य 2, आदि नाम दे सकते हैं।

   • आपके पास "आपूर्तिकर्ता" हैं जो कुछ भी आपूर्ति नहीं करते हैं; परिपत्र संदर्भ (अवैध, और अनावश्यक); बिना किसी व्यावसायिक उपकरण (जैसे इनवॉइस या सेल्सऑडर) के बिना उत्पादों को खरीदने वाले ग्राहक खरीद के लिए एक आधार के रूप में (या ग्राहकों के अपने "उत्पाद?"); अनसुलझे कई-से-कई रिश्ते; आदि।

   • एक बार जब इसे सामान्यीकृत किया जाता है, और आवश्यक तालिकाओं की पहचान की जाती है, तो उनके नाम स्पष्ट हो जाएंगे। सहज रूप में।

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

• मैं मानूंगा कि यदि उत्पाद घटकों से बना है, तो उत्पाद एक विधानसभा है, और घटकों का उपयोग एक से अधिक विधानसभा में किया जाता है।

• इसके अलावा, चूंकि "आपूर्तिकर्ता शून्य-से-कई घटकों को बेचता है", कि वे उत्पादों या विधानसभाओं को नहीं बेचते हैं, वे केवल घटक बेचते हैं।

अटकलें बनाम सामान्यीकृत मॉडल

यदि आप जागरूक नहीं हैं, तो वर्ग कोनों (स्वतंत्र) और गोल कोनों (डिपेंडेंट) के बीच का अंतर महत्वपूर्ण है, कृपया आईडीईएफ 1 एक्स नोटेशन लिंक देखें। इसी तरह धराशायी लाइनों (पहचानने) बनाम धराशायी लाइनों (गैर-पहचान)।

... "नेचुरल" नाम ग्राहकों, उत्पादों, घटकों और आपूर्तिकर्ताओं को रखने वाली तालिकाओं के नाम क्या हैं?

• ग्राहक
• उत्पाद
• घटक (या, असेंबलीकम्पोनेंट, उन लोगों के लिए जो महसूस करते हैं कि एक तथ्य दूसरे की पहचान करता है)
• प्रदायक

अब जब मैंने तालिकाओं को हल कर लिया है, तो मैं आपकी समस्या को नहीं समझता। शायद आप एक विशिष्ट प्रश्न पोस्ट कर सकते हैं ।

वोटकॉफी:
आप अपने उदाहरण में पोस्ट किए गए परिदृश्य रॉनिस को कैसे संभाल रहे हैं जहां 2 टेबल (user_likes_product, user_bought_product) के बीच कई संबंध मौजूद हैं? मुझे गलतफहमी हो सकती है, लेकिन ऐसा लगता है कि आपके द्वारा दिए गए सम्मेलन का उपयोग करके डुप्लिकेट तालिका नामों में परिणाम होगा।

मान लें कि कोई सामान्यीकरण त्रुटियां नहीं हैं, User likes Productएक विधेय है, तालिका नहीं है। उन्हें भ्रमित मत करो। मेरे उत्तर का संदर्भ लें, जहां यह विषय, क्रिया, और विधेय से संबंधित है, और लैरी के तुरंत ऊपर मेरी प्रतिक्रिया।

• प्रत्येक तालिका में तथ्यों का एक समूह होता है (प्रत्येक पंक्ति एक तथ्य है)। विधेय (या प्रस्ताव), तथ्य नहीं हैं, वे सच हो सकते हैं या नहीं भी हो सकते हैं।

  • रिलेशनल मॉडल सबसे पहले आदेश विधेय पथरी (सामान्यतः प्रथम आदेश तर्क के रूप में जाना जाता है) पर आधारित है। एक विधेय सरल, सटीक अंग्रेजी में एकल-खंड वाक्य है, जो सही या गलत का मूल्यांकन करता है।

  • इसके अलावा, प्रत्येक तालिका प्रतिनिधित्व करती है, या एक नहीं , कई Predicates का कार्यान्वयन है ।

• एक क्वेरी एक Predicate का परीक्षण है (या एक साथ कई प्रेडिकेट्स, एक साथ जंजीर) जिसके परिणामस्वरूप सच (तथ्य मौजूद है) या गलत (तथ्य मौजूद नहीं है)।

• इस प्रकार, तालिकाओं के नाम, मेरे उत्तर (नामकरण परंपराओं) में विस्तृत होने चाहिए, पंक्ति के लिए, तथ्य, और विधेयकों को प्रलेखित किया जाना चाहिए (हर तरह से, यह डेटाबेस प्रलेखन का हिस्सा है), लेकिन Predicates की एक अलग सूची के रूप में ।

• यह एक सुझाव नहीं है कि वे महत्वपूर्ण नहीं हैं। वे बहुत महत्वपूर्ण हैं, लेकिन मैं यहां नहीं लिखूंगा।

• जल्दी से, फिर। चूंकि रिलेशनल मॉडल FOPC पर स्थापित है, इसलिए पूरे डेटाबेस को FOPC घोषणाओं का एक सेट, Predicates का एक सेट कहा जा सकता है। लेकिन (ए) कई प्रकार के Predicates हैं, और (b) एक टेबल एक Predicate का प्रतिनिधित्व नहीं करता है (यह कई Predicates का भौतिक कार्यान्वयन है , और विभिन्न प्रकार के Predicates का)।

• इसलिए "" जो "प्रतिनिधित्व करता है" के लिए तालिका का नामकरण एक बेतुका अवधारणा है।

• "सिद्धांतकारों" को केवल कुछ ही विधेयकों के बारे में पता है, वे यह नहीं समझते हैं कि चूंकि RM को FOL पर स्थापित किया गया था, इसलिए पूरा डेटाबेस Predicates और विभिन्न प्रकारों का एक सेट है।

  • और निश्चित रूप से, वे उन लोगों में से बेतुका चुनते हैं जिन्हें वे जानते हैं EXISTING_PERSON:; PERSON_IS_CALLED। यदि यह इतना दुखी नहीं होता, तो यह प्रफुल्लित करने वाला होता।

  • यह भी ध्यान दें कि मानक या परमाणु तालिका नाम (पंक्ति का नामकरण) सभी क्रियाओं के लिए शानदार ढंग से काम करता है (तालिका से जुड़ी सभी Predicates सहित)। इसके विपरीत, मुहावरा "तालिका विधेय का प्रतिनिधित्व करती है" नाम नहीं हो सकता। जो "सिद्धांतकारों" के लिए ठीक है, जो प्रेडिकेट्स के बारे में बहुत कम समझते हैं, लेकिन मंदबुद्धि हैं।

• डेटा मॉडल के लिए प्रासंगिक हैं, जो मॉडल में व्यक्त किए गए हैं, वे दो आदेशों के हैं।

  1. Unary Predicate
     पहला सेट आरेखीय है , पाठ नहीं: संकेतन स्वयं । इनमें विभिन्न अस्तित्व शामिल हैं; बाधा उन्मुख; और विवरणक (गुण) विधेय।

     • बेशक, इसका मतलब है कि केवल वे जो मानक डेटा मॉडल को 'पढ़' सकते हैं, वे उन विधेयकों को पढ़ सकते हैं। यही कारण है कि "सिद्धांतवादी", जो अपनी पाठ-मात्र मानसिकता से बुरी तरह से अपंग हैं, डेटा मॉडल नहीं पढ़ सकते हैं, इसलिए वे अपने पूर्व-1984 के पाठ-मात्र मानसिकता से चिपके रहते हैं।

  2. बाइनरी प्रेडिक्टेट
     दूसरा सेट वह है जो तथ्यों के बीच संबंध बनाता है । यह संबंध रेखा है। Verb Phrase (ऊपर दिया गया) Predicate, प्रस्ताव को पहचानता है , जिसे लागू किया गया है (जिसे क्वेरी के साथ परीक्षण किया जा सकता है)। इससे अधिक स्पष्ट नहीं हो सकता है।

     • इसलिए, जो मानक डेटा मॉडल में धाराप्रवाह है, सभी प्रासंगिक जो प्रासंगिक हैं , मॉडल में प्रलेखित हैं। उन्हें Predicates (लेकिन उपयोगकर्ता, जो डेटा मॉडल से सब कुछ नहीं पढ़ सकते हैं, करते हैं) की एक अलग सूची की आवश्यकता नहीं है।)

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

इसलिए दो माता-पिता की तालिकाओं के बीच एक से अधिक बाल तालिका की घटना कोई समस्या नहीं है, बस उन्हें नाम दें जैसे कि अस्तित्ववादी तथ्य उनकी सामग्री को पुन: प्रस्तुत करते हैं, और नामों को सामान्य करते हैं।

एसोसिएटिव टेबल्स के लिए रिश्तों के नाम के लिए मैंने वर्ब वाक्यांशों के लिए जो नियम दिए थे, वे यहां लागू होते हैं। सारांश में दी गई सभी बिंदुओं को शामिल करते हुए, यहाँ एक बनाम बनाम तालिका चर्चा है।

विधेय और कैसे के समुचित उपयोग के लिए उन्हें (जो यहाँ टिप्पणी करने के लिए जवाब की है कि काफी एक अलग संदर्भ है) का उपयोग करने के फिर से एक अच्छा संक्षिप्त विवरण के लिए देखें: इस जवाब है, और के लिए नीचे स्क्रॉल विधेय अनुभाग।

---

चार्ल्स बर्न्स:
अनुक्रम से, मेरा मतलब था कि ओरेकल-शैली की वस्तु विशुद्ध रूप से एक संख्या और उसके अगले को कुछ नियम के अनुसार उपयोग करती थी (उदाहरण के लिए "1 जोड़ें")। चूंकि ओरेकल में ऑटो-आईडी तालिकाओं का अभाव है, इसलिए मेरा विशिष्ट उपयोग तालिका पीके के लिए अद्वितीय आईडी तैयार करना है। INSERT INTO foo (id, somedata) VALUES (foo_s.nextval, "data" ...)

ठीक है, जिसे हम कुंजी या नेक्स्ट टेबल कहते हैं। इसे ऐसे नाम दें। यदि आपके पास विषय है, तो यह इंगित करने के लिए COM_NextKey का उपयोग करें कि यह डेटाबेस में सामान्य है।

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

Comments

बहुत बढ़िया सफाई, धन्यवाद। सभी अच्छी टिप्पणियाँ (तारांकित, वोट अप) भी गई हैं। ओह ठीक है, इसे समय दें, और वे वापस आ जाएंगे।

— प्रदर्शन

पोस्ट पर 76 टिप्पणियां थीं, लायक कुछ भी जवाब में संपादित किया जाना चाहिए था, क्योंकि उन सभी में से कुछ भी निकालना लगभग असंभव होगा।

— टैरिन

@PerformanceDBA। कोई टिप्पणी जैसे कि "यह इस तरह का उत्तर है जो मैं चाहता हूं कि मैं सिर्फ स्टार बन सकता हूं" को उत्तर में नहीं ले जाना चाहिए । जिस तरह की चीजों को शामिल किया जाना चाहिए, वे स्पष्टीकरण के लिए पूछने या त्रुटियों को इंगित करने वाली टिप्पणियों के उत्तर हैं।

— ChrisF

@ChrisF। (ए) स्पष्टीकरण के लिए बहुत बहुत धन्यवाद, मैं पिछले मध्यस्थ कार्यों को समझ नहीं पाया। (b) क्या आपके लिए प्रश्न को दोबारा खोलना संभव है, इसे बंद करने का प्रयास स्पष्ट रूप से एक त्रुटि है (प्रश्न पर मेरी टिप्पणी देखें)। अन्यथा SO अच्छे प्रश्नों / उत्तरों को खोता रहता है, और नए उनकी जगह लेते हैं। सहायता में कहा गया है, "हमें महान उत्तर खोना पसंद नहीं है!"। धन्यवाद।

— प्रदर्शन 13

क्या आप इनमें से किसी भी "मानक" का संदर्भ दे सकते हैं? वर्तमान में यह केवल एक बहुत अच्छी तरह से लिखित व्यक्तिगत राय है।

— शेन कोर्ट्रेल

Answer 2

एकवचन बनाम बहुवचन: एक उठाओ और इसके साथ रहो।

स्तंभों को उपसर्ग / प्रत्यय / प्रत्यय या वैसे भी इस तथ्य के संदर्भ में तय नहीं किया जाना चाहिए कि यह एक स्तंभ है। वही टेबल के लिए जाता है। तालिकाओं को नाम न दें EMPLOYEE_T या TBL_EMPLOYEES क्योंकि दूसरा इसे एक दृश्य के साथ बदल दिया जाता है, चीजें वास्तव में भ्रमित हो जाती हैं।

नामों में टाइप जानकारी एम्बेड न करें, जैसे कि "vc_firstname" varchar के लिए, या "flavour_enum"। इसके अलावा कॉलम नामों में अड़चनें न डालें, जैसे कि "डिपार्टमेंट_फेक" या "एंप्लॉयी_पीके"।

वास्तव में, * फिक्स मैं के बारे में सोच सकते हैं, के बारे में केवल अच्छी बात यह है कि आप की तरह आरक्षित शब्द का उपयोग कर सकते है where_t, tbl_order, user_vw। बेशक, उन उदाहरणों में, बहुवचन का उपयोग करने से समस्या हल हो गई होगी :)

सभी कुंजी "आईडी" का नाम न दें। एक ही चीज़ को संदर्भित करने वाली कुंजी, सभी तालिकाओं में समान नाम होनी चाहिए। उपयोगकर्ता आईडी कॉलम को उपयोगकर्ता तालिका में USER_ID कहा जा सकता है और उपयोगकर्ता को संदर्भित करने वाली सभी तालिकाएं। केवल एक बार इसका नाम बदल दिया गया है, जब अलग-अलग उपयोगकर्ता विभिन्न भूमिकाएँ निभा रहे हैं, जैसे संदेश (प्रेषक_सुपर_ रिसीवर, रिसीवर_युसर_िड)। यह वास्तव में बड़े प्रश्नों से निपटने में मदद करता है।

CaSe के बारे में:

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

सामान्य तौर पर संदर्भित तालिकाओं के नामों के बजाय इसका वर्णन करने के लिए "मैपिंग टेबल" नाम देना बेहतर होता है। एक उपयोगकर्ता उत्पादों के लिए संबंधों के किसी भी संख्या हो सकती है: user_likes_product, user_bought_product, user_wants_to_buy_product।

Comments

मैं अंडरस्कोर देखना पसंद करता हूं। लेकिन मैं ऊंट टाइप करना पसंद करता हूं। अंडरस्कोर के बारे में कुछ है ... चाहे मैं कितना भी अभ्यास करूं, मैं कीबोर्ड को देखने और देखने के लिए मजबूर हूं।

— लॉर्ड टाइडस

@Ronnis, क्या आप कृपया "" सभी कुंजियों का नाम न बताएं "ID" बताएं। कुंजी एक ही चीज़ का उल्लेख करते हुए, सभी तालिकाओं में समान नाम होना चाहिए? ""?

— ट्रैविस

@Travis, यकीन है कि मैं कर सकता था, लेकिन वह पूरा पैराग्राफ एक विस्तार है?

— रॉननिस

मुझे लगता है कि मेरा प्रश्न केवल ( {table_name}_idबल्कि गैर-विभेदित भूमिका) सिंथेटिक प्राथमिक कुंजी के नामकरण के लाभों के बारे में है id, क्योंकि स्तंभ को केवल एक गुणक के रूप में उपसर्गित तालिका नाम के साथ संदर्भित किया जाएगा, उदा table_name.id। संदर्भ के लिए, मैं एक पारिस्थितिक तंत्र में काम कर रहा हूं जहां फॉर्म table_a JOIN table_b ON table_b_id_columnका सिंटैक्स शामिल नहीं है; मुझे करना है table_a JOIN table_b ON table_b.id_column = table_a.table_b_id_column।

— ट्रैविस

मेरे लिए यह स्पष्टता और तार्किक डेटा मॉडल के बारे में है। यदि मैं USER_ID और Company_ID के लिए एक संख्या अनुक्रम का उपयोग करता हूं, तो उनमें से कुछ मूल्य निश्चित रूप से समान होंगे। लेकिन USER_ID से 123, Company_ID से 123 के समान नहीं है, क्योंकि उनके मूल्य अंतर डोमेन से तैयार किए गए हैं । इस तरह यह उन्हें अलग नाम देने के लिए समझ में आता है।

— रॉननिस

Answer 3

एकवचन बनाम बहुवचन के बारे में कोई 'सही' नहीं है - यह ज्यादातर स्वाद का मामला है।

यह आपके ध्यान में भाग पर निर्भर करता है। यदि आप तालिका को एक इकाई मानते हैं, तो यह 'बहुवचन' रखता है (क्योंकि यह कई पंक्तियों को रखता है - इसलिए बहुवचन नाम उपयुक्त है)। यदि आप तालिका में एक पंक्ति की पहचान के रूप में तालिका के नाम के बारे में सोचते हैं, तो आप 'एकवचन' पसंद करेंगे। इसका मतलब है कि आपकी SQL को टेबल से एक पंक्ति पर काम करने के बारे में सोचा जाएगा। यह ठीक है, हालांकि यह आमतौर पर एक ओवरसाइम्प्लिफिकेशन है; SQL सेट (कम या ज्यादा) पर काम करता है। हालांकि, हम इस प्रश्न के उत्तर के लिए एकवचन के साथ जा सकते हैं।

1. चूंकि आपको संभवतः एक टेबल 'उपयोगकर्ता', एक और 'उत्पाद', और तीसरा उपयोगकर्ताओं को उत्पादों से जोड़ने की आवश्यकता होगी, फिर आपको एक तालिका 'user_product' की आवश्यकता होगी।

2. चूंकि विवरण किसी उत्पाद पर लागू होता है, इसलिए आप 'product_description' का उपयोग करेंगे। जब तक प्रत्येक उपयोगकर्ता अपने लिए प्रत्येक उत्पाद का नाम न ले ...

3. 'User_product' तालिका उत्पाद ID और उपयोगकर्ता ID वाली तालिका का उदाहरण है (या हो सकता है) और बहुत कुछ नहीं। आप दो-विशेषता तालिकाओं को समान रूप से नाम देते हैं: 'user_stuff'। 'Rel_' जैसे सजावटी उपसर्ग वास्तव में मदद नहीं करते हैं। आप कुछ लोगों को उदाहरण के लिए, प्रत्येक तालिका नाम के सामने 't_' का उपयोग करते देखेंगे। वह बहुत मदद नहीं है।

Comments

जब आप कहते हैं "और उपयोगकर्ताओं को जोड़ने के लिए तीसरा"। क्या आपका मतलब तीसरी तालिका से है? कई संबंध (उपयोगकर्ताओं के पास कई उत्पाद हैं) के लिए एक होने पर मुझे तीसरी तालिका की आवश्यकता क्यों होनी चाहिए? क्या आप उपयोगकर्ताप्रॉडक्ट के बजाय User_product का उपयोग करने की अनुशंसा करेंगे?

— एंड्रियास

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

— जोनाथन लेफ़लर

क्षमा करें, मुझे उत्पादों की तुलना में बेहतर उदाहरण का उपयोग करना चाहिए था। मेरा मतलब इस तरह से था कि उत्पाद एक उपयोगकर्ता के लिए अद्वितीय है। तो इस मंजूरी के साथ, मुझे लगता है कि वर्णन तालिका "user_product_description" होनी चाहिए क्योंकि यह उपयोगकर्ता / उत्पाद के लिए भी अद्वितीय है। मुझे पता है कि मैंने उत्पादों के साथ क्या भयानक उदाहरण लिया है :) धन्यवाद

— एंड्रियास

@ संकेत: अक्सर अच्छे उदाहरणों को चुनना मुश्किल होता है, और समस्याओं में से एक लोगों की पूर्व धारणा है कि उत्पाद तालिका में क्या होगा। हालाँकि, आपका स्पष्टीकरण, फिर 'उपयोगकर्ता', 'user_product', और 'user_product_description' तालिका नामों के रूप में उपयुक्त लगता है।

— जोनाथन लेफ्लर

Answer 4

जब तक वे लगातार उपयोग किए जाते हैं, तब तक खराब नहीं होते - लेकिन एकवचन मेरी प्राथमिकता है।

जब तक आप कई-से-कई संबंधों को रेखांकित नहीं करना चाहते, मैं अंडरस्कोर के साथ दूर हो जाऊंगा; और एक प्रारंभिक पूंजी का उपयोग करें क्योंकि यह ओआरएम में चीजों को अलग करने में मदद करता है।

लेकिन कई नामकरण परंपराएं हैं, इसलिए यदि आप अंडरस्कोर का उपयोग करना चाहते हैं तो ठीक है जब तक कि यह लगातार किया जाता है।

इसलिए:

User

UserProduct (it is a users products after all)

यदि केवल एक उपयोगकर्ता के पास कोई उत्पाद हो सकता है

UserProductDescription

लेकिन अगर उत्पाद उपयोगकर्ताओं द्वारा साझा किया जाता है:

ProductDescription

यदि आप कई-कई रिश्तों के लिए अपने अंडरस्कोर बचाते हैं, तो आप कुछ ऐसा कर सकते हैं:

UserProduct_Stuff

उपयोगकर्ताप्रॉडक्ट और स्टफ के बीच एम-टू-एम बनाने के लिए - इस सवाल से निश्चित नहीं कि कई-से-कई आवश्यक हैं।

Comments

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

— एंड्रियास

@ और तालिका के लिए आपको ऊपरी मामले का उपयोग करने की आवश्यकता नहीं है, बस अलग-अलग शब्दों के पहले अक्षर को कैपिटलाइज़ करें।

— अमेलविन

Answer 5

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

आपके प्रश्न के बारे में, यदि 'उत्पाद' और 'उत्पाद विवरण' आपके मॉडल में एक पहचान (यानी संस्थाओं) के साथ अवधारणाएं हैं, तो मैं बस टेबल को 'उत्पाद' और 'उत्पाद विवरण' कहूंगा। कई-से-कई संबंधों को लागू करने के लिए उपयोग किए जाने वाले तालिकाओं के लिए मैं सबसे अधिक बार नामकरण सम्मेलन "साइडए 2 एसआईडीबी" का उपयोग करता हूं, उदाहरण के लिए "स्टूडेंटसकोर्स"।