প্রতিটি কোর ডেটা সম্পর্কের কি একটি বিপরীত থাকতে হয়?


150

ধরা যাক আমার দুটি সত্তা ক্লাস রয়েছে: SocialAppএবংSocialAppType

ইন SocialApp: আমি একটি অ্যাট্রিবিউট আছে appURLএবং এক সম্পর্ক: type

ইন SocialAppTypeআমি তিনটি গুণাবলী আছে: baseURL, nameএবং favicon

SocialAppসম্পর্কের গন্তব্যটি typeএকক রেকর্ড SocialAppType

উদাহরণস্বরূপ, একাধিক ফ্লিকার অ্যাকাউন্টগুলির জন্য, SocialAppপ্রতিটি রেকর্ডের সাথে একজন ব্যক্তির অ্যাকাউন্টে একটি লিঙ্ক ধারণ করে প্রচুর রেকর্ড থাকবে। SocialAppType"ফ্লিকার" প্রকারের জন্য একটি রেকর্ড থাকবে যা সমস্ত SocialAppরেকর্ড নির্দেশ করবে।

যখন আমি এই স্কিমাটি দিয়ে একটি অ্যাপ্লিকেশন তৈরি করি, তখন আমি একটি সতর্কতা পাই যে SocialAppTypeএবং এর মধ্যে কোনও বিপরীত সম্পর্ক নেই SocialApp

 /Users/username/Developer/objc/TestApp/TestApp.xcdatamodel:SocialApp.type: warning: SocialApp.type -- relationship does not have an inverse

আমার কি বিপরীত দরকার, এবং কেন?

উত্তর:


117

অনুশীলনে, বিপরীত না থাকার কারণে আমার কোনও ডেটা ক্ষতি হয়নি - কমপক্ষে যা আমি অবগত রয়েছি। একটি দ্রুত গুগল পরামর্শ দেয় আপনার এগুলি ব্যবহার করা উচিত:

একটি বিপরীত সম্পর্ক কেবল জিনিসগুলিকে আরও পরিপাটি করে না, এটি প্রকৃতপক্ষে ডেটা অখণ্ডতা বজায় রাখতে কোর ডেটা ব্যবহার করে।

- কোকো দেব সেন্ট্রাল

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

- কোর ডেটা প্রোগ্রামিং গাইড


5
বিপরীতমুখী সম্পর্কগুলি ডেটা অখণ্ডতা বজায় রাখতে সহায়তা করে ডক্স বলতে কী বোঝায় তার আরও বিশদ ব্যাখ্যার জন্য ম্যাডনিকের উত্তর (পৃষ্ঠার নীচে এই মুহুর্তে আমি এটি লিখছি) দেখুন।
মার্ক আমেরিকা

135

অ্যাপল ডকুমেন্টেশনের একটি দুর্দান্ত উদাহরণ রয়েছে যা এমন পরিস্থিতির প্রস্তাব দেয় যেখানে বিপরীত সম্পর্ক না রেখেই আপনার সমস্যা হতে পারে। এই ক্ষেত্রে এটি মানচিত্র করা যাক।

ধরে নিন আপনি নীচে এটি মডেল করেছেন: এখানে চিত্র বর্ণনা লিখুন

উল্লেখ্য আপনি যদি একটি আছে টু-এক "বলা সম্পর্ক টাইপ " থেকে SocialAppথেকে SocialAppType। সম্পর্কটি অ-alচ্ছিক এবং এতে একটি "অস্বীকার" মোছার নিয়ম রয়েছে

এখন নিম্নলিখিত বিবেচনা করুন:

SocialApp *socialApp;
SocialAppType *appType;
// assume entity instances correctly instantiated

[socialApp setSocialAppType:appType];
[managedObjectContext deleteObject:appType];
BOOL saved = [managedObjectContext save:&error];

