কাউচডিবি ডকুমেন্টস মডেলিংয়ের জন্য নীতিমালা

Question

আমার একটি প্রশ্ন রয়েছে যা আমি কিছু সময়ের জন্য উত্তর দেওয়ার চেষ্টা করছি তবে বুঝতে পারি না:

আপনি কাউচডিবি নথিগুলি কীভাবে ডিজাইন করবেন বা ভাগ করবেন?

উদাহরণস্বরূপ একটি ব্লগ পোস্ট নিন।

এটি করার আধা "সম্পর্কযুক্ত" উপায়টি হ'ল কয়েকটি বস্তু তৈরি করা:

• পোস্ট
• ব্যবহারকারী
• মন্তব্য
• ট্যাগ
• টুকিটাকি

এটি বোধগম্যতা তৈরি করে। তবে আমি একই জিনিসটি মডেল করার জন্য কাউচডিবি (সমস্ত কারণেই এটি দুর্দান্ত) ব্যবহার করার চেষ্টা করছি এবং এটি অত্যন্ত কঠিন।

সেখানে থাকা বেশিরভাগ ব্লগ পোস্ট আপনাকে কীভাবে এটি করতে হয় তার একটি সহজ উদাহরণ দেয়। তারা মূলত এটিকে একইভাবে ভাগ করে দেয় তবে বলে যে আপনি প্রতিটি নথিতে 'নির্বিচারে' বৈশিষ্ট্য যুক্ত করতে পারেন, এটি অবশ্যই দুর্দান্ত nice সুতরাং কাউচডিবিতে আপনার এমন কিছু থাকতে হবে:

• পোস্ট (দস্তাবেজের ট্যাগ এবং স্নিপেটস "সিউডো" মডেল সহ)
• মন্তব্য
• ব্যবহারকারী

কিছু লোক এমনকি এমনও বলতে পারে যে আপনি মন্তব্য এবং ব্যবহারকারীকে সেখানে ফেলে দিতে পারেন, তাই আপনার এটি থাকতে হবে:

post {
    id: 123412804910820
    title: "My Post"
    body: "Lots of Content"
    html: "<p>Lots of Content</p>"
    author: {
        name: "Lance"
        age: "23"
    }
    tags: ["sample", "post"]
    comments {
        comment {
            id: 93930414809
            body: "Interesting Post"
        } 
        comment {
            id: 19018301989
            body: "I agree"
        }
    }
}

এটি দেখতে খুব সুন্দর এবং সহজেই বোঝা যায়। আমি এটিও বুঝতে পারি যে আপনি কীভাবে এমন সমস্ত ভিউ লিখতে পারেন যা ব্যবহারকারীদের এবং ট্যাগগুলির সাথে একই মতামত মডেলগুলিতে মন্তব্য করার জন্য আপনার সমস্ত পোস্ট নথি থেকে কেবল মন্তব্যগুলি বের করেছিল।

তবে আমি মনে করি, "কেন কেবল আমার পুরো সাইটটিকে একটি ডকুমেন্টে রাখি না?":

site {
    domain: "www.blog.com"
    owner: "me"
    pages {
        page {
            title: "Blog"
            posts {
                post {
                    id: 123412804910820
                    title: "My Post"
                    body: "Lots of Content"
                    html: "<p>Lots of Content</p>"
                    author: {
                        name: "Lance"
                        age: "23"
                    }
                    tags: ["sample", "post"]
                    comments {
                        comment {
                            id: 93930414809
                            body: "Interesting Post"
                        } 
                        comment {
                            id: 19018301989
                            body: "I agree"
                        }
                    }
                }
                post {
                    id: 18091890192984
                    title: "Second Post"
                    ...
                }
            }
        }
    }
}

আপনি এটি দিয়ে যা চেয়েছিলেন তা সন্ধান করতে আপনি সহজেই মতামত তৈরি করতে পারেন।

তারপরে আমার কাছে প্রশ্নটি হ'ল আপনি কীভাবে নির্ধারণ করবেন যে দস্তাবেজটি কখন ছোট দস্তাবেজগুলিতে ভাগ করবেন, বা কখন নথিগুলির মধ্যে "সম্পর্ক" তৈরি করবেন?

