কোনও সম্পর্কযুক্ত ডাটাবেসে স্বচ্ছতার সীমাবদ্ধতা - আমাদের কি সেগুলি উপেক্ষা করা উচিত?


10

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

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

এটি এখন তিন বছরের জন্য পছন্দসই পদ্ধতি। আমি এই সংস্থায় নতুন (কেবলমাত্র এক মাস), তবে যেমন পণ্য "কাজ করে", ডাটাবেস বাড়ানোর ক্ষেত্রে দ্বিধা রয়েছে; তবুও, প্রথম জিনিসটি আমি লক্ষ্য করেছি যে একটি পৃষ্ঠা লোড হতে 1 মিনিট সময় নেয় (হ্যাঁ, 60 সেকেন্ড!)।

বর্তমান অবস্থার পিছনে অন্যতম দাবি হ'ল একটি "অস্বীকৃত" ডাটাবেস একটি সাধারণীকরণের চেয়ে দ্রুত, তবে আমি বিশ্বাস করি না যে এটি সত্য।

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

সাধারণত, "সিআরইউডি" অপারেশনগুলির হ্যান্ডলিং অ্যাপ্লিকেশন প্রোগ্রামের কোড পর্যায়ে প্রয়োগ করা হয়; উদাহরণস্বরূপ, কিছু তথ্য থেকে ডেটা মুছে ফেলার জন্য, যাক, বলুন TableA:

  • এটি প্রথম চেক করা প্রয়োজন মাছি উপর যদি সারি মধ্যে কিছু সম্পর্ক নেই TableAএবং TableB,
  • যদি বলা হয় যে সম্পর্ক "সনাক্ত করা হয়েছে", তবে অ্যাপ্লিকেশন প্রোগ্রাম কোডটি প্রাসঙ্গিক সারি (গুলি) মুছে ফেলতে দেয় না, তবে
  • যদি কোনও কারণে অ্যাপ্লিকেশন প্রোগ্রামের কোডটি ব্যর্থ হয়, তবে জড়িত সারিগুলি এবং সারণীগুলির সাথে কোনও সম্পর্ক আছে কিনা তা বিবেচনা না করেই অপারেশনটি "সফল" হবে।

প্রশ্ন

আপনি কি আমাকে বিতর্ককে সমৃদ্ধ করার জন্য একটি ভাল, সঠিক এবং দৃ solid় উত্তরটি বিস্তারিতভাবে ব্যাখ্যা করতে সহায়তা করতে পারেন?


দ্রষ্টব্য : সম্ভবত এর আগে এমন কিছু জিজ্ঞাসা করা হয়েছিল (এবং উত্তর দেওয়া হয়েছিল) তবে গুগলের মাধ্যমে আমি কিছুই খুঁজে পাইনি।


মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।
পল হোয়াইট 9

উত্তর:


12

যদি, আপনার পোস্টে যেমন বলা হয়েছে, উদ্দেশ্যটি একটি সম্পর্কিত সম্পর্কযুক্ত ডাটাবেস তৈরি করা (ব্রিভিটির জন্য আরডিবি) এবং তাই, আশা করা যায় যে এটি এর মতোই কাজ করে, তবে সংক্ষিপ্ত উত্তরটি হ'ল:

  • না, আপনার ডেটা অখণ্ডতার সীমাবদ্ধতা উপেক্ষা করা উচিত নয়

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

সুতরাং, ডাটাবেস পেশাদার হিসাবে, আপনি ডক্টর ইএফ কোডড ব্যবসায়ের নিয়ম প্রয়োগের জন্য সরবরাহিত অত্যাধুনিক এবং মার্জিত রিলেশনাল মডেল পদ্ধতির সুবিধা নিতে পারেন এবং সেগুলি ব্যবহার না করা হলে অবশেষে যে সমস্যাগুলি দেখা দেয় তা এড়াতে পারেন।

এই ক্ষেত্রে, আমি (ক) আমার সামগ্রিক প্রতিবন্ধকতাগুলি গ্রহণ করব এবং (খ) ডাটাবেসের কার্যকারিতা এবং ইস্যুতে কাজের পরিবেশ সম্পর্কে নিম্নরূপ কয়েকটি বিবেচনা নিম্নরূপে ভাগ করব।

বিদেশী মূল সীমাবদ্ধতা, ডেটা সম্পর্ক এবং রেফারেন্সিয়াল অখণ্ডতা

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

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

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

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

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