সম্পর্কটি nonচ্ছিক না হওয়াতে আমরা মুছে ফেলার নিয়মটিকে অস্বীকার হিসাবে সেট করেছি বলে আমরা এই প্রেক্ষাপটটি ব্যর্থ হব তা প্রত্যাশা করি।

কিন্তু এখানে সংরক্ষণ সফল হয়।

কারণটি হ'ল আমরা কোনও বিপরীত সম্পর্ক সেট করি নি । তার কারণে, অ্যাপ্লিকেশনটি মুছে ফেলা হলে সোশ্যাল অ্যাপ্লিকেশন উদাহরণটি পরিবর্তিত হিসাবে চিহ্নিত হয় না। সুতরাং সংরক্ষণের আগে সোস্যাল অ্যাপের জন্য কোনও বৈধতা ঘটে না (কোনও পরিবর্তন ঘটে নি বলে এটি কোনও বৈধতার প্রয়োজন বলে ধরে নেয়)। কিন্তু আসলে একটি পরিবর্তন ঘটেছিল। কিন্তু এটি প্রতিফলিত হয় না।

আমরা যদি অ্যাপটি টাইপ করে মনে করি

SocialAppType *appType = [socialApp socialAppType];

অ্যাপ টাইপ শূন্য হয়।

অদ্ভুত, তাই না? আমরা একটি অ-alচ্ছিক বৈশিষ্ট্যের জন্য নিলাম পেতে?

সুতরাং যদি আপনি বিপরীত সম্পর্ক স্থাপন করে থাকেন তবে আপনি কোনও সমস্যায় পড়বেন না। অন্যথায় আপনাকে নীচে কোড লিখে জোর করে যাচাই করতে হবে।

SocialApp *socialApp;
SocialAppType *appType;
// assume entity instances correctly instantiated

[socialApp setSocialAppType:appType];
[managedObjectContext deleteObject:appType];

[socialApp setValue:nil forKey:@"socialAppType"]
BOOL saved = [managedObjectContext save:&error];

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

46

ডেভ মার্ক এবং জেফ লেমারচের আরও আইফোন 3 বিকাশে আমি সুনির্দিষ্ট উত্তরটি প্যারাফ্রেস করব।

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

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

তবে যদি না আপনার নির্দিষ্ট কারণ না থাকে তবে বিপরীতটি মডেল করুন । এটি কোর ডেটা ডেটা অখণ্ডতা নিশ্চিত করতে সহায়তা করে। আপনি যদি পারফরম্যান্সের সমস্যাগুলিতে চলে যান তবে বিপরীত সম্পর্কটি পরে মুছে ফেলা অপেক্ষাকৃত সহজ।


24

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


20

কমপক্ষে একটি দৃশ্য আছে যেখানে একটি ইনভার্স ব্যতীত মূল ডেটা সম্পর্কের জন্য একটি ভাল কেস তৈরি করা যায়: যখন ইতিমধ্যে দুটি বস্তুর মধ্যে অন্য একটি কোর্সের ডেটা সম্পর্ক রয়েছে যা বস্তুর গ্রাফ বজায় রাখবে।

উদাহরণস্বরূপ, একটি বইতে অনেক পৃষ্ঠা রয়েছে, যখন একটি পৃষ্ঠায় একটি বই রয়েছে। এটি দ্বি-মুখী বহু-এক-সম্পর্ক relationship একটি পৃষ্ঠা মুছে ফেলা কেবল সম্পর্ককে বাতিল করে দেয়, যেখানে কোনও বই মুছলে পৃষ্ঠাটি মুছে ফেলা হবে।