আমি মনে করি এটি অনেক বেশি "অবজেক্ট ওরিয়েন্টেড", এবং মান অবজেক্টগুলিতে মানচিত্র করা আরও সহজ হবে, যদি এটি ভাগ করে দেওয়া হয়:

posts {
    post {
        id: 123412804910820
        title: "My Post"
        body: "Lots of Content"
        html: "<p>Lots of Content</p>"
        author_id: "Lance1231"
        tags: ["sample", "post"]
    }
}
authors {
    author {
        id: "Lance1231"
        name: "Lance"
        age: "23"
    }
}
comments {
    comment {
        id: "comment1"
        body: "Interesting Post"
        post_id: 123412804910820
    } 
    comment {
        id: "comment2"
        body: "I agree"
        post_id: 123412804910820
    }
}

... তবে তারপরে এটি আরও সম্পর্কিত সম্পর্কিত ডাটাবেসের মতো দেখতে শুরু হয়। এবং প্রায়শই আমি এমন কিছু উত্তরাধিকার করি যা "সম্পূর্ণ-সাইট-ইন-এ-ডকুমেন্ট" এর মতো লাগে, তাই সম্পর্কের সাথে এটির মডেল করা আরও কঠিন।

রিলেশনাল ডেটাবেস বনাম ডকুমেন্ট ডাটাবেসগুলি কীভাবে / কখন ব্যবহার করতে হয় সে সম্পর্কে আমি প্রচুর জিনিস পড়েছি, সুতরাং এটি এখানে মূল সমস্যা নয়। আমি আরও ভাবছি, কাউচডিবিতে ডেটা মডেলিংয়ের সময় প্রয়োগ করার জন্য একটি ভাল নিয়ম / নীতি কী।

আর একটি উদাহরণ এক্সএমএল ফাইল / ডেটা সহ। কিছু এক্সএমএল ডেটাতে 10+ স্তর গভীর নীচে বাসা বেঁধেছে এবং আমি একই চিত্রটি ব্যবহার করতে চাই (উদাহরণস্বরূপ রেলগুলিতে অ্যাজাক্স, বা ফ্লেক্স) যা আমি অ্যাক্টিভেকর্ড, কাউচরেস্ট বা অন্য কোনও অবজেক্ট রিলেশনাল ম্যাপার থেকে জেএসএন রেন্ডার করব। কখনও কখনও আমি বিশাল সাইটের এক্সএমএল ফাইলগুলি পাই যেগুলি পুরো সাইটের কাঠামো যেমন নীচের মত, এবং আমাকে এটি আমার মানচিত্রের অ্যাপ্লিকেশনটিতে মান অবজেক্টে ম্যাপ করা দরকার যাতে ডেটা সিরিয়ালাইজিং / ডিসস্রায়ালাইজিংয়ের অন্য কোনও পদ্ধতিতে আমাকে লিখতে না হয় :

<pages>
    <page>
        <subPages>
            <subPage>
                <images>
                    <image>
                        <url/>
                    </image>
                </images>
            </subPage>
        </subPages>
    </page>
</pages>

সুতরাং সাধারণ কাউচডিবি প্রশ্নগুলি হ'ল:

1. আপনার নথিগুলি (সম্পর্কগুলি ইত্যাদি) ভাগ করার জন্য আপনি কোন বিধি / নীতিগুলি ব্যবহার করেন?
2. পুরো সাইটটিকে একটি ডকুমেন্টে রেখে দেওয়া কি ঠিক আছে?
3. যদি তা হয়, তবে আপনি কীভাবে সুনির্দিষ্ট গভীরতার স্তরের (উপরের বৃহত জসন উদাহরণ, বা এক্সএমএল উদাহরণ) এর সাথে ডকুমেন্টগুলি সিরিয়ালাইজিং / ডিসরিয়ালাইজিং পরিচালনা করবেন?
4. বা আপনি এগুলিকে ভিওতে পরিণত করেন না, আপনি কি কেবল "" এগুলি অবজেক্ট-রিলেশনাল ম্যাপের জন্য খুব ঘৃণিত, তাই আমি কী কাঁচা এক্সএমএল / জেএসএন পদ্ধতি ব্যবহার করে এগুলি অ্যাক্সেস করব "ঠিক করেন?

