পারস্পরিক একচেটিয়া সাবক্লাসের সাথে টাইপ / সাব টাইপ ডিজাইন প্যাটার্নে উপ-টাইপের সাব টাইপ প্রয়োগ করা


20

ভূমিকা

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

আমাদের তথ্য মডেল 3 সত্ত্বা, যা হিসাবে লেবেল করা হইবে নিয়ে গঠিত A, Bএবং C। জিনিসগুলিকে সহজ রাখার জন্য, তাদের সমস্ত বৈশিষ্ট্য intটাইপ হবে।

সত্তা Aবৈশিষ্ট্যাবলী অনুসরণ করেনি: D, Eএবং X;

সত্তা Bবৈশিষ্ট্যাবলী অনুসরণ করেনি: D, Eএবং Y;

সত্তার Cনিম্নলিখিত বৈশিষ্ট্য রয়েছে: Dএবং Z;

যেহেতু সমস্ত সত্তা সাধারণ বৈশিষ্ট্য ভাগ করে D, তাই আমি টাইপ / সাব টাইপ ডিজাইন প্রয়োগ করার সিদ্ধান্ত নিয়েছি ।

গুরুত্বপূর্ণ: সত্তা পারস্পরিক একচেটিয়া! এর অর্থ হ'ল সত্ত্বা হয় A বা B বা C হয় either

সমস্যা:

সত্তা Aএবং Bআরও একটি সাধারণ বৈশিষ্ট্য রয়েছে Eতবে এই বৈশিষ্ট্যটি সত্তায় উপস্থিত নেই C

প্রশ্ন:

আমি যদি সম্ভব হয় তবে আমার নকশাটিকে আরও অনুকূল করতে উপরে বর্ণিত বৈশিষ্ট্যটি ব্যবহার করতে চাই।

সত্যি কথা বলতে কি, আমি কীভাবে এটি করব, এবং কোথা থেকে চেষ্টা শুরু করব, তাই এই পোস্টটি সম্পর্কে আমার কোনও ধারণা নেই।

উত্তর:


6

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

আমি রেমাসের সাথে সম্পর্কিত বিষয়গুলির সাথে সম্পূর্ণ একমত :

  • প্রতিটি পদ্ধতির পক্ষে মতামত রয়েছে (যেমন সর্বদা বর্তমান "এটি নির্ভর করে" ফ্যাক্টর), এবং
  • প্রথম অগ্রাধিকারটি হ'ল ডেটা মডেলটির দক্ষতা (একটি অদক্ষ ডেটা মডেল পরিষ্কার এবং / অথবা দক্ষ অ্যাপ কোড দিয়ে সংশোধন করা যায় না)

এটি বলেছিল, আপনি যে পছন্দটির মুখোমুখি হন তা নিম্নের মধ্যে অন্তর্ভুক্ত, সর্বাধিক সাধারণীকরণের জন্য সজ্জিত:

  • Eবেস-টাইপ সারণীতে সম্পত্তি প্রচার করা
  • একাধিক সাব-টাইপ টেবিলগুলিতে এটি রাখা
  • সম্পূর্ণরূপে স্বাভাবিক Eহিসাবে একই স্তরের উপর একটি নতুন, মধ্যবর্তী উপ-বর্গ টেবিলে আউট C, যে Aএবং Bসরাসরি উপ-শ্রেণীর হতে হবে ( @ MDCCL এর উত্তর )

আসুন প্রতিটি বিকল্প তাকান:

Eবেস-টাইপ সারণীতে সম্পত্তি সরান

অনুকূল

  • প্রশ্ন যা প্রয়োজন জন্য কমিয়ে ক্যোয়ারী জটিলতা Eকিন্তু X, Yঅথবা Z
  • সম্ভাব্য আরও দক্ষ করে প্রয়োজন জিজ্ঞাসার জন্য Eকিন্তু না X, Yঅথবা Z(বিশেষ করে সমষ্টিগত প্রশ্নের) কোন কারণে এ যোগ দিন।
  • ইনডেক্স তৈরি করার সম্ভাবনা (D, E)(এবং যদি থাকে তবে (D, E)এন্টিটি টাইপ <> যেখানে Cএমন শর্ত অনুমোদিত থাকলে সম্ভাব্যভাবে একটি ফিল্টার সূচক )

