এমন কোনও সময় আছে যেখানে ডেটাবেস 1: 1 ব্যবহার করে বোঝা যায়?


162

আমি অন্য দিন স্বাভাবিকায়নের বিষয়ে ভাবছিলাম, এবং এটি আমার কাছে ঘটেছিল, আমি এমন একটি সময় ভাবতে পারি না যেখানে একটি ডাটাবেসে 1: 1 সম্পর্ক থাকা উচিত।

নাম: এসএসএন? আমি তাদের একই টেবিলে রাখতাম পার্সোনাইড: অ্যাড্রেসআইডি? আবার, একই টেবিল।

আমি 1 এর বহু মিলিয়ন উদাহরণ নিয়ে আসতে পারি: অনেক বা অনেকগুলি: অনেকগুলি (উপযুক্ত মধ্যবর্তী টেবিল সহ), তবে কখনও 1: 1 নয়।

আমি কি স্পষ্ট কিছু মিস করছি?


7
এসএসএন এর কোনও অনন্য নম্বর নয়। তারা পুনরায় ব্যবহার করা হয়।

এটি পৃথক করা হলে ডাটাবেসটিকে একাধিক শারীরিক ডিভাইসে বিভক্ত করা সহজ।
পেসারিয়ার

2
দয়া করে উপরে একটি সত্যই পুরানো মন্তব্যে একটি মন্তব্য ক্ষমা করুন: এসএসএন এর পুনরায় ব্যবহার করা হয় না এবং বাস্তবে কোনও ব্যক্তিকে সনাক্ত করতে পারে ly
ডেরেক

সত্য, তবে কিছু ব্যাক-অফ-খামের গণিতের ভিত্তিতে, সম্ভাব্য সংখ্যার প্রায় অর্ধেক ইতিমধ্যে জারি করা হয়েছে। এসএসএ দাবি করেছে যে আরও কয়েক প্রজন্মের জন্য প্রচুর পরিমাণে থাকবে তবে নীতি / আইন পরিবর্তন না হলে তারা অচিরেই বা সংখ্যার বাইরে চলে যাবে। এখানে আরও সন্ধান করুন: ssa.gov/history/hfaq.html
পালসহেড

2
আপনি মাত্র কল্পনা করতে পারেন যে ২৩:১০ থেকে ২৩:৩০ এর মধ্যে 5 ফেব্রুয়ারী '09-এ মার্ক ব্র্যাডি কী ধরণের মেজাজে ছিলেন। হে হে।
রবার্ট

উত্তর:


161

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

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

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

শারীরিক বিভাজন কার্যকর হতে পারে যখনই আপনার কাছে এমন কোয়েরি থাকে যেখানে বৃহত্তর সত্তার ধারাবাহিক সাবসেটের প্রয়োজন হয়।


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

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

@ ওচাডো যখন আমি সম্মত হই যে আপনার 1: 1 এর জন্য প্রাকৃতিকভাবে অনেকগুলি (শারীরিক-শারীরিক) কারণ রয়েছে তবে ক্যাভেট "যদি আপনার historicalতিহাসিক তথ্য না থাকে" এই ঘটনাগুলিকে আমি সম্ভবত 1: 1 এর সাথে ব্যবহার করব না এমনটি করে তোলে জোরদার করা।
Godeke

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

প্রকৃতপক্ষে, আইএস-এ এবং মেলা সংরক্ষণের পরিস্থিতিগুলিও সম্ভবত 1: 1 থেকে যাবে, এমনকি .তিহাসিক ডেটা সংরক্ষণ করা থাকলেও।
ত্রিপরিটো

125

একটি কারণ হ'ল ডাটাবেস দক্ষতা। 1: 1 টি সম্পর্ক থাকার ফলে আপনাকে ক্ষেত্রগুলি বিভক্ত করতে দেয় যা সারি / টেবিল লক চলাকালীন প্রভাবিত হবে। যদি টেবিল এ এর ​​এক টন আপডেট থাকে এবং টেবিল বিতে এক টন রিড থাকে (বা অন্য অ্যাপ্লিকেশন থেকে এক টন আপডেট পাওয়া যায়), তবে টেবিল এ এর ​​লকটি টেবিল বিতে কী চলছে তা প্রভাবিত করবে না affect

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

