क्या MongoDB में नाम संग्रह करने के लिए एक सम्मेलन है?


85

मैं जानना चाहूंगा कि क्या डेटाबेस संग्रह के लिए एक सम्मेलन है जैसे:

PageVisitया page_visit

क्या इन सूचनाओं के लिए कोई फायदे / नुकसान हैं?


जवाबों:


90

सामान्य सम्मेलन हैं:

  • लोअरकेस नाम : यह केस सेंसिटिविटी मुद्दों से बचा जाता है, क्योंकि MongoDB संग्रह नाम केस संवेदनशील होते हैं
  • बहुवचन : बहुवचन के रूप में किसी चीज़ के संग्रह को लेबल करने के लिए अधिक स्पष्ट है, जैसे "फ़ाइल" के बजाय "फाइलें"
  • कोई शब्द विभाजक नहीं : उन मुद्दों से बचता है जहां अलग-अलग लोग (गलत तरीके से) अलग शब्द (उपयोगकर्ता नाम <-> user_name, first_name <-> firstname)। यह एक इधर-उधर के कुछ लोगों के अनुसार बहस के लिए है, लेकिन तर्क यह प्रदान करता है कि संग्रह के नाम को अलग-थलग कर दिया जाए, मुझे नहीं लगता कि यह होना चाहिए;) यदि आप अपने आप को अपने संग्रह के नाम की पठनीयता में सुधार कर पाते हैं तो अंडरस्कोर या कैमल कैसिंग जोड़कर संग्रह का नाम संभवतः बहुत लंबा है या उपयुक्त अवधियों का उपयोग करना चाहिए जो संग्रह वर्गीकरण के लिए मानक है।
  • उच्च विवरण संग्रह के लिए डॉट संकेतन : कुछ संकेत देता है कि संग्रह कैसे संबंधित हैं। उदाहरण के लिए, आप यथोचित रूप से सुनिश्चित कर सकते हैं कि आप "users.pagevisits" को हटा सकते हैं यदि आपने "उपयोगकर्ताओं" को हटा दिया, बशर्ते कि स्कीमा तैयार करने वाले लोगों ने अच्छा काम किया हो;)

उदाहरण:

users
pagevisits
users.pagevisits

फ़ील्ड नेम कन्वेंशन (चाहिए) कुछ उसी तर्क का पालन करते हैं, हालांकि ऊंट आवरण उन काफी आम है।


33
मैं पूरी तरह से "नो वर्ड सेपरेटर्स" चीज के लिए आपसे असहमत होने जा रहा हूं, खासकर यदि आप पायनियर के साथ मोंगोबडी का उपयोग कर रहे हैं। रिक्त स्थान के बजाय अंडरस्कोर अत्यधिक पठनीय है, जो कोड, स्कीमा और पसंद के सबसे वांछनीय गुणों में से एक है।
नूह मैकलेरिथ

2
विषयवस्तु एक सुंदर चीज है;) यदि आप स्वयं को इतने सारे शब्दों के साथ फ़ील्ड या संग्रह नामों के साथ पाते हैं, जो अंडरस्कोर कोड की पठनीयता में सुधार करते हैं, तो आपको संभवतः पूरे वास्तव में नाम पर पुनर्विचार करना चाहिए। प्रत्येक अपने स्वयं के पाठ्यक्रम के लिए। मैं संभव विसंगतियों के मुद्दे का पता लगाता हूं जो शब्दों में बहुत बड़े मुद्दे को अलग कर देते हैं। शब्द सेपरेटर का उपयोग नहीं करना अपेक्षाकृत भाषा अज्ञेय है। जहाँ आप अंडरस्कोर पसंद करते हैं एक जावा डेवलपर शायद ऊंटनी करना पसंद करेगा और यह जल्दबाज़ी में गड़बड़ हो जाता है।
रेमन वैन Vliet

7
बहुवचन के बजाय एकवचन अन्यथा यह बहुवचन में Pojos जैसी वस्तुओं के लिए मैप करता है और आप एक उपयोगकर्ता वर्ग के साथ समाप्त होता है! एक उपयोगकर्ता वर्ग के बजाय
ricardoespsanto

4
@ रेकी यह मैं मान गया हूं। आप जिस उत्तर का उल्लेख कर रहे हैं वह उन्हीं अवधारणाओं को मिश्रित कर रहा है जो हालांकि यहां मिश्रित हैं। संग्रह नामकरण इकाई बनाम नामकरण। कोई भी "ग्राहक" का उपयोग इकाई नाम के रूप में नहीं करेगा, क्योंकि उस उत्तर के लेखक का सुझाव है कि वे SQL तालिका नाम के रूप में ग्राहक का उपयोग कर सकते हैं। जैसा कि आप कहते हैं कि यह एक अत्यंत व्यक्तिपरक चर्चा है। जब तक यह एक पूरे कोडबेस के अनुरूप होता है तब तक बहुत अधिक समस्या नहीं होनी चाहिए।
रेमन वैन Vliet