কনস

  • Eহিসাবে চিহ্নিত করতে পারে নাNOT NULL
  • অ্যান্টিটি CHECK CONSTRAINTটাইপ E IS NULL= C(যদিও এটি কোনও বিশাল সমস্যা নয়) তা নিশ্চিত করতে বেস-টাইপ টেবিলের অতিরিক্ত প্রয়োজন
  • কেন Eঅবশ্যই হওয়া উচিত তা ডেটা মডেলের ব্যবহারকারীদের শিক্ষিত করা দরকার NULLএবং যখন এন্টিটাইপ = তখনও পুরোপুরি উপেক্ষা করা উচিত C
  • সামান্য কম দক্ষ যখন Eএকটি নির্দিষ্ট দৈর্ঘ্যের টাইপ, তাই এবং সারি বৃহৎ অংশ EntityType জন্য C(অর্থাত ব্যবহার করছেন না Eঅত: পর তা NULL), এবং ব্যবহার করছেন না পারেন SPARSEকলাম বা ডেটা সংকোচন ক্লাস্টার সূচক উপর বিকল্পটি
  • বেস-টেবিলের Eউপস্থিতি যেহেতু প্রয়োজনীয় প্রশ্নের প্রয়োজন নেই তার জন্য সম্ভাব্যভাবে কম দক্ষতার Eসাথে প্রতিটি সারিটির আকার বাড়বে যা ফলস্বরূপ কোনও ডাটা পৃষ্ঠায় সজ্জিত সারিগুলির সংখ্যা হ্রাস পাবে। তবে Eএটি ফিলফেক্টর, বেস-টাইপ টেবিলের মধ্যে কতগুলি সারি রয়েছে তার সঠিক ডেটাটাইপগুলির উপর নির্ভরশীল etc.

Eপ্রতিটি উপ-টাইপ সারণীতে সম্পত্তি রাখুন

অনুকূল

  • ক্লিনার ডেটা মডেল (উদাহরণস্বরূপ E, বেস-টাইপ টেবিলের কলামটি কেন ব্যবহার করা উচিত নয় সে সম্পর্কে অন্যকে শিক্ষিত করার বিষয়ে চিন্তা করার দরকার নেই কারণ "এটি আসলে সেখানে নেই")
  • সম্ভবত আরও ঘনিষ্ঠভাবে বস্তু-মডেলের অনুরূপ
  • কলামটি চিহ্নিত করতে পারে NOT NULLযেন এটি সত্তার প্রয়োজনীয় সম্পত্তি
  • CHECK CONSTRAINTবেস টাইপ টেবিলের উপরে অতিরিক্ত প্রয়োজন নেই তা নিশ্চিত করার জন্য E IS NULLযখন সত্তা টাইপ = C(যদিও এটি কোনও বিশাল লাভ নয়)

কনস

  • এই সম্পত্তিটি পেতে সাব-টাইপ টেবিল (গুলি) -র জন্য JOIN এর প্রয়োজন
  • সম্ভাব্য সামান্য কম দক্ষ যখন প্রয়োজন E, এর কারণে যোগ দিন, কত সারি উপর নির্ভর করে A+ + Bআপনি কত সারির বিরোধিতা আছে Cআছে।
  • ক্রিয়াকলাপগুলির জন্য সামান্যতর জটিল / জটিল যেগুলি কেবলমাত্র সত্তার সাথেই আচরণ করে Aএবং B(এবং না C ) একই "ধরণের" হিসাবে রয়েছে। অবশ্যই, আপনি করতে পারে যে একটি করে কোনো দৃশ্য মাধ্যমে এই বিমূর্ত UNION ALLএকটি মধ্যবর্তী SELECTজন্য যোগ দিয়েছে টেবিল Aএবং অন্য SELECTজন্য যোগদান টেবিল B। এটি SELECT প্রশ্নের জটিলতা হ্রাস করবে তবে এগুলির জন্য সহায়ক INSERTএবং UPDATEপ্রশ্নের জন্য নয় ।
  • নির্দিষ্ট প্রশ্নের উপর নির্ভর করে এবং কত ঘন ঘন তারা কার্যকর করা হয় তার উপর নির্ভর করে এটি ক্ষেত্রে সম্ভাব্য অদক্ষতা হতে পারে যেখানে সূচক থাকা (D, E)সত্যই এক বা একাধিক ঘন ঘন ব্যবহৃত প্রশ্নগুলিকে সাহায্য করবে, কারণ তাদের একসাথে সূচক করা যায় না।

