ডাটাবেস ডিজাইন: একটি "(বহু থেকে বহু)-থেকে বহু" সম্পর্ককে সাধারণকরণ

Question

সংক্ষিপ্ত সংস্করণ

বিদ্যমান বহু থেকে বহু লোকের যোগদানের জন্য আমাকে প্রতিটি জোড়ায় একটি নির্দিষ্ট সংখ্যক অতিরিক্ত সম্পত্তি যুক্ত করতে হবে। নীচের চিত্রগুলিতে এড়িয়ে যাওয়া, বেস কেসটি প্রসারিত করে এটি সম্পাদন করার সুবিধাগুলি এবং অসুবিধাগুলির দিক থেকে বিকল্পগুলির মধ্যে 1-4 কে সবচেয়ে ভাল উপায়? বা, আমি এখানে বিবেচনা না করে এর চেয়ে ভাল বিকল্প আছে কি?

দীর্ঘ সংস্করণ

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

1. অতিরিক্ত সংখ্যার নির্দিষ্ট সংখ্যার একটি সংস্থার সাথে একটি জুড়ি যুক্ত
2. একজোড়া অনেকগুলি অতিরিক্ত বৈশিষ্ট্যযুক্ত
3. অনেকগুলি (দুটি) অবজেক্ট বৈশিষ্ট্যের এক সেটের সাথে যুক্ত
4. অনেক সম্পত্তি অনেক সম্পত্তি যুক্ত

উদাহরণ

আমার দুটি অবজেক্ট টাইপ, এক্স এবং ওয়াই, প্রতিটি অনন্য আইডি সহ, এবং objx_objyকলামগুলির সাথে একটি লিঙ্ক টেবিল x_idএবং y_idযা একসাথে লিঙ্কটির জন্য প্রাথমিক কী গঠন করে। প্রতিটি এক্স অনেকগুলি ওয়াইসের সাথে সম্পর্কিত হতে পারে এবং এর বিপরীতে। এটি আমার বিদ্যমান বহু থেকে বহু সম্পর্কের জন্য সেটআপ।

বেস কেস

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

বিকল্প 1

আমার বর্তমান অবস্থায় ঠিক তিন শর্ত আছে, এবং তাই এক সম্ভাবনা কলাম যুক্ত করতে আমি, যে বৃদ্ধি আশা কোন কারণ নেই c1_p_id, c2_p_idএবং c3_p_idকরতে featx_featy, একটি দেওয়া নির্দিষ্ট x_idএবং y_idযা সম্পত্তি, p_idতিনটি ক্ষেত্রে প্রতিটি ব্যবহারের ।

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

বিকল্প 2

একটি শর্ত সারণী তৈরি করুন cond, এবং যোগদানের টেবিলের প্রাথমিক কীতে শর্ত আইডি যুক্ত করুন।

এর একটি নেতিবাচক দিকটি হ'ল এটি প্রতিটি জুটির জন্য শর্তের সংখ্যা নির্দিষ্ট করে না। আরেকটি হ'ল আমি যখন প্রাথমিক সম্পর্কের বিষয়টি কেবল তখনই বিবেচনা করি তবে এরকম কিছু

SELECT objx.*, objy.* FROM objx
  INNER JOIN objx_objy ON objx_objy.x_id = objx.id
  INNER JOIN objy ON objy.id = objx_objy.y_id

DISTINCTসদৃশ এন্ট্রি এড়াতে আমাকে তখন একটি ধারা যুক্ত করতে হবে। এতে প্রতিটি জুটির উপস্থিতি একবারেই হওয়া উচিত বলে মনে হয়।

বিকল্প 3

যোগদানের টেবিলটিতে একটি নতুন 'জুড়ি আইডি' তৈরি করুন এবং তারপরে প্রথমটি এবং বৈশিষ্ট্য এবং শর্তগুলির মধ্যে একটি দ্বিতীয় লিঙ্ক টেবিল রাখুন।

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

বিকল্প 4 (3 বি)

মূলত অপশন 3 এর সমান, তবে অতিরিক্ত আইডি ক্ষেত্রটি তৈরি না করেই। এটি নতুন যোগদানের টেবিলের মূল আইডি উভয় রেখেই সম্পন্ন হয়, সুতরাং এটির পরিবর্তে, ক্ষেত্রগুলি x_idএবং y_idক্ষেত্রগুলি থাকে xy_id।

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

সারসংক্ষেপ

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

এই বিকল্পগুলির মধ্যে একটিটি কি আমার সেরা পথে এগিয়ে যাওয়ার বা আমার কাছে অন্য কোনও কাঠামো বিবেচনা করা উচিত?