এটি সম্পর্কে আমার ব্লগ এন্ট্রি।


1
হ্যাঁ আমি আশা করি ওপি এটি দ্বিতীয় স্বীকৃত উত্তর হিসাবে চিহ্নিত করতে পারে। আমার প্রথম চিন্তা, এই প্রশ্নটি পড়ার সময়, "সারি লকস" ছিল।
রিকিট

47

বিরলতা। ডেটা সম্পর্কটি প্রযুক্তিগতভাবে 1: 1 হতে পারে তবে প্রতিটি সারিটির জন্য সংশ্লিষ্ট সারিগুলির অস্তিত্ব থাকতে হবে না। সুতরাং আপনার যদি বিশ মিলিয়ন সারি থাকে এবং মানগুলির কিছু সেট থাকে যা কেবলমাত্র তাদের 0.5% এর জন্য বিদ্যমান থাকে, আপনি যদি সেই কলামগুলিকে একটি সারণীতে সরিয়ে রাখেন তবে স্থান সঞ্চয় বিশাল হয়।


8
"তবে প্রতিটি সারিটির জন্য সংশ্লিষ্ট সারিগুলির অস্তিত্ব থাকতে হবে না" তবে এটি 1: 1 নয়। আপনি 1: 0,1 এর কথা বলছেন।

1
হ্যাঁ। ডুনো যদি ওপি পার্থক্য আঁকেন।
বিশৃঙ্খলা

2
ঠিক আছে, আমি ধরে নিয়েছি যে তারা এগুলি করেছে কারণ 1: 0,1 এর সাথে আপনার ব্যবহারের প্রচুর ব্যবহার রয়েছে তবে 1: 1 এর পরিমাণ আরও কম। এবং তারা ব্যবহারগুলি সন্ধানের জন্য লড়াই করছিল, তাই আমি বলব যে ওপি পার্থক্যটি আঁকছিল।

12
আমার কাজের অনুমানটি বিপরীত ছিল কারণ তিনি 1: 1, 1: অনেক এবং অনেকগুলি: 1: 0,1 উল্লেখ না করে গণনা করেছেন।
বিশৃঙ্খলা

26

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

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

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

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

  • কিছু ধরণের দুর্লভ সংস্থান বরাদ্দ , উদাহরণস্বরূপ একজন কর্মীকে একবারে কেবলমাত্র একটি কোম্পানির গাড়ি বরাদ্দ করা যেতে পারে (উদাহরণস্বরূপ ট্র্যাকার প্রতি একটি ট্রাক, ক্যাব ড্রাইভারের জন্য একটি ট্যাক্সি, ইত্যাদি)। একজন সহকর্মী আমাকে সম্প্রতি এই উদাহরণ দিয়েছেন।

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

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

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

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


2
কম্পিউটারের শারীরিক প্রকৃতির মতো পার্থিব কারণে যখন এ জাতীয় সম্পর্ক সঠিক হয় এবং কখন তা কার্যকর হয় না সে সম্পর্কে আপনি কীভাবে মূল প্রশ্ন চেতনায় আটকে গেছেন তা আমি সত্যিই পছন্দ করি।
ব্যবহারকারী 1852503

21

আপনার প্রশ্নের বিভিন্নভাবে ব্যাখ্যা করা যেতে পারে, আপনি যেভাবে এটি শব্দটি বলেছিলেন সে কারণে। প্রতিক্রিয়াগুলি এটি দেখায়।