স্বাভাবিক Eবেস ক্লাসের মধ্যে মধ্যস্থতাকারী ছক থেকে বেরিয়ে A&B

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

অনুকূল

  • ডেটা মডেল পুরোপুরি স্বাভাবিক করা হয়েছে (আরডিবিএমএসের যা ডিজাইনের নকশা করা হয়েছে তা এটি দিয়ে অভ্যন্তরীণ কোনও ভুল হতে পারে না)
  • প্রয়োজনীয় জিজ্ঞাসার জন্য কোয়েরি জটিলতা হ্রাস Aএবং B, তবে নয় C(অর্থাত্ দুটি প্রশ্নের প্রয়োজনে যোগ দেওয়া হয়নি UNION ALL)

কনস

  • কিছুটা বেশি জায়গা নেওয়া হয়েছে ( Barটেবিলটি আইডিটিকে নকল করে, এবং সেখানে একটি নতুন কলাম রয়েছে BarTypeCode), [নগন্য, তবে সচেতন হওয়ার মতো কিছু]
  • অতিরিক্ত হিসাবে ক্যোয়ারী জটিলতায় কিছুটা বাড়ার JOINদরকার হয় Aবা হয়B
  • লকিংয়ের জন্য পৃষ্ঠতল বৃদ্ধি, বেশিরভাগ ক্ষেত্রে INSERT( DELETEবিদেশী কী চিহ্নিতকরণের মাধ্যমে স্পষ্টভাবে পরিচালনা করা যায় ON CASCADE DELETE) যেহেতু লেনদেনটি বেস-ক্লাসের টেবিলের (যেমন Foo) [উপেক্ষিত, তবে সচেতন হওয়ার মতো] কিছুটা দীর্ঘ খোলা রাখা হবে ]
  • প্রকৃত প্রকারের সরাসরি জ্ঞান নেই - Aবা B- বেস-শ্রেণীর সারণির মধ্যে Foo; এটি কেবল টাইপ সম্পর্কে জানে Brযেটি হতে পারে Aবা B:

    অর্থ, যদি আপনাকে সাধারণ বেস তথ্যের উপর কোয়েরি করতে হয় তবে সত্তা টাইপের দ্বারা শ্রেণিবদ্ধ করা বা এক বা একাধিক সত্তার প্রকার ফিল্টার করতে হয়, তবে বেস-ক্লাসের সারণীতে পর্যাপ্ত তথ্য নেই, সেক্ষেত্রে আপনার প্রয়োজন টেবিল। এটি কলামটি সূচকের কার্যকারিতাও হ্রাস করবে ।LEFT JOINBarFooTypeCode

  • A& Bবনাম এর সাথে ইন্টারঅ্যাক্ট করার জন্য কোনও সুসংগত পদ্ধতির নয় C:

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

  • সময়ের সাথে পরিবর্তিত ব্যবসায়ের নিয়মের সাথে সামান্য কম অভিযোজ্য:

    অর্থ, জিনিস সর্বদা পরিবর্তিত Eহয় এবং বেস উপ-শ্রেণির সারণীতে উঠে যাওয়া মোটামুটি সহজ, যদি এটি সমস্ত উপ-ধরণের মধ্যে সাধারণ হয়ে ওঠে। সত্তাগুলির প্রকৃতির পরিবর্তন যদি একটি উপযুক্ত সময় পরিবর্তন করে তোলে তবে সাধারণ সম্পত্তিটিকে উপ-প্রকারের বাইরে নিয়ে যাওয়াও যথেষ্ট সহজ। একটি উপ-প্রকারটি দুটি উপ-প্রকারে বিভক্ত করা (কেবলমাত্র অন্য একটি SubTypeIDমান তৈরি করা ) বা দুই বা ততোধিক উপ-প্রকারকে একটিতে সংযুক্ত করা যথেষ্ট সহজ । বিপরীতে, Eপরে যদি সমস্ত উপ-ধরণের একটি সাধারণ সম্পত্তি হয়ে যায়? তারপরে Barটেবিলের মধ্যস্থতাকার স্তরটি অর্থহীন হবে, এবং যুক্ত জটিলতাটি উপযুক্ত হবে না। অবশ্যই, 5 বা 10 বছরের মধ্যেও এই জাতীয় পরিবর্তন ঘটবে কিনা তা জানা অসম্ভব, সুতরাং Barটেবিলটি অগত্যা নয়, বা এমনকি অত্যন্ত খারাপ ধারণাও নেই (যার কারণেই আমি " সম্ভাব্যভাবে কম অভিযোজ্য" বলেছি )। এগুলি কেবল বিবেচনার জন্য বিষয়গুলি; এটি উভয় দিকের জুয়া।

  • সম্ভাব্য অনুপযুক্ত গ্রুপিং:

    অর্থ, Eসম্পত্তি কেবল সত্তার ধরণের মধ্যে ভাগ করা Aএবং এর Bঅর্থ এই নয় Aএবং একসাথে গোষ্ঠীভুক্ত B হওয়া উচিত । জিনিসগুলি "চেহারা" একইরূপে (অর্থাত্ একই বৈশিষ্ট্যগুলি) বোঝায় না যে তারা একই।

