চক্রীয় নির্ভরতা এড়াতে এই ডাটাবেসটিকে কীভাবে ডিজাইন করবেন?

Question

দুটি টেবিল রয়েছে:

1. ব্যবহারকারী
2. ঠিকানা

ব্যবহারকারীর ঠিকানা সম্পর্কিত একটি উল্লেখ রয়েছে।

ঠিকানার মধ্যে ক্রিয়েটেড বাই এবং মডিফাইডবাই কলাম রয়েছে যা ব্যবহারকারীর রেফারেন্স।

চক্রীয় নির্ভরতা এড়াতে আমি কীভাবে এই ডাটাবেসটি ডিজাইন করব?

Comments

আপনি কি নিশ্চিত যে মডিফাডবাই অ্যাপ্লিকেশন ব্যবহারকারীর পরিবর্তে (যে ব্যবহারকারীর টেবিলে থাকবে) পরিবর্তিত ডেটাবেস ব্যবহারকারীর একটি উল্লেখ নেই? যেভাবেই হোক না কেন, আসলেই কিছু আসে যায় না। আমি দেখতে পাচ্ছি না কেন আসল সমস্যা আছে?

— ফিলি

কোনটি প্রথমে তৈরি করবে। হিসাবে CreatedBy এএনডি সংশোধিত একটি আবশ্যক ডেটা। এবং ব্যবহারকারীর টেবিলের অ্যাড্রেসিড নਾਲ হিসাবে থাকা উচিত নয় .. মুরগির ডিমের সমস্যা। আমি যেমন এটি একটি নতুন টেবিল ইউজারএড্রেস তৈরি করে সমাধান করেছি যাতে ইউজারিড এবং অ্যাড্রেডির রেফারেন্স রয়েছে

— শশী

আপনার ডিবিএমএস যদি তাদের সমর্থন করে তবে আপনি সর্বদা পিছিয়ে থাকা সীমাবদ্ধতাগুলি ব্যবহার করতে পারেন।

— কলিন টি হার্ট

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

— কলিন 'হার্ট

Answer 1

টিপস এবং কৌশলগুলি অনুসন্ধানের পরিবর্তে (পিছিয়ে দেওয়া সীমাবদ্ধতাগুলি অন্তর্ভুক্ত) আমি আপনাকে পরামর্শ দেব যে আপনি এই "রেফারেন্স লক" থেকে আপনার উপায়টি কেবল ডিজাইন করুন - সুতরাং এর মতো কিছু চেষ্টা করুন:

---

তথ্য

• ব্যবহারকারী(UserID) বিদ্যমান।
• ঠিকানা ব্যবহারকারী(AddressID) দ্বারা তৈরি করা হয়েছিল ।(UserID)
• ঠিকানা(AddressID) তে তৈরি করা হয়েছে তারিখ(DateCreated) ।
• ঠিকানা(AddressID) সর্বশেষ রুপান্তরিত হয়েছিল ব্যবহারকারী(UserID) উপর তারিখ(ModifiedOn) ।
• তারিখের পরে ব্যবহারকারীর ঠিকানায়(UserID) থাকে ।(AddressID)(ValidFrom)

---

সীমাবদ্ধতাসমূহ

• Each ঠিকানা exactly one ব্যবহারকারী দ্বারা তৈরি করা হয়েছিল । It is possible that more than one ঠিকানা the same ব্যবহারকারী দ্বারা তৈরি করা হয়েছিল ।

• Each ঠিকানা তে তৈরি করা হয়েছে exactly one তারিখ । It is possible that more than one ঠিকানা তে তৈরি করা হয়েছে the same তারিখ ।

• For each ঠিকানা and তারিখ , that ঠিকানা দ্বারা পরিবর্তন হয়েছিল at most one ব্যবহারকারী উপর that তারিখ ।

• For each ব্যবহারকারী and তারিখ , that ব্যবহারকারী বসবাস at most one ঠিকানা যেহেতু that তারিখ ।

---

যৌক্তিক

---

যতটা বাধ্যতামূলক ঠিকানা সম্পর্কিত, অ্যাপ্লিকেশন স্তরে যাচাই করুন এবং লেনদেনের মধ্যে লোডিং স্টেটমেন্টগুলি মুড়ে দিন - এইভাবে আপনি সমস্ত কিছু বা কিছুই পাবেন না।

Answer 2

নীচে হিসাবে 2 টি ক্রিয়াকলাপে চক্রীয় নির্ভরতা তৈরি করা ছাড়া আপনার বিকল্প নেই কারণ আপনি প্রথমটি তৈরি করার সময় একটি টেবিলের অস্তিত্ব নেই।

CREATE TABLE A (A_ID INT PRIMARY KEY, B_FK INT);
CREATE TABLE B (B_ID INT PRIMARY KEY, A_FK INT REFERENCES A(A_ID));

ALTER TABLE A ADD B_FK INT;

আপনি যদি চক্র নির্ভরতা এড়াতে চান। তারপরে আপনাকে একটি রেফারেন্সের সীমাবদ্ধতা অপসারণ করতে হবে বা আপনি একটি উপায়ে একটি মোছা এবং আপডেট ক্যাসকেড রেফারেন্স যুক্ত করতে পারেন। যদি আপনার যুক্তি কিছুটা জটিল হয় তবে আপনি একটি ট্রিগারও প্রয়োগ করতে পারেন।

Comments

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

— লেইফ রিফেল

@ লিগ্রিফেল আমি সম্মত তবে আপনার প্রস্তাবিত ইভেন্টস টেবিলটি আসলে সমস্ত চক্রীয় নির্ভরতা সরিয়ে দেয়।

— ypercubeᵀᴹ

@ টাইপ्यूब আসলে এটি করে; নিশ্চিত না যে আমি কীভাবে তারটি পেরিয়ে গেলাম। পরিষ্কার হওয়ার জন্য আপনার সম্ভবত ইভেন্ট ইভেন্ট টেবিল তৈরি করা উচিত নয় যদিও এটি চক্রীয় নির্ভরতা অপসারণ করে।

— লেইফ রিফেল

যাইহোক, আমি মনে করি না যে এই উত্তরটি সমস্যার সমাধান করে। প্রশ্নটি (আমার মনে হয়) চক্রীয় পথটি কীভাবে এড়ানো যায় সে সম্পর্কে, প্রথমে চক্রাকার পথ দিয়ে এফকে কীভাবে তৈরি করা যায় তা নয়।

— ypercubeᵀᴹ