তেমনিভাবে, একটি উল্লেখযোগ্য সাংগঠনিক সংস্থানযুক্ত ডেটা — স্বাভাবিকভাবেই অ্যাপ্লিকেশন প্রোগ্রামগুলি, অ্যাপ্লিকেশন প্রোগ্রামারগুলিকে, অ্যাপ্লিকেশন ডেভলপমেন্ট প্ল্যাটফর্মগুলি এবং প্রোগ্রামিং প্যারাডিমগুলিকে প্রবাহিত করে।

প্রাথমিক কী সীমাবদ্ধতা এবং সদৃশ সারিগুলির অন্তর্ভুক্তি

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

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

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

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

এভাবে:

  • কোন "সংস্করণ" সঠিক, নির্ভরযোগ্য হিসাবে বিবেচনা করা যেতে পারে?
  • কোনটি আসল বিশ্বের সঠিকভাবে প্রতিফলিত করে?

আপনি জানেন যে, এই ঘটনাটি এমনকি আইনী জড়িত থাকতে পারে, এমন একটি পরিস্থিতি যা অবশ্যই অত্যন্ত গুরুত্বপূর্ণ।

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

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

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

(বর্তমান) চেক সীমাবদ্ধতা এবং একক-সারির বৈধতা

আসুন (বর্তমান) CHECK সীমাবদ্ধতার প্রাসঙ্গিকতাটি ভুলে যাব না যে ঘোষণামূলকভাবে একটি সারিটির কলাম মানগুলির বৈধ সেটকে সীমাবদ্ধ করে (যা সাধারণ প্রদর্শিত হতে পারে তবে বাস্তবে এটি একটি রিলেশনাল ডিবিএমএসের একটি মৌলিক বৈশিষ্ট্য) তৈরি করতে সহায়তা করে নির্দিষ্ট যে ব্যবসায় প্রসঙ্গে নিয়মগুলি সর্বদা যথাযথতার সাথে প্রতিফলিত হয়।

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

এই ক্ষেত্রে, আপনাকে অন্যান্য উপায়ে যেমন, এসিড ট্রান্সএকশনস , ট্রিগারস, বা ডিবিএমএসের মধ্যেই অন্য পদ্ধতিগুলির দ্বারা এই বিষয়টির যত্ন নিতে হবে (এই বিষয়ে তথ্যের জন্য @ ypercubeᵀᴹ দ্বারা এই উত্তরটি দেখুন ) যাতে ডেটা অবিরত থাকে সামঞ্জস্যপূর্ণ হতে.

সহায়তার সীমাবদ্ধতা: ঘোষণা করে আরও মাল্টি-সারি এবং মাল্টি-টেবিল ব্যবসায়িক বিধিগুলি সেট আপ

মাইএসকিউএল সহ বিভিন্ন এসকিউএল ডিবিএমএস-এর দ্বারা যে কোনও কারণেই খুব খারাপভাবে সমর্থিত - এর একটি দিকটি স্পষ্টতই PKs এবং FK- এর বাইরে একটি ঘোষিত ফ্যাশনে মাল্টি-সারি এবং মাল্টি-টেবিল সীমাবদ্ধতা সক্ষম করে —

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

দেখা যাচ্ছে যে ওরাকল বিক্রেতার এবং / বা বিকাশকারীরা ২০১ since সাল থেকে এসেরিটিশন সমর্থনটির মূল্যায়ন করছে এবং এটি ডিবিএমএসকে আরও আপেক্ষিকভাবে-সম্মতিযুক্ত এবং তাই আরও দৃ more় এবং প্রতিযোগিতামূলক করে তুলবে। আমি অনুমান করি যে, যদি (i) তাদের গ্রাহকরা চাপ বজায় রাখেন এবং (ii) ওরাকল বাস্তবায়নে সফল হন, তবে (iii) অন্যান্য ডিবিএমএস বিক্রেতারা / সম্প্রদায়গুলি তাদেরও সক্ষম করতে হবে এবং তাদের ব্যবহার ছড়িয়ে পড়তে শুরু করবে। অবশ্যই, এটি ডাটাবেস পরিচালনার ক্ষেত্রে একটি বিশাল অগ্রগতি হবে, এবং ডঃ কড দ্বারা কল্পনা করা অন্যতম স্বতন্ত্র সরঞ্জাম হওয়ায় আমি ব্যক্তিগতভাবে আশাবাদী যে আমরা শীঘ্রই ঘটতে দেখব।