সারসংক্ষেপ

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

  • প্রতিটি অ্যান্টিটি টাইপের জন্য আপনার কত সারি থাকবে (গড় বর্ধনের উপরে ধরে ধরে রাস্তায় কমপক্ষে 5 বছর দেখুন)
  • এই টেবিলগুলির প্রতিটি (বেস-টাইপ এবং উপ-প্রকার) কত জিবি হবে 5 বছরে?
  • নির্দিষ্ট ডেটাটাইপ সম্পত্তি কি E
  • এটি কি কেবল একটি সম্পত্তি বা কয়েকটি, বা এমনকি বেশ কয়েকটি বৈশিষ্ট্য রয়েছে?
  • আপনার কী জিজ্ঞাসাগুলির প্রয়োজন হবে Eএবং এটি কতবার কার্যকর করা হবে
  • আপনার কী জিজ্ঞাসাগুলির প্রয়োজন হবে যা প্রয়োজন হয় না Eএবং কতক্ষণ তাদের কার্যকর করা হবে

আমি মনে করি Eপৃথক সাব-টাইপ টেবিলগুলি রাখার ক্ষেত্রে আমি ডিফল্ট হয়ে পড়েছি কারণ এটি খুব কমপক্ষে, "ক্লিনার"। আমি Eবেস-টাইপ টেবিলের দিকে যেতে বিবেচনা করব যদি IF: সারিগুলির বেশিরভাগটি এন্টি টাইপের জন্য ছিল নাC ; এবং সারি সংখ্যা কমপক্ষে কয়েক মিলিয়ন ছিল; এবং আমি প্রায়শই প্রায়শই সম্পাদিত হয় না এমন প্রশ্নের জন্য যেগুলি প্রয়োজন হয় Eএবং / অথবা যে (D, E)সূত্রগুলি খুব ঘন ঘন সঞ্চালিত হয় এবং / অথবা পর্যাপ্ত সিস্টেমের সংস্থান প্রয়োজন যেমন সূচকটি সামগ্রিক সম্পদের ব্যবহার হ্রাস করে বা কমপক্ষে প্রতিরোধ করে সংস্থান গ্রহণের পরিমাণ বৃদ্ধি পায় যা গ্রহণযোগ্য স্তরের উপরে চলে যায় বা অত্যধিক অবরুদ্ধকরণ এবং / অথবা ডেডলকগুলিতে বৃদ্ধি পেতে যথেষ্ট দীর্ঘস্থায়ী হয়।