বাস্তব বিশ্বে ডেটা আইটেমগুলির মধ্যে অবশ্যই 1: 1 টি সম্পর্ক থাকতে পারে। এটি সম্পর্কে কোন প্রশ্ন। "একটি" সম্পর্কটি সাধারণত একটির সাথে এক হয়। গাড়ি একটি বাহন। একটি গাড়ি একটি গাড়ি। একটি গাড়ি এক গাড়ি হতে পারে। কিছু গাড়ি ট্রাক হয়, এক্ষেত্রে একটি গাড়ি গাড়ি নয়। বেশ কয়েকটি উত্তর এই ব্যাখ্যাকে সম্বোধন করে।

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

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

সাধারণীকরণের একটি স্তর রয়েছে যার নাম 6NF। 6NF এর স্বাভাবিককরণের নিয়মটি অবশ্যই একই প্রাথমিক কী সহ দুটি টেবিল তৈরি করতে পারে। 6NF 5NF এর চেয়ে বেশি সুবিধা পেয়েছে যে নুল সম্পূর্ণরূপে এড়ানো যায়। এটি কারও কাছে ডেটাবেস ডিজাইনারের পক্ষে গুরুত্বপূর্ণ important আমি কখনই 6NF এ স্কিমা লাগিয়ে বিরক্ত করিনি।

6NF- এ অনুপস্থিত ডেটা কিছু কলামে NULL সহ একটি সারির পরিবর্তে বাদ দেওয়া সারি দ্বারা প্রতিনিধিত্ব করা যেতে পারে।

বিভাজক টেবিলগুলির স্বাভাবিককরণ ছাড়াও অন্যান্য কারণ রয়েছে। কখনও কখনও বিভক্ত টেবিলের ফলে আরও ভাল পারফরম্যান্স হয়। কিছু ডাটাবেস ইঞ্জিনের সাহায্যে আপনি টেবিলটি ভাগ করে না দিয়ে ভাগ করে ভাগ করে একই কর্মক্ষমতা সুবিধা পেতে পারেন। ডাটাবেস ইঞ্জিনকে জিনিসগুলি দ্রুত করার জন্য প্রয়োজনীয় সরঞ্জামগুলি দেওয়ার সময় লজিকাল ডিজাইনটি সহজেই বোঝার পক্ষে এটি সুবিধা থাকতে পারে।


19

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

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


1
বাস্তব শব্দের উদাহরণের জন্য @ শানড +1 করুন। আমি "কেবল পঠনযোগ্য" পার্থক্যটিও পছন্দ করি।
মাইকেল রিলে - এ কেএ গুনি

13

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


সিরিয়াসলি? সাধারণত সেরা উপায় না? একক বৃহত্তম অনলাইন সঙ্গীত বিক্রেতাই এটি, অহেম, এমপি 3 এর একটি ডেটাবেজে সঞ্চয় করে।

1
@ মার্ক, ইমেজ সংরক্ষণের সর্বোত্তম উপায়ে কোনও ডাটাবেসে বা বাইরে ব্যবহার করার জন্য কয়েকটি প্রশ্ন রয়েছে এবং seemsক্যমত্যটি মনে হয় যে বেশিরভাগ ক্ষেত্রে ফাইল সিস্টেমটি দ্রুত is আমি ভাবছি যদি এটি সত্য হয় তবে এমপি 3 এর ক্ষেত্রেও এটি সত্য হবে।
জেমস ম্যাকমাহন 19

1
"আপনি সাধারণত একটি আলাদা টেবিলের মধ্যে বিএলওবি চাইবেন" - সাধারণত বিএলওবি'র ইনলাইন সংরক্ষণ করা হয় না (যদি তারা নির্দিষ্ট ডিবি-নির্দিষ্ট সারি দৈর্ঘ্য অতিক্রম করে)। বিএনএলবিগুলি যদি ইনলাইন না হয় তবে সাধারণত ডিবি-পৃষ্ঠাগুলিতে তাদের শারীরিক অবস্থানের জন্য 'পয়েন্টার' হিসাবে সংরক্ষণ করা হয়।
blispr

