ওয়ান-টু-ওয়ান সম্পর্ক কী স্বাভাবিক?

বিবেচনা করুন আমাদের কাছে একটি রেকর্ডের জন্য পরিসংখ্যানের ডেটা রয়েছে; যেমন 20-30 INTকলাম। পুরো সেটটি এক টেবিলের মধ্যে রাখা ভাল কারণ সেগুলি সমস্তই একটি রেকর্ডের অন্তর্ভুক্ত বা অন্য টেবিল তৈরি করে একে অপরের সাথে সম্পর্কের সাথে যুক্ত।

প্রাক্তনটির সুবিধা হ'ল JOINসংশ্লিষ্ট রেকর্ডের জন্য সমস্ত পরিসংখ্যানের ডেটা এড়ানো এবং দ্রুত অ্যাক্সেস পাওয়া।

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

সাধারণভাবে আমি জানতে চাই যে একটি একক রেকর্ডের জন্য বিভিন্ন সেট ডেটা আলাদা করা কার্যকর কি কার্যকর?

— Googlebot এক
সূত্র

'নরমালাইজড' এর অর্থ প্রথম সাধারণ ফর্ম (1NF) এবং এটি সম্পর্কিত সম্পর্কিত মডেলের একটি মৌলিক প্রয়োজনীয়তা। 'সম্পূর্ণরূপে স্বাভাবিককরণ' এর অর্থ 5NF বা তারও বেশি। আপনার প্রস্তাবিত 'ওয়ান-টু-ওয়ান রিলেশনশিটি' সারণীতে আপনার বর্তমানের চেয়ে উচ্চতর স্বাভাবিক ফর্মের (সম্ভবত 6NF- তেও) ভাল হওয়ার সম্ভাবনা রয়েছে কারণ এটি পচে গেছে! আপনার বিদ্যমান সারণীটি কোন সাধারণ ফর্মগুলি পূরণ করে?

— onedaywhen

@ ছেয়ে যাওয়া যখন অন্য অনেকের মতো আমি ধাপে ধাপে নরমালাইজেশন অনুসরণ করি না, কারণ কখনও কখনও ডি-নরমালাইজেশনও সহায়ক is সাধারণভাবে, পুরো ডাটাবেসের 3NF - 5NF এর মধ্যে একটি স্বাভাবিককরণের স্তর হওয়া উচিত (4NF নিয়ে আমার সর্বদা সমস্যা হয়!)

— গুগলবোট

উত্তর:

যদি এটি সাধারণীকরণের নিয়মের মধ্যে খাপ খায় তবে 1: 1 টি সম্পর্ককে স্বাভাবিক করা যায় (সংজ্ঞায়!) - অন্য কথায়, 1: 1 সম্পর্কে এমন কিছু নেই যা তাদের পক্ষে স্বাভাবিক রূপগুলি মান্য করা অসম্ভব করে তোলে।

1: 1 সম্পর্কের ব্যবহারিকতা সম্পর্কে আপনার প্রশ্নের জবাব দেওয়ার জন্য, এমন সময়গুলি আসে যখন এটি পুরোপুরি কার্যকর নির্মাণ, যেমন আপনার স্বতন্ত্র পূর্বাভাস (কলাম) সহ সাব টাইপগুলি থাকে।

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

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

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

— জোল ব্রাউন
সূত্র

You have some subset of columns that are very wide and you want to segregate them physically in your storage for performance reasons.

কীভাবে তাদের আলাদা করে দেওয়া পারফরম্যান্সে উন্নতি করে (ধরে নেওয়া যায় যে মূল টেবিলটি প্রতিটি সময় কলামগুলি সর্বদা অ্যাক্সেস করা থাকে)?

— গিলি

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

— জোয়েল ব্রাউন

ডিজাইনের কারণে (উদ্বেগের বিচ্ছেদ, কোডের পুনঃব্যবহারের বর্ধিততা) জন্য আমি সাধারণত ব্যবহৃত কলামগুলি পৃথক করতে চাই। কেউ কি এই জাতীয় যোগদানের ব্যয়ের একটি অনুমান পোস্ট করেছেন? এগুলি কি নগণ্য বা আমার দীর্ঘমেয়াদী সম্পর্কে চিন্তা করা উচিত?

— গিলি

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

— জোয়েল ব্রাউন

আমি করেছি, এবং অবাক করার ফলাফল পেয়েছি: dba.stackexchange.com/q/74693/4719 আমি স্বীকার করি যে এটি সাধারণীকরণের একটি আদর্শ উদাহরণ নয়, তবে এটি জয়নগুলি (এখনও) খুব ব্যয়বহুল তা হাইলাইট করে না।

— গিলি

আপনি একটি বড় টেবিলকে দুটি ভাগে ভাঙতে ওয়ান-টু ওয়ান ম্যাপিং ব্যবহার করার প্রধান কারণগুলি পারফরম্যান্স কারণে রয়েছে:

ক) টেবিলটিতে ঘন ঘন অ্যাক্সেস করা টেবিলটিতে বাইনারি / ক্লোব / ব্লব ডেটা থাকে তাই বৃহত্তর কলামগুলি অন্যভাবে পরিচালনা করা হওয়ায় কার্যকারিতাটি কমিয়ে দেয়।

খ) টেবিলটিতে অনেকগুলি কলাম রয়েছে যা বিভিন্ন ক্যোয়ারী দ্বারা অ্যাক্সেস করা হয়, সুতরাং কার্য সম্পাদন হ্রাস করা হয় তাই আপনি অ্যাক্সেস পারফরম্যান্সের উন্নতির জন্য সম্পর্কিত কলামগুলিকে পৃথক টেবিলের দিকে নিয়ে যেতে পারবেন

তবে অনেকগুলি সংখ্যক কলাম থাকা আলাদা আলাদা টেবিলগুলিতে টেবিলটি ভাঙ্গার এবং সেগুলি অনুসন্ধান করার অতিরিক্ত প্রচেষ্টাটিকে ন্যায়সঙ্গত করে না।

— স্টিফেন সেনকোমাগো মুসোকে
সূত্র

ইস্যু স্পষ্ট করার জন্য খুব ভাল পয়েন্ট!

— গুগলবট