আপনার সহায়তার জন্য অনেক ধন্যবাদ, কাউচডিবি দিয়ে আপনার ডেটা কীভাবে ভাগ করবেন সেই বিষয়টি আমার পক্ষে "এখন থেকে এটি করা উচিত" এইভাবে বলা আমার পক্ষে মুশকিল। আমি শীঘ্রই সেখানে পৌঁছানোর আশা করি।

আমি নিম্নলিখিত সাইটগুলি / প্রকল্পগুলি অধ্যয়ন করেছি।

1. কাউচডিবিতে হায়ারার্কিকাল ডেটা
2. কাউচডিবি উইকি
3. সোফা - কাউচডিবি অ্যাপ
4. কাউচডিবি সংজ্ঞা নির্দেশিকা
5. পিপকোড কাউচডিবি স্ক্রিনকাস্ট
6. CouchRest
7. কাউচডিবি পুনরায় পড়ুন

... তবে তারা এখনও এই প্রশ্নের উত্তর দেয়নি।

Comments

বাহ আপনি এখানে একটি সম্পূর্ণ রচনা লিখেছেন ... :-)

— Eero

ওহে, এটি একটি ভাল প্রশ্ন

— এলমার্কো

Answer 1

ইতিমধ্যে এটির জন্য দুর্দান্ত কিছু উত্তর রয়েছে, তবে আমি viatropos দ্বারা বর্ণিত মূল পরিস্থিতির সাথে কাজ করার জন্য বিকল্পগুলির মিশ্রণে আরও কয়েকটি সাম্প্রতিক কাউচডিবি বৈশিষ্ট্য যুক্ত করতে চেয়েছিলাম।

দস্তাবেজগুলিতে বিভক্ত করার মূল বিষয়টি হ'ল যেখানে বিবাদ থাকতে পারে (আগেই বলা হয়েছে)। আপনি সম্পূর্ণরূপে সম্পর্কিত নয় এমন আপডেটের জন্য একক সংশোধনী পাথর পাবেন (উদাহরণস্বরূপ পুরো সাইটের নথিতে একটি সংশোধন যোগ করার জন্য মন্তব্য সংযোজন করা হবে) আপনার একক দস্তাবেজে বৃহত্তর "জটযুক্ত" নথিগুলি একসাথে রাখা উচিত নয়। বিভিন্ন, ছোট নথির মধ্যে সম্পর্ক বা সংযোগ পরিচালনা করা প্রথমে বিভ্রান্তিকর হতে পারে তবে কাউচডিবি একক প্রতিক্রিয়াগুলিতে পৃথক পৃথক টুকরো একত্রিত করার জন্য বিভিন্ন বিকল্প সরবরাহ করে।

প্রথম বড়টি হল ভিউ কোলেশন। আপনি যখন মানচিত্র / ফলাফল হ্রাসের ফলাফলগুলিতে কী / মান জোড়গুলি নির্গমন করেন, তখন চাবিগুলি ইউটিএফ -8 কোলেশনের উপর ভিত্তি করে সাজানো হয় ("ক" "বি" এর আগে আসে)। এছাড়াও আপনি আপনার মানচিত্র থেকে আউটপুট জটিল কী / তাদেরকে JSON অ্যারে হিসাবে কমে যায়: ["a", "b", "c"]। এটি করার ফলে আপনি অ্যারে কীগুলি থেকে তৈরির ধরণের "গাছ" অন্তর্ভুক্ত করতে পারবেন। উপরে আপনার উদাহরণ ব্যবহার করে আমরা পোস্ট_আইডি আউটপুট করতে পারি, তারপরে আমরা যে ধরণের জিনিসটি উল্লেখ করছি তার আইডি (প্রয়োজনে)। তারপরে যদি আমরা রেফারেন্সযুক্ত ডকুমেন্টের আইডিটিকে প্রত্যাশিত মানের কোনও অবজেক্টে আউটপুট করি তবে আমরা সেই নথিগুলিকে মানচিত্রে অন্তর্ভুক্ত করতে / আউটপুট হ্রাস করতে 'অন্তর্ভুক্ত_ডোক্স' কোয়েরি প্যারাম ব্যবহার করতে পারি:

{"rows":[
  {"key":["123412804910820", "post"], "value":null},
  {"key":["123412804910820", "author", "Lance1231"], "value":{"_id":"Lance1231"}},
  {"key":["123412804910820", "comment", "comment1"], "value":{"_id":"comment1"}},
  {"key":["123412804910820", "comment", "comment2"], "value":{"_id":"comment2"}}
]}