1
এটি একটি বিতর্কিত যে কোনও ডেটাবেজে বড় ডেটা (ফাইল) সংরক্ষণ করা অর্থবোধ করে কিনা, কারও কারও কারও পক্ষে বৈধ কারণ রয়েছে, তবে 1: 1 এর উদাহরণের জন্য +1 রয়েছে।
কেভিন পেনো

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

9

বিশুদ্ধ বিজ্ঞানের ক্ষেত্রে, হ্যাঁ, তারা অকেজো।

সত্যিকারের ডাটাবেসে কখনও কখনও বিরল ব্যবহৃত ক্ষেত্রকে আলাদা টেবিলের মধ্যে রাখার জন্য দরকারী: এটি এবং কেবলমাত্র এই ক্ষেত্রটি দিয়ে কোয়েরি বাড়ানোর জন্য; তালা ইত্যাদি এড়ানোর জন্য


3
@ মার্ক ব্র্যাডি: না, এটি নেই, যেমন না 2 এসও 4 এবং কেসিএল রয়েছে। একটি মহাবিশ্ব ডাটাবেস তৈরি করার সময়, আপনি t_atom (আইডি INT, প্রোটন INT, নিউট্রন INT), t_molecule (আইডি INT, atom_id INT) তৈরি এবং যোগদান করা উচিত। এটি একের সাথে একাধিক সম্পর্ক।
কাসনসুই

2
দ্বিতীয় চিন্তায়, আইএনটি এখানে যথেষ্ট না পারে, কারণ মহাবিশ্বে 10 ^ 78 পরমাণু রয়েছে। এমনকি দু'টি জিইউডি একত্রে আটকানো পরমাণুর মাত্র 1/10 তম থাকতে পারে। আমাদের একটি RAW (40) প্রাথমিক কী লাগবে - কেবলমাত্র যদি আমাদের ডাটাবেস খুব দ্রুত বৃদ্ধি পায়। অন্ধকার ব্যাপার, আপনি কিছু জানেন।
কাসনসুই

1
ওহ, সুতরাং কেবলমাত্র সম্পর্কিত তত্ত্ব খাঁটি বিজ্ঞান। বুঝতে পারিনি যে রসায়ন কোনও বিশুদ্ধ বিজ্ঞান না হলে যদি না আমরা এর জন্য একটি ডেটাবেস তৈরি করি।

1
@ মার্ক ব্র্যাডি: আপনি কি দয়া করে কেবল এটি বলতে পারলেন না যে আপনি যার সাথে একমত নন? আমি আসলেই আপনার
কট্টরতা পাচ্ছি

কাসনসুই (এবং মার্ক ব্র্যাডি) আপনি আমাকে যে এলএল দিয়েছিলেন সেটির জন্য আপনি একটি উত্সাহ পাবেন।
পালসহেড

8

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


8

আমি এমন পরিস্থিতিতেও ভাবতে পারি যেখানে আপনার ওও মডেল রয়েছে যেখানে আপনি উত্তরাধিকার ব্যবহার করেন এবং উত্তরাধিকার গাছটি ডিবিতে বহাল রাখতে হয়।

উদাহরণস্বরূপ, আপনার কাছে একটি ক্লাস বার্ড এবং ফিশ রয়েছে যা উভয়েরই প্রাণীর উত্তরাধিকার সূত্রে প্রাপ্ত। আপনার ডিবিতে আপনার একটি 'অ্যানিম্যাল' টেবিল থাকতে পারে, যাতে প্রাণী শ্রেণীর সাধারণ ক্ষেত্র রয়েছে এবং প্রাণী টেবিলে পাখির টেবিলের সাথে একের সাথে সম্পর্ক রয়েছে এবং ফিশের সাথে একের সাথে সম্পর্ক রয়েছে has টেবিল।

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

পরিবর্তে, আপনার পাখি-টেবিলের একটি রেকর্ড রয়েছে যা প্রাণী টেবিলে রেকর্ডের সাথে এক-একের সম্পর্ক relationship


