সুবিধাভোগী সন্তানের সাথে কীভাবে একের সাথে একাধিক সম্পর্ক থাকবে?

22

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

TableA
    Id            INT PRIMARY KEY

TableB
    Id            INT PRIMARY KEY
    Parent        INT NOT NULL FOREIGN KEY REFERENCES TableA.Id

আমি এটি যেভাবে দেখছি, আমি নীচের কলামটি টেবিলএতে যুক্ত করতে পারি:

    FavoriteChild INT NULL FOREIGN KEY REFERENCES TableB.Id

বা টেবিলবিতে নিম্নলিখিত কলামটি:

    IsFavorite    BIT NOT NULL

প্রথম পদ্ধতির সমস্যাটি হ'ল এটি একটি অবিচ্ছিন্ন বিদেশী কীটি প্রবর্তন করে, যা আমি বুঝতে পেরেছি যে এটি স্বাভাবিক আকারে নেই। দ্বিতীয় পদ্ধতির সমস্যাটি হ'ল সর্বাধিক এক সন্তানের প্রিয় তা নিশ্চিত করার জন্য আরও কাজ করা দরকার।

কোন পদ্ধতির ব্যবহার করতে হবে তা নির্ধারণ করতে আমার কোন ধরণের মানদণ্ড ব্যবহার করা উচিত? বা, অন্য কোন পন্থা আমি বিবেচনা করছি না?

আমি এসকিউএল সার্ভার 2012 ব্যবহার করছি।

— cubetwo1729
সূত্র

19

আরেকটি উপায় (নুলস ছাড়া এবং FOREIGN KEYসম্পর্কের চক্র ব্যতীত ) "প্রিয় শিশুদের" সঞ্চয় করার জন্য একটি তৃতীয় টেবিল রাখা উচিত। বেশিরভাগ ডিবিএমএসে আপনার একটি অতিরিক্ত UNIQUEবাধা প্রয়োজন TableB।

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

Parent
    ParentID        INT NOT NULL PRIMARY KEY

Child
    ChildID         INT NOT NULL PRIMARY KEY
    ParentID        INT NOT NULL FOREIGN KEY REFERENCES Parent (ParentID)
    UNIQUE (ParentID, ChildID)

FavoriteChild
    ParentID        INT NOT NULL PRIMARY KEY
    ChildID         INT NOT NULL 
    FOREIGN KEY (ParentID, ChildID) 
        REFERENCES Child (ParentID, ChildID)

এসকিউএল-সার্ভারে (যে আপনি ব্যবহার করছেন), আপনি যে IsFavoriteবিট কলামটি উল্লেখ করেছেন তার বিকল্পও রয়েছে । পিতামাতার প্রতি অনন্য প্রিয় শিশু ফিল্টার করা অনন্য সূচকের মাধ্যমে সম্পন্ন করা যায়:

Parent
    ParentID        INT NOT NULL PRIMARY KEY

Child
    ChildID         INT NOT NULL PRIMARY KEY
    ParentID        INT NOT NULL FOREIGN KEY REFERENCES Parent (ParentID)
    IsFavorite      BIT NOT NULL

CREATE UNIQUE INDEX is_FavoriteChild
  ON Child (ParentID)
  WHERE IsFavorite = 1 ;

এবং অন্তত এসকিউএল-সার্ভারে নয়, আপনার বিকল্প 1 টি সুপারিশ করা হয়নি তার মূল কারণ হ'ল বিদেশী কী রেফারেন্সগুলিতে বৃত্তাকার পথগুলির প্যাটার্নটিতে কিছু সমস্যা রয়েছে।

একটি বেশ পুরানো নিবন্ধ পড়ুন: এসকিউএল ডিজাইন দ্বারা: বিজ্ঞপ্তি রেফারেন্স

দুটি টেবিল থেকে সারি সন্নিবেশ করা বা মুছার সময়, আপনি "মুরগী এবং ডিম" সমস্যার মধ্যে চলে যাবেন। কোন সীমাবদ্ধতা লঙ্ঘন না করে আমার প্রথমে কোন টেবিলটি sertোকানো উচিত?

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

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

— ypercubeᵀᴹ
সূত্র

9

এটি আপনার অগ্রাধিকার কী তার উপর নির্ভর করে। আপনি কি কাজ এড়াতে চান বা আপনি সাধারণীকরণের কঠোরতম নিয়ম মেনে চলতে চান?

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

@ ইয়ারকিউবের পরামর্শটিও একটি ভাল সমঝোতা।

একপাশে হিসাবে, দয়া করে, দয়া করে অর্থহীন কলাম নাম মত আপনার স্কিমা জঞ্জাল না Id। আমি বরং Idস্কিমা জুড়ে অর্থবহ উপায়ে নামটির নাম দেখতে পাচ্ছি । এটি কোনও লেখককে সনাক্ত করতে পারে? ঠিক আছে, এটি কল AuthorID। এটি একটি পণ্য প্রতিনিধিত্ব করে? ঠিক আছে ProductID। এটি কোনও কর্মচারী, এবং কিছু ক্ষেত্রে কোনও পরিচালকের উল্লেখ রয়েছে? ঠিক আছে, EmployeeIDএবং ManagerIDতুলনায় আমার আরো জানার জন্য IDএবং Parent। যদিও এটি ছেড়ে দেওয়া যুক্তিসঙ্গত বলে মনে হতে পারে (এবং এটি toোকাতে অপ্রয়োজনীয়), যখন আপনি জটিল যোগদান করতে শুরু করেন (বা এখানে ক্যোয়ারী পোস্ট করেন) আপনি অবশ্যই কিছুটা অভিশাপ বোধ করবেন যখন আপনি ইঞ্জিনিয়ারকে একগুচ্ছ বিপরীত করার চেষ্টা করছেন সেই বিন্দুতে যোগ দেয় কলামগুলিতে a.Parent = b.ID... ব্লিচ।

— অ্যারন
সূত্র

1

ডেটা সন্তানের টেবিলে অন্তর্ভুক্ত। একটিকে রেকর্ডটি প্রিয় হিসাবে চিহ্নিত করা হয়েছে (বা আমাদের ক্ষেত্রে পছন্দসই ঠিকানা হিসাবে) তা নিশ্চিত করতে আমরা টেবিলে একটি ট্রিগার দিয়ে এটি সঠিক রাখি।

তবে, আলাদা আলাদা টেবিলের বিষয়ে @ ইপারকিউবের ধারণাটিও ভাল।

— HLGEM
সূত্র