Comments

সামগ্রিকভাবে 1 এবং 4 সেরা বিকল্প বলে মনে হচ্ছে, আমি সম্মত। বিকল্প 4 সহ স্থির (3) সংখ্যার বৈশিষ্ট্য প্রয়োগ করা সহজ হবে না তবে আমি মনে করি এটি সম্ভবত সম্ভব।

— ypercubeᵀᴹ

জন্য DISTINCTদফা, আমি # 2 শেষে এক, যা সংযোগগুলি মত একটি ক্যোয়ারী চিন্তা ছিল xএবং yএর মাধ্যমে xycকিন্তু বোঝায় না cযদি আমি করেছেন ... তাই (x_id, y_id, c_id)সীমাবদ্ধ UNIQUEসারি দিয়ে (1,1,1)এবং (1,1,2)তারপর, SELECT x.id, y.id FROM x JOIN xyc JOIN yআমি ফিরে পাবেন একই রকম দুটি সারি, (1,1)এবং (1,1)।

— মাইকেল আন্ডারউড

আহ, ঠিক আছে. আমি যাইহোক বিকল্প 2 খারিজ করব। আমি 1 বা 4 এর সাথে যাব

— ypercubeᵀᴹ

আমি এটি সম্পর্কে যত বেশি চিন্তা করি ততই আমি অনুভব করি যে সম্পত্তিগুলির সংখ্যা ঠিক তিনটিতে সীমাবদ্ধ করা আমার প্রয়োজনীয়তার মধ্যে সবচেয়ে গুরুত্বপূর্ণ। পরের কিছুক্ষণের মধ্যে অতিরিক্ত গঠনমূলক প্রতিক্রিয়া ব্যতীত আমি সম্ভবত এই সময়ে # 4 নিয়ে যাব। আপনার ইনপুট জন্য ধন্যবাদ, @ypercube!

— মাইকেল আন্ডারউড

Answer 1

• বিকল্প 1

  * এটি আমার কাছে দুর্দান্ত ধারণা বলে মনে হচ্ছে না, কারণ এটি কোনও বৈশিষ্ট্যে প্রয়োগ সমস্ত বৈশিষ্ট্য নির্বাচন করতে এসকিউএলকে জটিল করে তোলে…

  এটি অগত্যা এসকিউএল জিজ্ঞাসা জটিল করে তোলে না (নীচে উপসংহার দেখুন)।

  … এবং সহজেই আরও শর্তে স্কেল করে না ...

  এটি আরও শর্তের সাথে সহজেই স্কেল করে, যতক্ষণ না এখনও নির্দিষ্ট সংস্থাগুলি রয়েছে, এবং সেখানে কয়েক ডজন বা শতাধিক নেই।

  যাইহোক, এটি প্রতি (এক্স, ওয়াই) জোড়ের জন্য নির্দিষ্ট সংখ্যক শর্তের প্রয়োজনীয়তা প্রয়োগ করে। আসলে এখানে এটিই একমাত্র বিকল্প যা এটি করে *

  এটি হ'ল, এবং যদিও আপনি একটি মন্তব্যে বলেছেন যে এটি "আমার প্রয়োজনীয়তার মধ্যে সবচেয়ে কম গুরুত্বপূর্ণ", আপনি বলেননি এটি মোটেই গুরুত্বপূর্ণ নয় doesn't

• বিকল্প 2

  এর একটি নেতিবাচক দিকটি হ'ল এটি প্রতিটি জুটির জন্য শর্তের সংখ্যা নির্দিষ্ট করে না। আর একটি হ'ল যখন আমি কেবল প্রাথমিক সম্পর্কের বিষয়টি বিবেচনা করি ... তখন আমাকে নকল প্রবেশগুলি এড়াতে একটি DISTINCT ধারা যোগ করতে হবে ...

  আমি মনে করি আপনি যে জটিলতাগুলি উল্লেখ করেছেন তার কারণে আপনি এই বিকল্পটি বরখাস্ত করতে পারেন। objx_objyটেবিল (যেমন "নির্বাচন করুন সব সম্পত্তি একটি বৈশিষ্ট্য প্রয়োগ করা", যা আমি সব সম্পত্তি মানে নিচ্ছি একটি প্রয়োগ আপনার প্রশ্ন কিছু ড্রাইভিং টেবিল হতে পারে objxবা objy)। আপনি প্রাক-প্রয়োগের জন্য একটি ভিউ ব্যবহার করতে পারেন DISTINCTসুতরাং এটি জটিল প্রশ্নগুলির বিষয় নয় তবে এটি খুব অল্প লাভের জন্য খুব খারাপভাবে পারফরম্যান্স-ভিত্তিতে স্কেল করতে চলেছে।