ডেটা ধারাবাহিকতা এবং সিদ্ধান্ত গ্রহণের প্রক্রিয়া

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

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

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

"Denormalization"

হায়রে, "একটি 'অস্বীকৃত' ডাটাবেস একটি সাধারণীকরণের তুলনায় দ্রুত" একটি ব্যাপকভাবে ছড়িয়ে পড়া ভুল ধারণা, যদিও এটি যুক্তি, শারীরিক এবং বাস্তববাদী কারণে খণ্ডন করা যায়।

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

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

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

শারীরিক স্তরের স্ক্যাফোल्डিংগুলি সাধারণকরণ এবং "অস্বীকৃত" টেবিলগুলিকে সমর্থন করে

একটি যৌক্তিক (বিমূর্ত) লেআউট (এসকিউএল-ডিডিএল ডিজাইন) যা বাস্তব বিশ্বে ব্যবহৃত হতে বোঝা যায় তা স্পষ্টত শারীরিক (কংক্রিট) ধারণাকে ধারণ করে যা অবশ্যই বিবেচনা করা উচিত।

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

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

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

বিবেচনাধীন ডাটাবেসের কার্যকারিতা

আপনার প্রশ্নের নিম্নলিখিত অনুচ্ছেদগুলির ডেটা পুনরুদ্ধারের ক্রিয়াকলাপের সাথে সম্পর্কিত:

[এ] পণ্যটি "কাজ করে", ডাটাবেস উন্নত করতে দ্বিধা বোধ করে; তবুও, প্রথম জিনিসটি আমি লক্ষ্য করেছি যে একটি পৃষ্ঠা লোড হতে 1 মিনিট সময় নেয় (হ্যাঁ, 60 সেকেন্ড!)।

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

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

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

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

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

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


1
দুর্দান্ত উত্তর। আমি প্রয়োগের পারফরম্যান্স বিবেচনা করার সময় নিজেকে সর্বদা স্মরণ করিয়ে দিই যে বিকাশকারীদের একটি দল আমার চেয়ে অনেক বেশি স্মার্ট এই সমস্যাগুলিতে দীর্ঘকাল ধরে কাজ করে চলেছে। রিলেশনাল ডাটাবেসগুলি বিশ্বের সর্বাধিক বিপুল সিস্টেমের কেন্দ্রবিন্দুতে রয়েছে (ফেসবুক এবং টুইটারের কয়েকটি নাম প্রকাশের জন্য)।
নিক বেডফোর্ড

9

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

বিদেশী কীগুলি আপনার ডেটার অখণ্ডতা বজায় রাখতে গুরুত্বপূর্ণ ভূমিকা পালন করে। এগুলি মুছে ফেলে কোনও ছোট পারফরম্যান্স উন্নতির চেয়ে এটি অনেক বেশি গুরুত্বপূর্ণ (এমনকি এটি সত্য ছিল)।

অধীন নয় না, কোনো পরিস্থিতিতে, একটি OLTP ডাটাবেস থেকে অপসারণ FKs।

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

এটি খুব বিরল যখন সাধারণ টিউনিং আপনাকে ডেনারমালাইজিংয়ের চেয়ে অনেক বেশি গতি উন্নতি করতে না পারে। এখানেই কোনও ভাল ডিবিএ তার বেতন অর্জন করতে পারে his আপনি আপনার প্রশ্নের টিউন করতে পারেন। আমি একবার এমন একটি ক্যোয়ারী নিয়েছি যা ৩০ মিনিটেরও কম সময়ের মধ্যে একটি উত্তর ফিরে পেয়েছিল এবং এটি 8 সেকেন্ডের মধ্যে কাজ করতে পেয়েছে। ডাটাবেসে কোনও পরিবর্তন হয়নি, কেবল ক্যোয়ারীটি আবার লিখুন। মঞ্জুর, এটি আমার ব্যক্তিগত সেরা রেকর্ড, সুতরাং আপনার মাইলেজটি বিভিন্ন রকম হতে পারে, তবে আপনি যে চেষ্টা করছেন তা সর্বশেষতম হওয়া উচিত den

আপনি আরও জটিল প্রশ্নগুলি বিকাশকারীদের লেখা থেকে রক্ষা করতে চাইতে পারেন। তারা কোন ডেটা চান এবং কোন ফর্ম্যাটে এটি চান তা তাদের জিজ্ঞাসা করুন Then তারপরে তাদের এটিকে দেওয়ার জন্য মতামত দিন। জটিল প্রশ্নগুলির মতামত হবে। তবে বিকাশকারীদের কেবল তখনই লিখতে হবে:

select <something> from <SomeView> where <whatever>;

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

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


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

2

শিরোনাম পরিবর্তন করা প্রশ্নকে পরিবর্তন করে। FOREIGN KEYs.চ্ছিক। তারা করে:

  • কোনও এফকে স্পষ্টতই একটি INDEXটেবিলের মধ্যে একটি তৈরি করে। এই জাতীয় সূচকটি ম্যানুয়ালি যুক্ত করা যেতে পারে। (সুতরাং এর জন্য এফকে প্রয়োজন হয় না ))
  • একটি এফ কে সততা পরীক্ষা করে। খ্যাতির পক্ষে এটিই এফকের মূল দাবি। আপনার অ্যাপ্লিকেশন অনুরূপ চেকগুলি করতে পারে বা একটি চেকের দরকার নেই তা সিদ্ধান্ত নেওয়ার জন্য এফকে প্রয়োজন হয় না। তাই ...
  • অখণ্ডতা চেক কর্মক্ষমতা কিছু খরচ; সুতরাং এটি প্রক্রিয়াটি ধীর করে দেয়। (এটি সাধারণত কোনও বড় বিষয় নয়))
  • এফ কে প্রত্যেকে যা চায় সবকিছু করে না; এই ফোরামটি "কেন এফকেগুলি এক্স করতে পারে না" প্রশ্নগুলি দ্বারা লিখিত। বিশেষত CHECKবিকল্পটিতে অভিনয় করা হয় না।
  • এফকে জিনিসগুলি করতে CASCADEপারে। (ব্যক্তিগতভাবে, আমি নিয়ন্ত্রণে থাকতে পছন্দ করি এবং ধরে নিই না যে এফকে 'সঠিক কাজটি করবে'।)

এফকেগুলির জন্য নীচের লাইন: কিছু লোক এফকেতে জোর দেয়; কিছু পণ্য তাদের ছাড়া পুরোপুরি ভাল বাস। তুমি সিদ্ধান্ত নাও.

PRIMARY KEYইনোডিবি থেকে মুক্তি পাওয়া একটি বড় ভুল mistake অন্যদিকে, সারোগেট থেকে মুক্তি পাওয়া AUTO_INCREMENTএবং এক (বা আরও) কলাম দিয়ে তৈরি "প্রাকৃতিক" পিকে ব্যবহার করা প্রায়শই সঠিক কাজ। একটি সাধারণ, সাধারণ, কেস অনেকগুলি: অনেকগুলি ম্যাপিং টেবিল, যেমন এখানে আলোচনা করা হয়েছে

ব্যক্তিগত অভিজ্ঞতার ভিত্তিতে, আমি পরামর্শ দিচ্ছি যে টেবিলের 2/3 টুপি অটো_পিন পিকে পরিবর্তে 'প্রাকৃতিক' ব্যবহার করা ভাল।


1
সুতরাং ... আপনি প্রায় নিখুঁত অ্যাপ্লিকেশনটির উপর নির্ভর করেন কারণ যদি কোনও বিকাশকারী DELETEউদাহরণস্বরূপ কোনও ভুল করে থাকেন এবং ডিবি সাইডে আপনার কোনও সীমাবদ্ধতা না থাকে তবে আপনি ডেটা হারাবেন end এই পদ্ধতির বৈধতা রয়েছে তবে তীব্র কোড এবং ভাল পরীক্ষার প্রয়োজন রয়েছে, যা তাদের নেই :)
ReynierPM

মুছে ফেলা হচ্ছে অত্যধিক অ্যাপ্লিকেশানে বা এফ কে সঙ্গে ঘটতে পারে। খুব অল্প পরিমাণে মুছে ফেলা সাধারণত সুস্পষ্ট হয়ে যায়। ওতো, আমি এমন কেসগুলি দেখেছি যেখানে খুব কম মুছে ফেলা ব্যয়যোগ্য - একটি "সাধারণীকরণ" সম্পর্কে চিন্তা করুন যেখানে জিনিস খুব কমই মুছে ফেলা হয়। অতিরিক্ত, অব্যবহৃত, সারিগুলি কার্যত নিরীহ are
রিক জেমস

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

1
আমার রামপুলগুলিতে একটি সাধারণ থিম নোট করুন: কোনও উত্তর নেই; কোনও এক-আকারের ফিট - সব।
রিক জেমস

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