3
मुझे लगता है कि एकवचन अधिक समझ में आता है, क्योंकि बहुवचन निहित है। और जैसा @Ricky कहता है, यह मानक बहुत पहले sql में स्थापित किया गया था। stackoverflow.com/questions/338156
भाप से चलने वाला

32

बस अपने संग्रह नामों में हाइफ़न का उपयोग करने से बचें।

और ऐसा केवल इसलिए है, क्योंकि यदि आप नीचे दिए गए दो कॉल्स का उपयोग करते हैं, तो पहला अमान्य जावास्क्रिप्ट है:

db.foo-bar.find();
db['foo-bar'].find();

वे दोनों कार्यात्मक रूप से समान हैं, लेकिन दूसरा टाइप करने के लिए थोड़ा अधिक कष्टप्रद है और टैब-पूर्ण नहीं है।

इसके अलावा, फायदे / नुकसान संग्रह के आपके उपयोग पर निर्भर करते हैं। सुसंगत होना अधिक महत्वपूर्ण है कि आप किस सम्मेलन का चयन करते हैं।


क्या :संग्रह नाम रखने के लिए मान्य हैं, जैसे foo:bar?
रफ़ियन

मोंगो के लिए कुछ भी मान्य है। जैसे db["\n"].insert({});- कोई त्रुटि नहीं। विचार करने वाली चीजें ज्यादातर आपके द्वारा उपयोग किए जा रहे ड्राइवर के साथ सुविधा होती हैं।
AD7six

1
यह विंडोज़ पर 2.2 में बदल गया: / \। * * <>: | - अब मान्य नहीं हैं - देखें docs.mongodb.org/manual/release-notes/2.2/……
toong

5
@toong, यह डेटाबेस के नाम के लिए है , संग्रह के लिए नहीं।
बोरिसऑकुंस्की

19

में http://docs.mongodb.org/manual/reference/limits/ , मैनुअल कहा गया है कि संग्रह के नाम एक साथ शुरू करना चाहिए अंडरस्कोर ( '_') या एक पत्र चरित्र, और नहीं कर सकते हैं:

  • $ होते हैं।
  • एक रिक्त स्ट्रिंग (उदाहरण के लिए "") बनें।
  • अशक्त चरित्र होते हैं।
  • सिस्टम से शुरू करें। उपसर्ग। (आंतरिक उपयोग के लिए आरक्षित।)

हालांकि, यदि आप नियम का पालन करते हैं और '_' के साथ शुरुआती अक्षर के रूप में एक संग्रह बनाते हैं, जैसे कि "_TWII", तो आप उस समय परेशानी का सामना करेंगे जब आप संग्रह को छोड़ना चाहते हैं। नीचे दिए गए परीक्षण और इसे ठीक करने का तरीका देखें। संग्रह '_TWII' का निर्माण 'लोगों के db' के तहत किया गया था।

> show collections
_TWII
employees
system.indexes
> db._TWII.drop()
2015-02-19T16:34:56.738-0800 TypeError: Cannot call method 'drop' of undefined

> use admin
switched to db admin

> db.runCommand({renameCollection:"people._TWII",to:"people.TWII"})
{ "ok" : 1 }
> use people
switched to db people
> show collections
TWII
employees
system.indexes
> db.TWII.drop()
true
> show collections
employees
system.indexes
> 

'लोगों' डीबी के तहत _TWII संग्रह को हटाने के लिए एक शॉर्ट-कट:

> db.createCollection('^TWII')
{ "ok" : 1 }
> db.getCollection('^TWII').drop()
true

0

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

चूंकि डेटाबेस के नाम MongoDB में असंवेदनशील हैं, इसलिए डेटाबेस के नाम केवल वर्णों के मामले से भिन्न नहीं हो सकते।

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

उदाहरण के लिए, यदि आपके पास "पाठ्यक्रम" नाम का एक संग्रह है, तो यहां बताया गया है कि आपको अपने मॉडल की संरचना करने की आवश्यकता है:

const LawModel = mongoose.model(
  "course",
  new mongoose.Schema({
    id: String,
    name: String,

  }),

ध्यान दें कि "पाठ्यक्रम" कैसे विलक्षण है? Mongoose इसे बहुवचन देगा इसलिए आप एक खाली सरणी "[]" देख सकते हैं। -> आप एक अस्पष्ट संग्रह को क्वेरी कर रहे हैं।

अपने मॉडल का नाम बदलने और समायोजित करने का प्रयास करें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.