হালনাগাদ

ওপি এই উত্তরে মন্তব্য করেছেন যে:

আমার নিয়োগকর্তারা ব্যবসার যুক্তি পরিবর্তন করে, পুরোপুরি ই সরিয়ে!

এই পরিবর্তনটি বিশেষভাবে গুরুত্বপূর্ণ কারণ এটি হ'ল আমি পূর্বাভাসটি হ'ল " Eবেস " Aএবং B"বিভাগের মধ্যবর্তী বিভাগের মধ্যে" মধ্যবর্তী সারণিকে সাধারণীকরণ "(6th ষ্ঠ বুলেট পয়েন্ট) এর" CONs "উপধারাতে ঘটতে পারে । নির্দিষ্ট সমস্যাটি হ'ল যখন এই জাতীয় পরিবর্তনগুলি ঘটে (এবং তারা সর্বদা করে) তখন ডেটা মডেলটিকে রিফেক্টর করা কতটা সহজ / কঠিন। কিছু তর্ক করবে যে কোনও ডেটা মডেল রিফ্যাক্টর / পরিবর্তন করা যায়, তাই আদর্শ দিয়ে শুরু করুন। প্রযুক্তিগত পর্যায়ে এটি সত্য যে কোনও কিছুর সংশোধন করা যেতে পারে, তবে পরিস্থিতিটির বাস্তবতা একটি মাত্রার বিষয়।

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

এই বিষয়টি মাথায় রেখে, যদি ডেটার আকারটি এমন ছোট হয় যে পরিবর্তনগুলি খুব কোয়েরি করা যায়, এবং / অথবা আপনার একটি রক্ষণাবেক্ষণ উইন্ডো রয়েছে যা কেবলমাত্র পরিবর্তন করতে যথেষ্ট নয় তবে কিছু চলে গেলে রোল-ব্যাকও করতে পারে ভুল, তারপর স্বাভাবিক Eবেস ক্লাসের টেবিল এবং মধ্যে মধ্যস্থতার ছক থেকে বেরিয়ে A& Bউপ-বর্গ টেবিল কাজ করতে পারে (নির্দিষ্ট ধরণের কোন সরাসরি জ্ঞান যদিও এখনও পাতার আপনি ( AবাB) বেস-ক্লাসের টেবিলটিতে)। কিন্তু, যদি এই টেবিলগুলিতে আপনার কয়েক মিলিয়ন সারি থাকে, এবং সারণীগুলিকে উল্লেখ করে একটি অবিশ্বাস্য পরিমাণ কোড থাকে (পরিবর্তনগুলি করার সময় পরীক্ষা করতে হয় এমন কোড), তবে এটি সাধারণত আদর্শবাদীর চেয়ে বেশি বাস্তববাদী হতে পারে। এবং এই পরিবেশটি যা আমাকে বছরের পর বছর ধরে মোকাবেলা করতে হয়েছিল: 98 সার্ভিস জুড়ে বেস-ক্লাসের টেবিলটিতে 987 মিলিয়ন সারি এবং 615 জিবি। এবং এতগুলি কোড এই টেবিলগুলিকে আঘাত করেছে (বেস-ক্লাস এবং উপ-শ্রেণীর টেবিলগুলি) যে প্রতিরোধের অনেক ছিল - বেশিরভাগ পরিচালনা থেকে তবে কখনও কখনও দলের বাকী অংশ থেকে - উন্নয়নের পরিমাণের কারণে কোনও পরিবর্তন করতে এবং কিউএ সংস্থানগুলি বরাদ্দ করা দরকার।

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

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


17

মার্টিন ফাউলারের মতে, টেবিলের উত্তরাধিকারের সমস্যার জন্য 3 টি পদ্ধতি রয়েছে:

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

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

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