এই উত্তরটি অন্য একটি প্রশ্নের সাথে সম্পর্কিত: 1 থেকে 0-1 সম্পর্কের।
Hibou57

8

আপনার যদি খুব বেশি তথ্য থাকে তবে 1-1 টি সম্পর্কও প্রয়োজনীয়। সারণীতে প্রতিটি রেকর্ডে রেকর্ড আকারের সীমাবদ্ধতা রয়েছে। কখনও কখনও টেবিলগুলি দুটি ভাগে বিভক্ত হয় (মূল সারণীতে সর্বাধিক জিজ্ঞাসিত তথ্যের সাথে) কেবল যাতে রেকর্ডের আকার খুব বেশি না হয়। টেবিলগুলি সংকীর্ণ হলে জিজ্ঞাসাবাদে ডেটাবেসগুলি আরও দক্ষ।


6

এটি একটি টেবিলটি প্রসারিত করার একটি উপায় যা ইতিমধ্যে "সত্য" ডাটাবেস পরিবর্তনের চেয়ে কম (অনুভূত) ঝুঁকি নিয়ে উত্পাদিত। লিগ্যাসি সিস্টেমে 1: 1 টি সম্পর্ক দেখা প্রায়শই ভাল সূচক হয় যে প্রাথমিক নকশার পরে ক্ষেত্রগুলি যুক্ত করা হয়েছিল।


কেন সমান? আপনি কি মনে করেন যে কোনও ব্র্যান্ড স্প্যানকিন নতুন টেবিলের বিদ্যমান টেবিলটি পরিবর্তনের মতোই ঝুঁকি রয়েছে। নতুন টেবিল যুক্ত হওয়ার সাথে সাথে যে জিনিসগুলি ভেঙে যায় সেগুলি দয়া করে তালিকাভুক্ত করুন। আমি যা ভাবতে পারি তা হ'ল মেটাডাটা ওভার নির্বাচন করে এমন কোড যা USER_TABLES লুপ থেকে << কিছু> শেষ লুপটি নির্বাচন করুন।

1
অতিরিক্ত ক্ষেত্র যুক্ত করার চেয়ে 1: 1 টেবিলটি সঠিকভাবে যুক্ত করতে প্রায়শই বেশি বেশি কাজ করা লাগে তার চেয়ে জিনিসগুলি ভাঙবে less এখন একটি নতুন রেকর্ডের অর্থ কেবল একটির পরিবর্তে দুটি টেবিল আপডেট করা। একটি রেকর্ড মোছা হচ্ছে? পাশাপাশি দুটি প্রশ্ন। এখন আমরা একবার পরিবর্তন করার পরিবর্তে আরও কোড বজায় রাখছি।
জেটি গ্রিমস

@ মার্ক ব্র্যাডি, ডাটাবেসে কয়েকটি দায়ের করার সময় দৃ strongly়ভাবে টাইপ করা ডেটাসেট পরিচালনা করা নরক হতে পারে। যদি ডেটাসেটে কোনও টেবিলডাপ্টারে অনেকগুলি কোয়েরি থাকে এবং আরও থাকে তবে এটি কেবল নতুন টেবিলটিতে টানতে আরও সহজ এবং তারপরে এটি সম্পন্ন হয়েছে।
স্টিফান

@ স্টেফান: কোনও ক্যাসকেড sertোকানো নেই।
জেটি গ্রিমস

@ বুফাস, ভাল .. মাঝে মাঝে আমাদের উপার্জিত অর্থের জন্য আমাদের কিবোর্ড এবং প্রোগ্রামটি ব্যবহার করতে হবে। ;)
স্টিফান

5

এসকিউএল-তে দুটি সারণীর মধ্যে 1: 1 সম্পর্ক কার্যকর করা অসম্ভব যা উভয় পক্ষেই বাধ্যতামূলক (যদি কেবল টেবিলগুলি কেবল পঠনযোগ্য না হয়)। বেশিরভাগ ব্যবহারিক উদ্দেশ্যে এসকিউএল-তে একটি "1: 1" সম্পর্কের অর্থ 1: 0 | 1।