'? অন্তর্ভুক্ত_ডোক্স = সত্য' দিয়ে একই দর্শনটির অনুরোধ করলে একটি 'ডক' কী যুক্ত হবে যা হয় 'মান' অবজেক্টে রেফারেন্সকৃত '_id' ব্যবহার করবে বা যদি এটি 'মান' অবজেক্টে উপস্থিত না থাকে, এটি ব্যবহার করবে যে দস্তাবেজ থেকে সারিটি নির্গত হয়েছিল তার '_id' (এই ক্ষেত্রে 'পোস্ট' নথি)। দয়া করে নোট করুন, এই ফলাফলগুলির মধ্যে একটি 'আইডি' ক্ষেত্র উল্লেখ করা হবে যা থেকে উত্সটি তৈরি হয়েছিল উত্স নথিকে fere আমি স্থান এবং পাঠ্যতার জন্য এটিকে রেখে দিয়েছি।

তারপরে আমরা 'স্টার্ট_কি' এবং 'এন্ড_কি' প্যারামিটারগুলি একক পোস্টের ডেটাতে ফলাফলগুলি ফিল্টার করতে ব্যবহার করতে পারি:

? শুরু_কি = ["123412804910820"] & শেষ_কি = ["123412804910820", {}, {}]

অথবা নির্দিষ্টভাবে নির্দিষ্টভাবে তালিকাটিও বের করে নিন:

? শুরু_কি = ["123412804910820", "মন্তব্য"] & শেষ_কি = ["123412804910820", "মন্তব্য", {}]

এই ক্যোয়ারী প্যারাম সংমিশ্রণগুলি সম্ভব কারণ একটি খালি অবজেক্ট (" {}") সর্বদা কোলেশনের নীচে থাকে এবং নাল বা "" সর্বদা শীর্ষে থাকে।

এই পরিস্থিতিতে কাউচডিবি থেকে দ্বিতীয় সহায়ক সংযোজন হ'ল _লিস্ট ফাংশন। এটি আপনাকে কোনও ধরণের টেম্প্লেটিং সিস্টেমের মাধ্যমে উপরের ফলাফলগুলি চালনার অনুমতি দেয় (যদি আপনি এইচটিএমএল, এক্সএমএল, সিএসভি বা যাই হোক না কেন ফিরে চান), অথবা আপনি যদি কোনও সম্পূর্ণ পোস্টের সামগ্রীর জন্য অনুরোধ করতে সক্ষম হন তবে একীভূত জেএসওএন কাঠামো আউটপুট দেয় (সহ) লেখক এবং মন্তব্য ডেটা) একক অনুরোধ সহ এবং একক জেএসওএন নথি হিসাবে প্রত্যাবর্তিত হয়েছে যা আপনার ক্লায়েন্ট-পাশ / ইউআই কোডের প্রয়োজনের সাথে মেলে। এটি করা আপনাকে পোস্টের ইউনিফাইড আউটপুট নথির অনুরোধ করতে অনুমতি দেবে:

/ ডিবি / _ ডিজাইন / অ্যাপ / _লিস্ট / পোস্ট / ইউনিফাইড ?? start_key = ["123412804910820"] & শেষ_কি = ["123412804910820", {}, {}] & অন্তর্ভুক্ত_ডোক্স = সত্য

আপনার _লিস্ট ফাংশন (এই ক্ষেত্রে "ইউনিফাইড" নামে পরিচিত) মানচিত্রের ফলাফলগুলি গ্রহণ করবে / হ্রাস করবে (এই ক্ষেত্রে "পোস্ট" নাম দেওয়া হয়েছে) এবং এটি একটি জাভাস্ক্রিপ্ট ফাংশন দিয়ে চালিত করবে যা আপনাকে লিখিত সামগ্রীতে টাইপ করে HTTP প্রতিক্রিয়া ফিরিয়ে দেবে send প্রয়োজন (জেএসএন, এইচটিএমএল, ইত্যাদি)।

এই জিনিসগুলির সংমিশ্রণে, আপনি আপডেটগুলি, দ্বন্দ্বগুলি এবং প্রতিলিখনের জন্য দরকারী এবং "নিরাপদ" মনে করেন যে স্তরে আপনার নথিগুলি বিভক্ত করতে পারেন, এবং তারপরে অনুরোধ করা হলে প্রয়োজনমতো আবার একসাথে রেখে দিতে পারেন।