@ অ্যালওয়েস লেয়ার্নিং নিউস্টফ আমার মনে হয় এই প্রশ্নটি ডিবিএস্ট্যাকেক্সেঞ্জার / প্রশ্নস / ১৩৯৯৯২ , সঠিক? বাস্তবায়ন সেখানে আপনি কি টেবিল উত্তরাধিকার আছে।
রেমাস রুসানু

হ্যাঁ, এই প্রশ্নটি জিজ্ঞাসা করার আগে আমি নিশ্চিত করতে চেয়েছিলাম যে আমি প্রথমে টাইপ / সাব টাইপ ডিজাইনটি কীভাবে প্রয়োগ করতে পারি তা সঠিকভাবে বুঝতে পেরেছি। যখন কিছু (তবে সব নয়!) সাবক্লাসগুলি বৈশিষ্ট্যগুলি ভাগ করে নিয়েছে তখন আমি উপরের বর্ণিত সমস্যার মুখোমুখি । আমি ভাবছিলাম যে সেই
উপায়ে

6

আপনার স্পেসিফিকেশনগুলির আমার ব্যাখ্যা অনুসারে, আপনি দুটি পৃথক (তবে সংযুক্ত ) সুপার টাইপ-সাব-টাইপ কাঠামো বাস্তবায়নের জন্য একটি পদ্ধতি খুঁজে পেতে চান ।

অর্ডার aformentioned টাস্ক অর্জন করার একটি পন্থা এক্সপোজ করতে, আমি দুই সর্বোত্তম সমস্যাপূর্ণ দৃশ্যকল্প যোগ করতে যাচ্ছি প্রকল্পিত সত্তা ধরনের নামক Fooএবং Bar, যা আমি বিস্তারিত নিচে হবে।

ব্যবসার নীতি

এখানে কয়েকটি বিবৃতি দেওয়া হয়েছে যা আমাকে একটি লজিকাল মডেল তৈরি করতে সহায়তা করবে:

  • A Foo is either one Bar or one C
  • A Foo is categorized by one FooType
  • A Bar is either one A or one C
  • A Bar is classified by one BarType

যৌক্তিক মডেল

এবং তারপরে, ফলাফল IDEF1X [1] লজিকাল মডেলটি চিত্র 1 এ দেখানো হয়েছে (এবং আপনি এটি ড্রপবক্স থেকে পিডিএফ হিসাবেও ডাউনলোড করতে পারেন ):

চিত্র 1 - হাইপোথিটিক্যাল সুপারটাইপ-সাব-টাইপ রিলেশনশিপ ডেটা মডেল

ফু ও বার সংযোজন

আমি যোগ হয়নি Fooএবং Barমডেল বর্ণন ভাল করতে, কিন্তু এটা আরো ভাবপূর্ণ করতে। আমি নিম্নলিখিতগুলির কারণে এগুলি গুরুত্বপূর্ণ বলে মনে করি:

  • নামযুক্ত বৈশিষ্ট্য হিসাবে Aএবং Bভাগ করে নেওয়ার ফলে E, এই বৈশিষ্ট্যটি বোঝায় যে এগুলি স্বতন্ত্রতা (তবে সম্পর্কিত) ধরণের ধারণা , ইভেন্ট , ব্যক্তি , পরিমাপ ইত্যাদির ধরণের, যা আমি Barউপজাতীয় ধরণের মাধ্যমে উপস্থাপন করি যা পরিবর্তিত হয় একটি subentity ধরণের Foo, যা Dস্তরক্রমের শীর্ষে বৈশিষ্ট্যটি ধারণ করে ।

  • যেহেতু Cআলোচ্য সত্তা ধরনের, বাকি সঙ্গে শুধুমাত্র শেয়ার একটি অ্যাট্রিবিউট অর্থাত, Dএই দৃষ্টিভঙ্গি insinuates এটি আরেকটি ধরনের একটি subentity ধরনের ধারণা , ঘটনা , ব্যক্তি , পরিমাপ , ইত্যাদি আমি তাই শক্তি কর্মদক্ষতার দ্বারা এই পরিস্থিতিতে ফোটানো Fooসুপার সত্তা প্রকার।

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