রেফারেন্সিয়াল সীমাবদ্ধতায় বাধ্যতামূলক কার্ডিনালিটি সমর্থন করতে অক্ষমতা এসকিউএল এর গুরুতর সীমাবদ্ধতাগুলির মধ্যে একটি। "ডিফেরেবল" সীমাবদ্ধতাগুলি সত্যই গণনা করে না কারণ এগুলি কেবল বলার এক উপায় যা কিছুটা সময় প্রয়োগ করা হয় না।


4

আপনি যদি কোনও জনপ্রিয় ওআরএম এর সাথে ডেটা ব্যবহার করেন তবে আপনি নিজের অবজেক্ট হায়ারার্কির সাথে মেলে একাধিক টেবিলের টেবিল ভাঙতে চাইতে পারেন।


3
দুঃখজনক, দুঃখজনক কারণ। যদি কোনও ওআরএম অবজেক্ট মডেল এবং শারীরিক সঞ্চয়স্থানের মধ্যে কোনও বিভাজন পরিচালনা করতে না পারে তবে .... কেবল দু: খজনক।

আসলে, যদি আমি সঠিকভাবে বুঝতে পারি তবে এর অর্থ সম্পর্কিত সম্পর্কিত ডাটাবেসে শ্রেণিবিন্যাসের উত্তরাধিকারীকরণ বাস্তবায়ন করা। এটি 1: 1 সম্পর্কের একদম বৈধ এবং প্রাকৃতিক কেস; এটি সম্পর্কে "দু: খিত" কিছুই নেই।
ত্রিপরিটো

4

আমি খুঁজে পেয়েছি যে আমি যখন 1: 1 টি সম্পর্ক করি তখন এটি সম্পূর্ণভাবে সিস্টেমিক কারণে হয়, কোনও সম্পর্কযুক্ত কারণে নয়।

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

তবে আপনি সঠিক, তত্ত্ব অনুসারে, 1: 1 সম্পর্ক সম্পূর্ণরূপে স্বীকৃত এবং এটি প্রায় একটি ঘটনা। তবে যৌক্তিকভাবে এটি প্রোগ্রামগুলি এবং অপ্টিমাইজেশানগুলি ডেটাবেসটিকে বিমূর্ত করার সহজ করে।


ঘটনা: বৈজ্ঞানিক আগ্রহের যে কোনও ঘটনা বা ঘটনা যা বৈজ্ঞানিকভাবে বর্ণিত এবং / বা ব্যাখ্যা হওয়ার সম্ভাবনাযুক্ত। আমি মনে করি না আপনি এই শব্দটি ব্যবহার করেছিলেন।

1
আমি এর অর্থ বোঝাতে চেয়েছি এটি একটি বিরল জিনিস being সাধারণত ঘটনাটি বহিরাগতদের বর্ণনা করতে ব্যবহৃত হয়, যদিও এর সংজ্ঞাটি, আমার পোস্টের প্রতিটি শব্দকে সংশোধন করার জন্য আপনার প্রয়োজনীয়তার সংজ্ঞা দেয়।
বিকাশক্রিস

@ ডেভেলপিংক্রিস আমি সম্মত হই যে 1: 1 এর একটি ফেনোমোমনন। স্কুল তত্ত্ব ব্যতীত এখানে খুব কম বাস্তব বিশ্বের পরিস্থিতি রয়েছে।
মাইকেল রিলে - এ কেএ গুনি

4

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

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


3

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


2

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

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


2

1: 1 টি সম্পর্কের জন্য আমি দেখতে পাবার সর্বোত্তম কারণ হ'ল ডাটাবেস ডিজাইনের একটি সুপারটাইপ সাবটাইপ। আমি এই মডেলের উপর ভিত্তি করে একটি রিয়েল এস্টেট এমএলএস ডেটা কাঠামো তৈরি করেছি। পাঁচটি পৃথক ডেটা ফিড ছিল; আবাসিক, বাণিজ্যিক, মাল্টিফ্যামিলি, হোটেল এবং জমি।