আশা করি এইটি কাজ করবে.

Comments

এটি ল্যান্সকে সহায়তা করেছিল কিনা তা নিশ্চিত নয় তবে আমি একটি জিনিস জানি; এটি অবশ্যই আমাকে এক বিরাট সাহায্য করেছে! এটা সত্যিই দারুন!

— চিহ্নিত করুন

Answer 2

আমি জানি এটি একটি পুরানো প্রশ্ন, তবে আমি ঠিক একই সমস্যাটির সর্বোত্তম পদ্ধতির সন্ধান করার চেষ্টা করে এটিকে ঘুরে এসেছি। ক্রিস্টোফার লেনজ কাউচডিবিতে "যোগ দেয়" মডেলিংয়ের পদ্ধতি সম্পর্কে একটি দুর্দান্ত ব্লগ পোস্ট লিখেছিলেন । আমার গ্রহণের একটি উপায় ছিল: "সম্পর্কিত তথ্যগুলিকে দ্বি-বিরোধী সংযোজনের অনুমতি দেওয়ার একমাত্র উপায় হ'ল সেই সম্পর্কিত ডেটা পৃথক নথিতে রেখে দেওয়া" " সুতরাং, সরলতার জন্য আপনি "অস্বীকৃতি" এর দিকে ঝুঁকতে চান। তবে কিছু পরিস্থিতিতে বিরোধী লেখার কারণে আপনি একটি প্রাকৃতিক বাধা অর্জন করবেন।

আপনার পোস্ট এবং মন্তব্যের উদাহরণে, যদি কোনও একক পোস্ট এবং এর সমস্ত মন্তব্য একটি নথিতে থাকে তবে দুটি ব্যক্তি একই সাথে মন্তব্য পোস্ট করার চেষ্টা করছে (অর্থাত্ নথির একই সংশোধনের বিরুদ্ধে) দ্বন্দ্বের কারণ হতে পারে। এটি আপনার "একক দস্তাবেজের পুরো সাইট" দৃশ্যে আরও খারাপ হয়ে উঠবে।

সুতরাং আমি মনে করি যে থাম্বের নিয়মটি "ব্যথা না হওয়া পর্যন্ত অস্বীকার করা হবে", তবে এটি যেখানে "আঘাত করবে" সেই বিন্দুটি হ'ল ডকুমেন্টের একই সংশোধনের বিপরীতে আপনার একাধিক সম্পাদনা পোস্ট হওয়ার উচ্চ সম্ভাবনা রয়েছে।

Comments

আকর্ষণীয় প্রতিক্রিয়া। এই বিষয়টি মাথায় রেখে, কেউ প্রশ্ন করা উচিত যে যুক্তিসঙ্গতভাবে উচ্চ ট্র্যাফিক সাইটের এমনকি একটি নথিতে একটি ব্লগ পোস্টের জন্য সমস্ত মন্তব্য থাকতে পারে। যদি আমি এই অধিকারটি পড়ি, এর অর্থ হ'ল প্রত্যেকবার আপনি যখন লোকদের দ্রুত উত্তরসূরীতে মন্তব্য যুক্ত করেন, তখন আপনাকে বিবাদগুলি সমাধান করতে হতে পারে। অবশ্যই, আমি জানি না যে উত্তরাধিকার সূত্রে কত তাড়াতাড়ি তাদের এটিকে ট্রিগার করতে হবে।

— pc1oad1etter

যে ক্ষেত্রে মন্তব্যগুলি পালঙ্কে নথির অংশ, একই সাথে মন্তব্য পোস্টগুলি সংঘাতের কারণ হতে পারে কারণ আপনার সংস্করণের সুযোগটি তার সমস্ত মন্তব্য সহ "পোস্ট"। আপনার প্রতিটি বস্তু নথি সংগ্রহ করার ক্ষেত্রে, এটি কেবল পোস্টে ফিরে লিঙ্কযুক্ত এবং সংঘর্ষের উদ্বেগের সাথে দুটি নতুন 'মন্তব্য' নথি হয়ে উঠবে। আমি আরও উল্লেখ করতে চাই যে "অবজেক্ট অরিয়েন্টেড" ডক ডিজাইনের উপর বিল্ডিং ভিউগুলি সরাসরি এগিয়ে রয়েছে - আপনি কোনও পোস্টের কীতে পাস করেন উদাহরণস্বরূপ, সেই পোস্টের জন্য কোনও মন্তব্য অনুসারে সাজানো সমস্ত মন্তব্য নির্গত করুন।