নকশা পর্যায়ে গুরুত্বপূর্ণ বিষয়গুলি

এই সত্যটি সম্পর্কে সচেতন হওয়া বেশ কার্যকর যে সমস্ত পরিভাষা একপাশে রেখে একচেটিয়া সুপারটাইপ-সাব-টাইপ ক্লাস্টারটি একটি সাধারণ সম্পর্ক। আসুন পরিস্থিতিটি নিম্নলিখিত উপায়ে বর্ণনা করি:

  • প্রতিটি এক্সক্লুসিভ সাপোরেন্টিটি টাইপ সংঘটন কেবলমাত্র একটি সাবেন্টিটি টাইপের পরিপূরক সম্পর্কিত।

সুতরাং, এই ক্ষেত্রে ওয়ান-টু-ওয়ান (1: 1) এর একটি চিঠিপত্র (বা কার্ডিনালিটি) রয়েছে।

আপনি আপনার পূর্ববর্তী পোস্ট থেকে জানি, discriminator অ্যাট্রিবিউট (কলাম, যখন বাস্তবায়িত) একটি প্যারামাউন্ট ভূমিকা পালন করে একটি তৈরি সমিতি এই প্রকৃতির, কারণ এটি সঠিক উপপ্রকার উদাহরণস্বরূপ যা দিয়ে supertype হয় ইঙ্গিত সংযুক্ত । (Ii) সুপারটাইপ থেকে (ii) উপপ্রকারগুলিতে প্রাথমিক কী এর স্থানান্তরও প্রধান তাত্পর্যপূর্ণ।

কংক্রিট ডিডিএল কাঠামো

এবং তারপরে আমি একটি ডিডিএল কাঠামো লিখেছি যা উপরের উপস্থাপিত যৌক্তিক মডেলের উপর ভিত্তি করে:

CREATE TABLE FooType -- Look-up table.
(
    FooTypeCode     CHAR(2)  NOT NULL,
    Description     CHAR(90) NOT NULL, 
    CreatedDateTime DATETIME NOT NULL,
    CONSTRAINT PK_FooType             PRIMARY KEY (FooTypeCode),
    CONSTRAINT AK_FooType_Description UNIQUE      (Description)
);

CREATE TABLE Foo -- Supertype
(
    FooId           INT      NOT NULL, -- This PK migrates (1) to ‘Bar’ as ‘BarId’, (2) to ‘A’ as ‘AId’, (3) to ‘B’ as ‘BId’, and (4) to ‘C’ as ‘CId’.
    FooTypeCode     CHAR(2)  NOT NULL, -- Discriminator column.
    D               INT      NOT NULL, -- Column that applies to ‘Bar’ (and therefore to ‘A’ and ‘B’) and ‘C’.
    CreatedDateTime DATETIME NOT NULL,
    CONSTRAINT PK_Foo                 PRIMARY KEY (FooId),
    CONSTRAINT FK_from_Foo_to_FooType FOREIGN KEY (FooTypeCode)
        REFERENCES FooType (FooTypeCode)
);

CREATE TABLE BarType -- Look-up table.
(
    BarTypeCode CHAR(1)  NOT NULL,  
    Description CHAR(90) NOT NULL,  
    CONSTRAINT PK_BarType             PRIMARY KEY (BarTypeCode),
    CONSTRAINT AK_BarType_Description UNIQUE      (Description)
);

CREATE TABLE Bar -- Subtype of ‘Foo’.
(
    BarId       INT     NOT NULL, -- PK and FK.
    BarTypeCode CHAR(1) NOT NULL, -- Discriminator column. 
    E           INT     NOT NULL, -- Column that applies to ‘A’ and ‘B’.
    CONSTRAINT PK_Bar             PRIMARY KEY (BarId),
    CONSTRAINT FK_from_Bar_to_Foo FOREIGN KEY (BarId)
        REFERENCES Foo (FooId),
    CONSTRAINT FK_from_Bar_to_BarType FOREIGN KEY (BarTypeCode)
        REFERENCES BarType (BarTypeCode)    
);