আমি এমন একটি সুপার টাইপ নামে পরিচিতি তৈরি করেছি যার মধ্যে ডেটা রয়েছে যা পাঁচটি পৃথক ডেটা ফিডের মধ্যে সাধারণ ছিল। এটি সমস্ত ডেটাটাইপগুলিতে খুব দ্রুত "সাধারণ" অনুসন্ধানের জন্য মঞ্জুরিপ্রাপ্ত।

আমি পাঁচটি পৃথক সাবটাইপ তৈরি করেছি যা পাঁচটি ডেটা ফিডের প্রতিটিটির জন্য অনন্য ডেটা উপাদান সংরক্ষণ করে। প্রতিটি সুপারটাইপ রেকর্ডটির উপযুক্ত সাবটাইপ রেকর্ডের সাথে 1: 1 টি সম্পর্ক ছিল।

যদি কোনও গ্রাহক কোনও বিশদ অনুসন্ধান চান তাদের একটি সুপার-সাব টাইপ উদাহরণস্বরূপ সম্পত্তি সম্পত্তি হিসাবে নির্বাচন করতে হবে।


1

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

বাই মারিও


1

যদি কোনও উল্লেখযোগ্য পারফরম্যান্স সুবিধা থাকে তবে আপনি এক থেকে এক সম্পর্কের টেবিল তৈরি করতে পারেন। আপনি খুব কমই ব্যবহৃত ক্ষেত্রগুলি পৃথক সারণীতে রাখতে পারেন।


0

1: 1 টি সম্পর্ক 1: 1 হ'ল একই টেবিলে রাখা হবে এমন কোনও কিছু হিসাবে যদি আপনি সাধারণীকরণে আসেন তবে তা আসলেই বোঝা যায় না।

বাস্তব বিশ্বে যদিও এটি প্রায়শই আলাদা। আপনার অ্যাপ্লিকেশন ইন্টারফেসটি মেলানোর জন্য আপনি আপনার ডেটা ব্রেক করতে চাইতে পারেন।


আমি এক টেবিল তত্ত্বের সাথে একমত নই। এমন সময়গুলি আসে যখন 1: 1 টি সম্পর্কের সাথে একটি সুপারটাইপ সাবটাইপ সম্পর্কটি সর্বোত্তমভাবে প্রকাশ করা হয়।
মাইকেল রিলে - এ কেএ গুনি

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

0

সম্ভবত আপনার যদি আপনার ডাটাবেজে টাইপ করা কিছু জিনিস থাকে।

একটি টেবিলে বলুন, টি 1, আপনার কাছে কলামগুলি C1, C2, C3… এর সাথে একটির সাথে সম্পর্ক রয়েছে। এটি ঠিক আছে, এটি স্বাভাবিক আকারে। এখন একটি টেবিল টি 2 তে বলুন, আপনার কাছে কলাম C1, C2, C3,… (নামগুলি পৃথক হতে পারে, তবে প্রকারগুলি এবং ভূমিকাটি একই বলে) একটির সাথে একটি সম্পর্কের সাথেও। টি 1 এর মতো একই কারণে এটি টি 2 এর জন্য ঠিক আছে।

তবে এই ক্ষেত্রে, আমি পৃথক টেবিল টি 3 এর জন্য ফিট দেখতে পাচ্ছি, যার সাথে সি 1, সি 2, সি 3 ... এবং টি 1 থেকে টি 3 এবং টি 2 থেকে টি 3 পর্যন্ত একটি সম্পর্ক রয়েছে। আরও একটি টেবিল উপস্থিত থাকলে আমি আরও ফিট দেখতে পেলাম, যার সাথে ইতিমধ্যে একাধিক সি 1, সি 2, সি 3 উপস্থিত রয়েছে ... টেবিল বি থেকে টেবিল এ থেকে একাধিক সারিতে বলুন, তারপরে, টি 3 এর পরিবর্তে আপনি বি ব্যবহার করুন এবং টি 1 থেকে বি এর সাথে একটির সম্পর্ক, টি 2 থেকে বি পর্যন্ত একই এবং এখনও এ থেকে বি পর্যন্ত একাধিক সম্পর্কের ক্ষেত্রে একই

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