— রিয়াদ কল্লা

Answer 3

বই বলে, যদি আমি সঠিকভাবে স্মরণ পর্যন্ত "এটা ব্যাথা" denormalize, যখন ফ্রিকোয়েন্সি যা দিয়ে আপনার দস্তাবেজগুলি আপডেট করা যেতে পারে মনে রেখে।

1. আপনার নথিগুলি (সম্পর্কগুলি ইত্যাদি) ভাগ করার জন্য আপনি কোন বিধি / নীতিগুলি ব্যবহার করেন?

থাম্বের নিয়ম হিসাবে, আমি প্রশ্নযুক্ত আইটেমটি সম্পর্কিত কোনও পৃষ্ঠা প্রদর্শনের জন্য প্রয়োজনীয় সমস্ত ডেটা অন্তর্ভুক্ত করছি। অন্য কথায়, আপনি যা কিছু কাগজের টুকরোটি রিয়েল-ওয়ার্ল্ডে মুদ্রণ করবেন যা আপনি কারও হাতে তুলে দেবেন। উদাহরণস্বরূপ একটি স্টক উদ্ধৃতি নথিতে সংখ্যার পাশাপাশি সংস্থার নাম, এক্সচেঞ্জ, মুদ্রা অন্তর্ভুক্ত থাকবে; একটি চুক্তি নথিতে অংশের নাম ও ঠিকানা, তারিখ এবং স্বাক্ষর সম্পর্কিত সমস্ত তথ্য অন্তর্ভুক্ত থাকবে। তবে পৃথক তারিখের স্টক কোটগুলি পৃথক নথি তৈরি করবে, পৃথক চুক্তি পৃথক নথি তৈরি করবে।

2. পুরো সাইটটিকে একটি ডকুমেন্টে রেখে দেওয়া কি ঠিক আছে?

না, এটি নির্বোধ হবে কারণ:

• আপনাকে প্রতিটি আপডেটে পুরো সাইটটি (দস্তাবেজ) পড়তে হবে এবং লিখতে হবে এবং এটি খুব অকার্যকর;
• আপনি কোনও ভিউ ক্যাচিং থেকে উপকৃত হবেন না।

Comments

এটি আমার সাথে কিছুটা forুকার জন্য ধন্যবাদ আমি "প্রশ্নযুক্ত আইটেমটি সম্পর্কিত কোনও পৃষ্ঠা প্রদর্শনের জন্য প্রয়োজনীয় সমস্ত ডেটা অন্তর্ভুক্ত করার" ধারণাটি পেয়েছি তবে এটি এখনও কার্যকর করা খুব কঠিন। একটি "পৃষ্ঠা" মন্তব্যগুলির একটি পৃষ্ঠা, ব্যবহারকারীর একটি পৃষ্ঠা, পোস্টগুলির একটি পৃষ্ঠা বা মন্তব্য এবং পোস্টগুলির একটি পৃষ্ঠা ইত্যাদি হতে পারে আপনি কীভাবে তখন সেগুলিকে ভাগ করবেন, মূলত? আপনি ব্যবহারকারীদের সাথে আপনার চুক্তিটিও প্রদর্শন করতে পারেন। আমি 'ফর্মের মতো' নথি পেয়েছি, সেগুলি আলাদা রাখার জন্য তা বোঝা যায়।

— ল্যান্স পোলার্ড

Answer 4

আমি মনে করি জ্যাকের প্রতিক্রিয়া কাউচডিবিয়ের সাথে কাজ করার অন্যতম গুরুত্বপূর্ণ দিক নখ যা আপনাকে স্কোপিং সিদ্ধান্ত নিতে সহায়তা করতে পারে: দ্বন্দ্ব।

