কোডের চেয়ে ডাটাবেসে কেন বাধা প্রয়োগ করা হয়?

Question

ডাটাবেসে বাধা কেন প্রয়োগ করা হয়? কোডে রেখে দেওয়া কি আরও নমনীয় হবে না?

আমি ডেটাবেস বাস্তবায়নের বিষয়ে একটি প্রাথমিক বই পড়ছি, তাই আমি এটি একটি শিক্ষানবিশ হিসাবে জিজ্ঞাসা করছি। ধরা যাক আমি এই সত্তা মডেল সহ একটি ডেটাবেস ডিজাইন করেছি:

 entity type    |   sub-types
----------------+--------------------------------------------
   Person       |   Employee, Student,       ...
   Student      |   Graduate, Undergraduate, ...
   Employee     |   Teacher,  Administrator, ...

বর্তমান বাধা:

1. সিস্টেমে নিবন্ধিত ব্যক্তি কেবল একজন ছাত্র বা কর্মচারী হতে পারে।
2. ব্যক্তি সত্তার সামাজিক সংখ্যার স্বতন্ত্রতা প্রয়োজন, যা আমরা অনুমান করি যে প্রতিটি ব্যক্তি কেবলমাত্র একটি একক অনন্য (ওরফে, একটি ভাল যথেষ্ট প্রাথমিক কী) রাখে। (দেখুন # 1)

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

(এটি খুব অসম্ভব তবে আমি এখনই অন্য কিছু ভাবতে পারি না। স্পষ্টতই এটি সম্ভব)।

আমরা কোডের পরিবর্তে ডাটাবেস ডিজাইনে ব্যবসায়ের নিয়ম কেন যত্ন করি ?

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

Comments

বেশিরভাগ ক্ষেত্রে আমরা ব্যবসায়ের বিধি প্রয়োগ করা হয় এবং এটির জন্য সর্বোত্তম উপায় কী।

— ypercubeᵀᴹ

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

— নীলস কেওরেন্টজেস

আসলে, একজন স্নাতক ছাত্র হিসাবে আমি একজন ছাত্র, কর্মচারী এবং একজন শিক্ষক উভয়ই বিবেচিত considered সুতরাং আপনার উদাহরণ সত্যিই অসম্ভব।

— উইনস্টন ইওয়ার্ট

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

— এইচএলজিইএম

অবজেক্ট <-> রিলেশনাল ম্যাপিং একটি শিল্প।

— থরবজর্ন রাভন অ্যান্ডারসন

Answer 1

কিছু সীমাবদ্ধতা ডাটাবেসে সেরা প্রয়োগ করা হয়, এবং কিছু প্রয়োগে সেরা প্রয়োগ করা হয়।

ডাটাবেসে সর্বাধিক প্রয়োগ করা সীমাবদ্ধতাগুলি সাধারণত সেখানে থাকে কারণ এগুলি কোনও ডেটা মডেলের কাঠামোর জন্য মৌলিক, যেমন কোনও বিদেশী কী কনট্রিন্ট কোনও পণ্যটির বৈধ আছে কিনা তা নিশ্চিত করতে category_id।

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

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

আপনার উদাহরণটি এমন একটি পরিস্থিতি দেখায় যেখানে ডাটাবেসের পরিবর্তে অ্যাপ্লিকেশনটিতে সীমাবদ্ধতা থাকা আরও সুবিধাজনক হতে পারে তবে প্রাথমিক ডেটা মডেলটি খুব সীমাবদ্ধ এবং জটিল নয় বলে সম্ভবত একটি মৌলিক সমস্যা ছিল?

Comments

সুতরাং এই উত্তর অনুসারে, এই বিধি <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< শিক্ষার্থী / কর্মচারী সাব-টাইপ ব্যক্তি> সীমাবদ্ধতা। আমি কি সঠিক? (এটি ছিল বইয়ের উদাহরণ)। ধন্যবাদ।

— hkoosha

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

— হতাশাগ্রস্থ

@ ললুউইয়্য: আসল ডেটা মডেলটি ব্যবহার করার এবং এখনও শিক্ষকদের শিক্ষার্থী হতে দেওয়ার আরেকটি উপায় হতে পারে অন্য একটি টেবিল বলা যেতে পারে teachers_as_studentsযা একটি অন্য উপ-প্রকার Studentsএবং একটি নতুন বিদেশী কী রেফারিং রয়েছে Teachersএবং একটি সিস্টেমের পরিবর্তে একটি সিস্টেমের দ্বারা উত্পাদিত প্রাথমিক কীটি সামাজিক পরিবর্তে রয়েছে নিরাপত্তা সংখ্যা. এইভাবে, একজন "ছাত্র" আসলে একজন শিক্ষকের একটি উপনাম তাই শিক্ষক এখনও একটি ক্লাস নিতে নিবন্ধন করতে পারেন। পুরো ডেটা মডেল না দেখে এটি কতটা ভাল কাজ করবে তা নিশ্চিত করে বলা শক্ত।

— হতাশিত

আমি এটাকে কমিয়ে দিয়েছি। এমন কোনও সময় নেই যখন কেবলমাত্র প্রয়োগে সীমাবদ্ধতা প্রয়োগ করা হয় best এই উত্তরের স্বরটি ভুলভাবে ওজনযুক্ত।

— ইভান ক্যারল

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

— ইভান ক্যারল

Answer 2

কারণ:

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

আমার কাছে গুরুত্বপূর্ণ কিছু কারণ।

Comments

(1) এবং (3) এর সাথে আধা সম্পর্কিত: অ্যাপ্লিকেশন কোডের বাগগুলি স্থির করা যায়, আপনার ডেটার বাগগুলি প্রায়শই অপূরণীয় হয়।

— মিউ খুব ছোট

Answer 3

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

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

Answer 4

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

সাধারণত অ্যাপ্লিকেশন-স্তরের সীমাবদ্ধতাগুলি পরাজিত হয় যদিও ডাটাবেস পঠিত ধারাবাহিকতা প্রক্রিয়া, যার দ্বারা প্রতিশ্রুতি না দেওয়া পর্যন্ত সেশনগুলি অন্যান্য সেশনের ডেটা দেখতে পারে না।

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

এটি উপায় দ্বারা অ্যাপ্লিকেশন ভাষা ডিজাইনারদের কাছে অজানা। পড়ুন অধ্যায় 3.10 স্বতন্ত্রতা মধ্যে পাগল নেভিগেশন নির্দেশিকা রুবি: সক্রিয় রেকর্ড যাচাই এবং Callbacks

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

Answer 5

ডাটাবেস দ্বারা প্রয়োগ করা সীমাবদ্ধতার সুবিধা:

সরলতা - সীমাবদ্ধতা ঘোষণা করা সীমাবদ্ধতা ঘোষণা করা এবং কোডটি লেখা যা এই ঘোষণা কার্যকর করে তার চেয়ে উল্লেখযোগ্যভাবে সহজ।

যথার্থতা - আপনি যে কোডটি লিখেছেন তা আপনার তৈরি করা ত্রুটি কখনও থাকতে পারে না। ডাটাবেস বিক্রেতারা তাদের সীমাবদ্ধতা কোডটি সঠিক কিনা তা নিশ্চিত করে সময় ব্যয় করেন, তাই আপনার দরকার নেই।

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

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

সম্পূর্ণতা - ডেটাবেসগুলিতে ডেটা প্রবেশের সময় অ্যাপ্লিকেশনগুলি সীমাবদ্ধতা প্রয়োগ করে এবং পুরানো ডেটা সঠিক কিনা তা যাচাই করতে বা ইতিমধ্যে ডাটাবেসে ডেটা ম্যানিপুলেট করার জন্য অতিরিক্ত প্রচেষ্টা প্রয়োজন।

দীর্ঘায়ু - আপনার ডাটাবেস প্ল্যাটফর্মটি সম্ভবত কোনও নির্দিষ্ট অ্যাপ্লিকেশনকে ছাড়িয়ে যাবে।

Answer 6

সার্ভারে বাধা কেন প্রয়োগ করা হয়? কারণ আপনি খারাপ ক্লায়েন্টদের আপনার ক্লায়েন্ট ব্যবহার করতে বাধ্য করতে পারবেন না।

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

আপনি যদি ডাটাবেস সার্ভারে অখণ্ডতা যাচাই করেন তবে সরঞ্জাম নির্বিশেষে ডেটা অ্যাক্সেসের প্রতিটি প্রচেষ্টা আপনার নিয়ম দ্বারা সীমাবদ্ধ থাকবে।

Answer 7

এখানে কিছু দুর্দান্ত উত্তর, এবং অন্যান্য চিন্তা পুনরাবৃত্তি করার ঝুঁকিতে:

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

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

Answer 8

1. ডাটাবেসগুলি কার্যকরভাবে সীমাবদ্ধতাগুলি পরীক্ষা করতে পারে। কোডের চেয়ে ভাল।

2. অখণ্ডতা সীমাবদ্ধতা কার্যকর কার্যকর পরিকল্পনাটি আবিষ্কার করতে ডাটাবেসকে সহায়তা করে

3. অ্যাপ্লিকেশনটি ধারাবাহিক দর্শন পড়তে দেখায়, সুতরাং এটি খুব কমই স্বতন্ত্রতার গ্যারান্টি দিতে পারে। যখন ডাটাবেস অ-প্রত্যাশিত ডেটাও দেখতে পারে।

Answer 9

সংক্ষিপ্ত উত্তর ... ডেটা অখণ্ডতা সংরক্ষণ করার জন্য (যেমন নির্ভুলতা এবং বৈধতা)।

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

অন্য কিছুর জন্য ...
ডাটাবেসগুলি সর্বদা দুটি মাস্টার পরিবেশন করে যা আমি সম্পাদক এবং ব্যবহারকারীদের কল করব ।

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

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

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

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

যাইহোক, আমরা যতটা ভান করি ভবিষ্যতের ভবিষ্যদ্বাণী করতে পারি, আমরা তা করতে পারি না।

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

সীমাবদ্ধতাগুলি সেই নিয়ম এবং সম্পর্কগুলি সংক্ষিপ্ত, ঘোষণামূলক আকারে প্রয়োগ করে যেখানে সহজেই অ্যাক্সেস হয়। সেগুলি ব্যতীত পরবর্তী বিকাশকারীদের সেই বিধিগুলি বিপরীতে ইঞ্জিনিয়ার করার জন্য অ্যাপ্লিকেশন প্রোগ্রামের মাধ্যমে .ালা উচিত। শুভকামনা!

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

Answer 10

অন্যান্য মন্তব্য ছাড়াও ...

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

Answer 11

ব্যক্তিগতভাবে, আমি মনে করি ট্রিগার তৈরির চেয়ে প্রতিবন্ধকতা তৈরি করা এবং পরিবর্তন করা সহজ, উদাহরণস্বরূপ, উত্স কোড ব্যবহার করে আপনার ব্যবসায়ের নিয়ম প্রয়োগের এক উপায় এটি হতে পারে।

এছাড়াও ট্রিগারগুলি পোর্টেবল হওয়ার সম্ভাবনা কম থাকে কারণ এগুলি সাধারণত বিক্রেতার নির্দিষ্ট ভাষায় যেমন পিএল / এসকিউএল লেখা হয়।

তবে যদি সীমাবদ্ধতাগুলি আপনার প্রয়োজনগুলি পূরণ করে না, আপনি সর্বদা আপনার ব্যবসায়ের বিধি প্রয়োগ করতে ট্রিগার ব্যবহার করতে পারেন।

Comments

এছাড়াও ধারাবাহিকতার বিষয়গুলি পড়ার কারণে ট্রিগারগুলি সততার গ্যারান্টি দেয় না।

— ডেভিড অ্যালড্রিজ

Answer 12

সেগুলি সর্বদা প্রথম ডাটাবেসে প্রয়োগ করা উচিত কারণ,

1. ডাটাবেস বিভিন্ন ক্লায়েন্টদের মধ্যে সততা নিশ্চিত করে। আপনার বিভিন্ন প্ল্যাটফর্মে বিভিন্ন ক্লায়েন্ট ডাটাবেস অ্যাক্সেস করতে পারে। আপনি একটি নতুন ক্লায়েন্ট তৈরি করার সময় ডাটাবেসের সীমাবদ্ধতা অখণ্ডতার সমস্যাগুলিকে ঝুঁকিপূর্ণ করে না। এটি আপনাকে পুনর্লিখন বা অতিরিক্ত অ্যাক্সেস পয়েন্টের ক্ষেত্রে আপনার বাধাগুলি প্রশ্নোত্তর থেকে আটকাবে।
2. ডাটাবেসটিতে বিল্ডিং সীমাবদ্ধতার জন্য একটি ডিএসএল রয়েছে: এসকিউএল ডিডিএল!
3. ডাটাবেস সিস্টেম ক্যাটালগগুলিতে সেই প্রতিবন্ধগুলির অ্যাক্সেস সরবরাহ করে যাতে একটি যথাযথ ওআরএম বা "স্কিমা লোডার" এই সীমাবদ্ধতাগুলি পড়তে পারে এবং সেগুলি আপনার অ্যাপ্লিকেশনে নিয়ে আসতে পারে। উদাহরণস্বরূপ, যদি আপনার ডাটাবেসটি নির্দিষ্ট করে যে আপনার একটি varchar(5)প্রকার রয়েছে, আপনি আপনার নির্দিষ্ট ভাষার জন্য একটি স্কিমা লোডিং ওআরএম খুঁজে পেতে পারেন যা ভাষার টাইপটি স্কিমার ধরণে ম্যাপ করে এবং আকারের উপর নিজের সীমাবদ্ধাকে একত্রিত করে। DBIx for Perl is one such schema loader; সত্তা ফ্রেমওয়ার্কের জন্য এখানে অন্য একটি । এই লোডারগুলির ক্ষমতা পৃথক হয় তবে তারা যে কোনও কিছু সরবরাহ করতে পারে তা ডাটাবেসে ট্রিপ না করে অ্যাপে অখণ্ডতা নিশ্চিত করার জন্য একটি ভাল শুরু।