• বিকল্প 3

  একটি নতুন আইডি তৈরি করা যদিও বিদ্যমান আইডি ব্যতীত অন্য কিছুই সনাক্ত করে তা কি বোধগম্য নয়?

  না, এটি হয় না - বিকল্প 4 দিকটি সর্বোত্তম।

• বিকল্প 4

  … এটি মূলত পুরো টেবিলটিকে একাধিকবার নকল করে (বা যাইহোক, সেভাবে অনুভব করে) তাই এটি আদর্শ বলে মনে হয় না।

  এই বিকল্পটি ঠিক আছে - সম্পত্তির সংখ্যা পরিবর্তনশীল বা পরিবর্তনের সাপেক্ষে সম্পর্ক স্থাপনের এটি সুস্পষ্ট উপায়

উপসংহার

আমার পছন্দের বিকল্পটি 1 হবে যদি প্রতি সম্পত্তিগুলির সংখ্যা objx_objyস্থিতিশীল হওয়ার সম্ভাবনা থাকে এবং আপনি যদি কখনও মুষ্টিমেয় অতিরিক্তের চেয়ে বেশি যোগ করার বিষয়টি কল্পনা করতে না পারেন তবে। এটি একমাত্র বিকল্প যা 'বৈশিষ্ট্যগুলির সংখ্যা = 3' সীমাবদ্ধতা প্রয়োগ করে - 4 বিকল্পের অনুরূপ সীমাবদ্ধতা প্রয়োগ করা সম্ভবত c1_p_idযুক্তিযুক্ত টেবিলে যাইহোক * কলাম যুক্ত করা জড়িত থাকতে পারে *।

আপনি যদি সেই শর্তটি সম্পর্কে সত্যিই যত্নবান না হন এবং আপনারও সন্দেহের কারণ রয়েছে যে বৈশিষ্ট্যের সংখ্যাটি স্থিতিশীল হতে চলেছে তবে বিকল্প 4 বেছে নিন।

যদি আপনি নিশ্চিত না হন তবে বিকল্প 1 টি চয়ন করুন - এটি সহজ এবং অন্যরা যেমন বলেছে তেমন বিকল্পটি আপনার কাছে থাকলে তা অবশ্যই ভাল। যদি আপনাকে বিকল্প 1 "বন্ধ করে দেওয়া হয় ... কারণ এটি কোনও বৈশিষ্ট্যে প্রয়োগ করা সমস্ত সম্পত্তি নির্বাচন করতে এসকিউএলকে জটিল করে তোলে ..." আমি বিকল্প 4 এর অতিরিক্ত টেবিলের মতো একই ডেটা সরবরাহ করার জন্য একটি ভিউ তৈরির পরামর্শ দিচ্ছি:

বিকল্প 1 টেবিল:

create table prop(id integer primary key);
create table objx(id integer primary key);
create table objy(id integer primary key);

create table objx_objy(
  x_id integer references objx
, y_id integer references objy
, c1_p_id integer not null references prop
, c2_p_id integer not null references prop
, c3_p_id integer not null references prop
, primary key (x_id, y_id)
);

insert into prop(id) select generate_series(90,99);
insert into objx(id) select generate_series(10,12);
insert into objy(id) select generate_series(20,22);

insert into objx_objy(x_id,y_id,c1_p_id,c2_p_id,c3_p_id)
select objx.id, objy.id, 90, 91, 90+floor(random()*10)
from objx cross join objy;

বিকল্প অনুকরণ 4 দেখুন:

create view objx_objy_prop as
select x_id
     , y_id
     , unnest(array[1,2,3]) c_id
     , unnest(array[c1_p_id,c2_p_id,c3_p_id]) p_id
from objx_objy;

"একটি বৈশিষ্ট্যে প্রয়োগ সমস্ত বৈশিষ্ট্য নির্বাচন করুন":

select distinct p_id from objx_objy_prop where x_id=10 order by p_id;

/*
|p_id|
|---:|
|  90|
|  91|
|  97|
|  98|
*/

এখানে ডিবিফিডল

Answer 2

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

যদিও আপনি যদি কঠোর ডাটাবেস স্বাভাবিককরণের নিয়মগুলি অনুসরণ করতে চান তবে আমি বিশ্বাস করি শর্ত সংখ্যা নির্ধারিত কিনা তা বিবেচনা না করেই আপনার সাথে ২ টি প্রয়োজন।