আপনার নিজের পোস্টটির একটি অ্যারে সম্পত্তি হিসাবে মন্তব্য রয়েছে এবং জ্যাক এবং অন্যান্যরা সঠিকভাবে উল্লেখ করেছেন যে আপনি যে কোনও দৃশ্যের কল্পনা করতে পারবেন ঠিক তেমন একটি 'পোস্ট' ডিবিতে এতে বিশাল একটি 'পোস্ট' নথি রয়েছে with একটি সত্যই জনপ্রিয় ব্লগ পোস্ট যেখানে দু'জন ব্যবহারকারী একই সাথে পোস্ট নথিতে সম্পাদনা জমা দেয়, ফলস্বরূপ এই দস্তাবেজের জন্য সংঘর্ষ এবং সংস্করণ সংঘাত ঘটে।

ASIDE: যেমন এই নিবন্ধটি উল্লেখ করেছে , এটিও বিবেচনা করুন যে প্রতিবার আপনি যখন ডকটিটি সম্পূর্ণরূপে নথিটি পেতে / সেট করতে চান তখন আপনাকে অনুরোধ করা / আপডেট করা হয়, সুতরাং একটি বিশাল নথি যা পুরো সাইট বা একটি পোস্ট সহ অনেকগুলি উপস্থাপন করে এটিতে মন্তব্য করা এমন সমস্যা হয়ে উঠতে পারে যা আপনি এড়াতে চান।

যে ক্ষেত্রে পোস্টগুলি মন্তব্য থেকে পৃথকভাবে মডেল করা হয় এবং দু'জন লোক একটি গল্পের উপরে একটি মন্তব্য জমা দেয়, সেগুলি কেবল ডিবিতে দুটি "মন্তব্য" নথি হয়ে যায়, এতে কোনও বিরোধ নেই; "মন্তব্য" ডিবিতে দুটি নতুন মন্তব্য যুক্ত করতে মাত্র দুটি পুট অপারেশন।

তারপরে এমন একটি ভিউ লিখতে যা আপনাকে কোনও পোস্টের জন্য মন্তব্যগুলি ফিরিয়ে দেয়, আপনি পোস্টআইডিতে পাস করবেন এবং তারপরে এমন সমস্ত মন্তব্য প্রেরণ করবেন যা প্যারেন্ট পোস্ট আইডিকে কিছু যৌক্তিক ক্রম অনুসারে সাজানো হয়েছে। পিতামাতার পোস্ট এবং আপনি কীভাবে ফলাফলগুলি বাছাই করতে চান বা সেই লাইনগুলিতে কীভাবে কিছু চান তা নির্দেশ করতে আপনি এমনকি 'মন্তব্যগুলি' দর্শনের মূল হিসাবে [পোস্টআইডি, বাই ব্যবহারকারীর মতো] কিছুতে পাস করেছেন।

মঙ্গোডিবি ডকুমেন্টকে কিছুটা ভিন্নভাবে পরিচালনা করে, নথির উপ-উপাদানগুলিতে সূচীগুলি তৈরি করার অনুমতি দেয়, সুতরাং আপনি একই প্রশ্নটি মঙ্গোডিবি মেলিং তালিকায় দেখতে পাবেন এবং কেউ "মন্তব্যগুলিকে কেবল প্যারেন্ট পোস্টের সম্পত্তি হিসাবে চিহ্নিত করুন" বলে মন্তব্য করতে পারে।

লেখার লকিং এবং মঙ্গোর একক-মাস্টার প্রকৃতির কারণে, দু'জনের মন্তব্য যুক্ত করার পরস্পরবিরোধী সংশোধন ইস্যুটি এখানে উঠে আসবে না এবং উল্লিখিত লিখিত সামগ্রীর অনুসন্ধান-ক্ষমতা খুব খারাপভাবে প্রভাবিত হবে না কারণ সাব- ইনডেক্স।

বলা হচ্ছে, যদি কোনও ডিবিতে আপনার উপ-উপাদানগুলি বিশাল হতে চলেছে (হাজার হাজার মন্তব্যের দশকে বলুন) আমি বিশ্বাস করি যে এই দুটি পৃথক উপাদান তৈরি করার জন্য উভয় শিবিরেরই সুপারিশ; আমি অবশ্যই দেখেছি যে মঙ্গোর ক্ষেত্রে এটি হতে পারে কারণ কোনও দলিল এবং এর সূত্রগুলি কতটা বড় হতে পারে তার কিছু উপরের সীমাবদ্ধতা রয়েছে।

Comments

খুব উপকারী. আপনাকে ধন্যবাদ

— রে Suelzer