তবে আপনি প্রতিটি বইয়ের জন্য পঠিত বর্তমান পৃষ্ঠাটিও ট্র্যাক করতে চাইতে পারেন। এই "currentPage" সঙ্গে কাজ করা যেতে পারে সম্পত্তি উপর পৃষ্ঠা , কিন্তু তারপর আপনি অন্য যুক্তিবিজ্ঞান প্রয়োজন তা নিশ্চিত করার জন্য বই একমাত্র পৃষ্ঠা যে কোন সময়ে বর্তমান পৃষ্ঠার হিসাবে চিহ্নিত আছে। পরিবর্তে, বুক থেকে একক পৃষ্ঠায় একটি বর্তমান পৃষ্ঠা সম্পর্ক তৈরি করা নিশ্চিত করে যে কেবল সর্বদা কেবলমাত্র একটি বর্তমান পৃষ্ঠা চিহ্নিত থাকবে এবং তদ্ব্যতীত কেবলমাত্র পৃষ্ঠার বইয়ের রেফারেন্স সহ এই পৃষ্ঠাটি সহজেই অ্যাক্সেস করা যায়।

বই এবং পৃষ্ঠাগুলির মধ্যে মূল ডেটার সম্পর্কের গ্রাফিকাল উপস্থাপনা

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

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

যখন এটি প্রদর্শিত হতে পারে যে বস্তুর গ্রাফ অখণ্ডতা ঝুঁকিপূর্ণ নয়, যেমন উদাহরণ হিসাবে, এবং কোড জটিলতা এবং রক্ষণাবেক্ষণের উন্নতি হয়, তখন যুক্তি দেওয়া যেতে পারে যে একটি বিপরীত ছাড়া সম্পর্ক সঠিক সিদ্ধান্ত হতে পারে।


ধন্যবাদ ডানকান - এটি আমার কাছে ব্যবহারের ক্ষেত্রে অত্যন্ত নিকটে। মূলত, আমার একটি বইয়ের শেষ পৃষ্ঠাটি পেতে সক্ষম হওয়া দরকার । আমার এটিকে একটি স্থির মান হওয়া দরকার যাতে আমি এটি একটি আনতে সক্ষম হিসাবে ব্যবহার করতে পারি। আমি একটি "bookImLastPageOf" বিপরীতটি সেট আপ করেছি, তবে এটি বেশ বোকামিযুক্ত এবং অন্যান্য সমস্যা সৃষ্টি করছে (আমি সঠিকভাবে বুঝতে পারি না)। আপনি কি জানেন যে কোনও একক মামলার জন্য সতর্কতাটি অক্ষম করার কোনও উপায় আছে কিনা?
বেনজোহান

সতর্কতাগুলি অক্ষম করার কোনও উপায় আছে কি? আমার এখন 2: ... এর একটি বিপরীত হওয়া উচিত এবং অ্যাকশন মুছে ফেলার নিয়ম থাকা উচিত ... মুছে ফেলা বস্তুর সাথে সম্পর্কের ফলস্বরূপ । এবং currentPageহিসাবে চিহ্নিত করা যেতে পারে Optional?
সুইফট আরকিটেক্ট

কোনও সম্পর্কের পরিবর্তে এনএসম্যানেজডঅবজেক্টআইডি হিসাবে কারেন্টপেজটি সংরক্ষণ করা কোনও বৈধ পদ্ধতির হতে পারে?
ব্যবহারকারী 965972

4

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


0

বিপরীতগুলিও ব্যবহৃত হয় Object Integrity(অন্যান্য কারণে, অন্যান্য উত্তর দেখুন):

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

থেকে: https://developer.apple.com/library/archive/docamentation/Cocoa/Conceptual/CoreData/HowManagedObjectsarerelated.html#//apple_ref/doc/uid/TP40001075-CH17-SW1

প্রদত্ত লিঙ্কটি আপনাকে একটি inverseসেট কেন রাখা উচিত তা ধারণা দেয় । এটি ছাড়া, আপনি ডেটা / ইন্টিগ্রিটি হারাতে পারেন। এছাড়াও, আপনি যে কোনও বস্তুটিতে অ্যাক্সেস করার সম্ভাবনা nilবেশি সম্ভবত।


0

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.