0

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

উদাহরণ:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

তারপরে, আমরা যদি ভোটের টেবিলটিকে এভাবে দেখি:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

আমরা বলতে পারি যে 3 নম্বর নাগরিক হলেন আগুনের একটি মিথ্যা প্যান্ট যিনি বার্ন নাইকে প্রতারণা করেছিলেন। শুধু একটি উদাহরণ।


0

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


-4

যে কোনও জায়গায় দুটি সম্পূর্ণ স্বতন্ত্র সত্তা একে অপরের মধ্যে সম্পর্ক ভাগ করে নিয়েছিল। এখানে প্রচুর উদাহরণ থাকতে হবে:

ব্যক্তি <-> দাঁতের (এটি 1: এন, তাই এটির ভুল!)

ব্যক্তি <-> ডাক্তার (এটির 1: এন, সুতরাং এটিও ভুল!)

ব্যক্তি <-> পত্নী (এটির 1: 0 | 1, সুতরাং এটি বেশিরভাগ ক্ষেত্রে ভুল!)

সম্পাদনা করুন: হ্যাঁ, সেগুলি বেশ খারাপ উদাহরণ ছিল, বিশেষত যদি আমি সর্বদা 1: 1 এর সন্ধান করতাম, উভয় পক্ষের 0 বা 1 নয়। আমার অনুমান আমার মস্তিষ্কে ভুল গুলি চালানো হয়েছে :-)

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

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

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

প্রতিটি ক্ষেত্রে আপনি পৃথক সত্তাকে একটি বড় রেকর্ড হিসাবে উত্পাদন করতে পারতেন, তবে পচনের স্তর দেওয়া, এটি ভুল হবে। তারা এই নির্দিষ্ট প্রসঙ্গে, সত্যিকারের স্বতন্ত্র সত্তা, যদিও তারা উচ্চতর স্তরে উপস্থিত নাও হতে পারে।

পল।


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

চিহ্নিত করুন, আপনি কেবল "কাপলস" টেবিলটি করতে পারেন যেখানে সারি সবসময় জোড়াতে আসে। তবে অন্যথায় আমি আপনার, আহ ... অভিমানের সাথে একমত : পি
জোহানেস

হ্যাঁ, আমি মার্কের সাথেও একমত। :-) (আমি কি আমার নিজের বোকা উত্তরটি ডিস্ক করার অনুমতি দিয়েছি?)
পল ডব্লু হোমার

হ্যাঁ, "বোবা" এর মালিকানা প্রমাণ করে আপনি কতটা স্মার্ট। আসল কাপুরুষরা তাদের বোবা উত্তরগুলি মুছে দেয় ... ভাল জিনিস তারা চিকিত্সক নয়, চিকিত্সার রেকর্ড মুছে ফেলছে। আসলে, এটি একটি ভাল জিনিস যা আমরা হয় না; রিবুট একটি খারাপ চিকিত্সা চিকিত্সা হবে।

2
আমি সর্বদা উপলব্ধি করেছি যে এমনকি বিশ্বের বুদ্ধিমান ব্যক্তি (এই সময়ে যে কেউ হতে পারে) এখনও তাদের মজাদার মূর্খতার মুহুর্তগুলি রয়েছে। এটি একটি মানব অভিশাপ :-) যেখানে আমার কম্পিউটারটির বুদ্ধিমানের কাছাকাছি মুহুর্ত রয়েছে।
পল ডব্লু হোমার 17
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.