CREATE TABLE A -- Subtype of ‘Bar’.
(
    AId INT NOT NULL, -- PK and FK.
    X   INT NOT NULL, -- Particular column.  
    CONSTRAINT PK_A             PRIMARY KEY (AId),
    CONSTRAINT FK_from_A_to_Bar FOREIGN KEY (AId)
        REFERENCES Bar (BarId)  
);

CREATE TABLE B -- (1) Subtype of ‘Bar’ and (2) supertype of ‘A’ and ‘B’.
(
    BId INT NOT NULL, -- PK and FK.
    Y   INT NOT NULL, -- Particular column.  
    CONSTRAINT PK_B             PRIMARY KEY (BId),
    CONSTRAINT FK_from_B_to_Bar FOREIGN KEY (BId)
        REFERENCES Bar (BarId)  
);

CREATE TABLE C -- Subtype of ‘Foo’.
(
    CId INT NOT NULL, -- PK and FK.
    Z   INT NOT NULL, -- Particular column.  
    CONSTRAINT PK_C             PRIMARY KEY (CId),
    CONSTRAINT FK_from_C_to_Foo FOREIGN KEY (FooId)
        REFERENCES Foo (FooId)  
);

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

নিখরচায়তা, ধারাবাহিকতা এবং অন্যান্য বিবেচনা

একবার আপনি আপনার ডাটাবেস বাস্তবায়ন করেন, তাহলে আপনি অবশ্যই নিশ্চিত করতে হবে যে (ক) প্রতিটি একচেটিয়া supertype সারি সবসময় তার সংশ্লিষ্ট দ্বারা complemented হয় উপপ্রকার সহযোগীর এবং, ঘুরে, নিশ্চয়তা (খ) উক্ত উপপ্রকার সারি মান সঙ্গে সামঞ্জস্যপূর্ণ supertype অন্তর্ভুক্ত discriminator কলাম । অতএব, TRANSACTIONSএই শর্তগুলি আপনার ডাটাবেসে পূরণ হয়েছে তা নিশ্চিত করার জন্য এটি এসিডি নিয়োগ করা বেশ সুবিধাজনক ।

আপনার আপনার ডাটাবেসের যৌক্তিক দৃ sound়তা, স্ব-প্রকাশ এবং যথার্থতা ছেড়ে দেওয়া উচিত নয়, এগুলি এমন দিক যা স্থির করে আপনার ডাটাবেসটিকে আরও দৃ make় করে তোলে।

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

দৃশ্য সংজ্ঞা দিয়ে ডেটা পুনরুদ্ধার করা

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

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

সম্পর্কিত সংস্থানসমূহ

আপনি যদি এমন কোনও বিস্তৃত ডাটাবেস বিশ্লেষণ করতে চান যা সুপারটাইপ-সাব-টাইপ সম্পর্কের সাথে জড়িত, আপনি নীচের স্ট্যাক ওভারফ্লো প্রশ্নগুলিতে @ পারফরম্যান্সডিবিএ প্রস্তাবিত অসাধারণ উত্তরগুলির মূল্য খুঁজে পাবেন :


বিঃদ্রঃ

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


আমার নিয়োগকর্তারা Eসম্পূর্ণরূপে অপসারণ করে ব্যবসায় যুক্তি বদলেছেন ! ব্যবহারকারীর শ্রুতজকির জবাব গ্রহণ করার কারণ হ'ল কারণ এটি ভাল পয়েন্ট দেয় যা আমাকে সবচেয়ে দক্ষ রুটটি বেছে নেওয়ার সিদ্ধান্ত নিতে সহায়তা করে। যদি না হয় তবে আমি আপনার উত্তরটি গ্রহণ করব। আমি আপনার উত্তরটি আগেই উন্নীত করেছি। আবার ধন্যবাদ!
সর্বদা লার্নিং নিউস্টফ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.