আমি কি ডাটাবেসে টেবিলের মধ্যে সম্পর্কগুলির সংজ্ঞা দিতে পারি বা কেবল কোডে?


60

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

ডাটাবেসে:

  • ডিজাইন থেকে সঠিক তথ্য। অ্যাপ্লিকেশন ত্রুটিগুলি প্রতিরোধ করুন যা অবৈধ ডেটা তৈরি করতে পারে।

  • অ্যাপ্লিকেশন হিসাবে ডেটা /োকানো / আপডেট করার সময় অ্যাপ্লিকেশনটিতে নেটওয়ার্ক রাউন্ড ট্রিপ হ্রাস করুন ডেটা অখণ্ডতা পরীক্ষা করতে আরও জিজ্ঞাসা করতে হবে)

উত্স কোডে:

  • আরো নমনীয়.

  • একাধিক ডাটাবেসে স্কেলিং করা ভাল, কারণ কখনও কখনও সম্পর্কটি ক্রস-ডাটাবেস হতে পারে।

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

আর কিছু আছে?

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

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


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

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

10
কিছু উল্লেখ করার মতো ... একবার আপনি আপনার ডাটাবেসে সততার সমস্যাগুলি পরিচয় করিয়ে দিন এটি প্যান্ডোরার বাক্স খোলার এক আত্মীয়। অযৌক্তিকভাবে ক্ষতিগ্রস্থ ডাটাবেসের প্রতি অখণ্ডতার পুনঃপ্রবর্তন করা দুঃস্বপ্ন। আপনার ডাটাবেসে কড়া নিয়ন্ত্রণ রাখা কোনও ঝামেলা হতে পারে তবে এটি আপনাকে দীর্ঘকালীন প্রচুর ব্যথা বাঁচাতে পারে।
ড্যানেকে

3
উত্স কোডে: আপনি শেষ পর্যন্ত একটি ডাটাবেসের বেশিরভাগ লেখার শেষ করেন।
ব্লারফ্লু

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

উত্তর:


70

টিএল; ডিআর: ডেটাবেজে সম্পর্কের সীমাবদ্ধতা থাকা উচিত।


আপনার অ্যাপ্লিকেশন যথেষ্ট বড় নয়।

আপনি সত্য, সত্য, যে ডাটাবেস জুড়ে সম্পর্ক প্রয়োগ করার জন্য তাদের প্রয়োগের ক্ষেত্রে প্রয়োগের প্রয়োজন হতে পারে

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

এমনকি আপনার যদি অ্যাপ্লিকেশনটিতে কিছু বৈধতা থাকা প্রয়োজন, এমনকি স্নানের জল দিয়ে শিশুটিকে বাইরে ফেলে দেবেন না । সর্বোপরি, আপনাকে যত কম করতে হবে, আপনি তত ভাল।

অবশেষে, আপনি যদি ভবিষ্যতের স্কেলিবিলিটি সমস্যাগুলি সম্পর্কে উদ্বিগ্ন হন তবে আমি ভয় করি যে আপনার অ্যাপ্লিকেশনটি যেভাবে স্কেল করার আগে তা উল্লেখযোগ্য পরিবর্তন করতে হবে under থাম্বের নিয়ম হিসাবে, প্রতিবার যখন আপনি 10x বৃদ্ধি পাচ্ছেন, আপনাকে পুনরায় নকশা করতে হবে ... সুতরাং আসুন স্কেলাবিলিটি সমস্যাগুলির প্রত্যাশা করতে ব্যর্থ হওয়ার জন্য খুব বেশি অর্থ ডুবিয়ে দেওয়া উচিত নয় এবং পরিবর্তে অর্থটি ব্যবহার করুন যেখানে আপনার issues সমস্যাগুলি রয়েছে reach

আপনার অ্যাপ্লিকেশনটি যথেষ্ট সঠিক নয়।

আপনার অ্যাপ্লিকেশনটিতে চেকটির ত্রুটিপূর্ণ প্রয়োগের সুযোগের তুলনায় আপনি যে ডেটাবেসটি ব্যবহার করেন তাতে চেকটির ত্রুটিযুক্ত বাস্তবায়ন হওয়ার সুযোগটি কী?

এবং কোনটি আপনি প্রায়শই পরিবর্তন করেন?

আমি ডেটাবেসটি সঠিক হওয়ার জন্য, যে কোনও সময় বাজি ধরব ।

আপনার বিকাশকারীরা যথেষ্ট পরিমাণে বিতরণ করার চিন্তা করছেন না।

অ্যাপ্লিকেশনটিতে নেটওয়ার্ক রাউন্ড ট্রিপ হ্রাস করুন যখন ডেটা integrityোকানো / আপডেট করা তথ্য হিসাবে ডেটা অখণ্ডতা পরীক্ষা করতে অ্যাপ্লিকেশনকে আরও কোয়েরি করতে হবে।

লাল পতাকা ! 1

আপনি যদি ভাবছেন:

  • রেকর্ড বিদ্যমান কিনা তা পরীক্ষা করুন
  • যদি না হয়, রেকর্ড .োকান

তারপরে আপনি সর্বাধিক বুনিয়াদি সম্মতি ইস্যুতে ব্যর্থ হয়েছেন: অন্য কোনও প্রক্রিয়া / থ্রেড আপনার যেতে যেতে রেকর্ডটি যুক্ত করতে পারে।

আপনি যদি ভাবছেন:

  • রেকর্ড বিদ্যমান কিনা তা পরীক্ষা করুন
  • যদি না হয়, রেকর্ড .োকান
  • নকল হিসাবে রেকর্ডটি প্রবেশ করানো হয়েছে কিনা তা পরীক্ষা করে দেখুন

তারপরে আপনি এমভিসিসির জন্য অ্যাকাউন্ট করতে ব্যর্থ হয়েছিলেন: আপনার লেনদেন শুরু হওয়ার সময় আপনার কাছে থাকা ডাটাবেসের দৃশ্যটি একটি স্ন্যাপশট; এটি সংঘটিত সমস্ত আপডেটগুলি প্রদর্শন করে না এবং সম্ভবত প্রতিশ্রুতিবদ্ধও নয়।

একাধিক অধিবেশন জুড়ে সীমাবদ্ধতা বজায় রাখা সত্যিই একটি কঠিন সমস্যা, এটি আপনার ডাটাবেজে সমাধান হয়েছে বলে খুশী হন।

1 যদি না আপনার ডাটাবেস সিরিয়ালিজেবল সম্পত্তিটি যথাযথভাবে প্রয়োগ করে; তবে কয়েকজন আসলেই করেন।


শেষ:

এবং আমি মনে করি, প্রয়োগে ডেটা অখণ্ডতা হ্যান্ডেল ডাটাবেস ব্যবহার না করে আরও ভার্বোজ ত্রুটি বার্তা দেয়। উদাহরণস্বরূপ: আপনি যখন একটি API সার্ভার তৈরি করেন। আপনি যদি ডেটাবেসে সম্পর্কের সংজ্ঞা দেন এবং কিছু ভুল হয়ে যায় (যেমন রেফারেন্সড সত্তাটি বিদ্যমান নেই), আপনি বার্তা সহ একটি এসকিউএল ব্যতিক্রম পাবেন।

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

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

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

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


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

8
সমস্ত ভাল পয়েন্ট। আর একটি হ'ল ডেটাবেজে সম্পর্কগুলি হ'ল স্ব নথিভুক্ত। আপনি যদি কখনও কোনও ইঞ্জিনিয়ারকে এমন কোনও ডেটাবেসকে বিপরীত করতে হয়েছিল যেটির সম্পর্কগুলি এটির কোডের মাধ্যমে সংজ্ঞায়িত করা হয়েছিল তবে আপনি যে কেউ সেভাবে এটি ঘৃণা করবেন।
Kat

1
@ কেট 11: এটি সত্য। এবং স্ব-বর্ণনারও সুবিধা রয়েছে যে সরঞ্জামগুলি সহজেই ডেটা বুঝতে পারে এবং এতে কাজ করতে পারে যা কখনও কখনও দরকারী হতে পারে।
ম্যাথিউ এম।

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

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

119

ডাটাবেসটিতে প্রতিটি সময় অ্যাপ্লিকেশন ডেটা সংশোধন করে ডেটা অখণ্ডতার জন্য পরীক্ষা করতে হয় না।

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


5
@ dan1111 আমি আপনার মন্তব্য বুঝতে পারছি না ... আপনি কি বলছেন: সাধারণ সীমাবদ্ধতাগুলি ডাটাবেস দ্বারা প্রয়োগ করা হয়, সুতরাং এগুলি অ্যাপ্লিকেশন কোডের জন্য কোনও সমস্যা নয়, আরও জটিল বাধাগুলি কার্যকর করা খুব কঠিন তাই কেবল তাদের ছেড়ে দেওয়া? বা আপনি কি বলছেন যে ডাটাবেস ট্রিগার (এবং অনুরূপ প্রক্রিয়া) ব্যবহার করে জটিল বাধা প্রয়োগ করা খুব জটিল এবং তাই এগুলি প্রয়োগের কোডে প্রয়োগ করা আরও ভাল?
বাকুরিউ

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

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

9
@ dan1111 আপনি কখনও অ্যাপ্লিকেশনটিতে বাগ লেখেন না, তাই না?
ব্যবহারকারী 253751

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

51

সীমাবদ্ধতাগুলি আপনার ডাটাবেসের মধ্যে থাকা উচিত, যেমন (বিশ্বের সেরা ইচ্ছা অনুসারে), আপনার অ্যাপ্লিকেশনটি এই ডাটাবেসটিতে অ্যাক্সেসের একমাত্র জিনিস হবে না

এক পর্যায়ে, ডাটাবেসের মধ্যে একটি স্ক্রিপ্টযুক্ত সমাধানের প্রয়োজন হতে পারে, বা আপনাকে স্থাপনার সময় এক টেবিল থেকে অন্য টেবিলে ডেটা স্থানান্তর করতে হতে পারে।

অতিরিক্ত হিসাবে আপনি অন্যান্য প্রয়োজনীয়তা পেতে পারেন যেমন "বড় গ্রাহক এক্স এর সত্যিকার অর্থে এই অ্যাপ্লিকেশন ডেটাবেজে আমদানি করা এই এক্সেল শীটটি আজ বিকেলে আপনার প্রয়োজন হবে", যেখানে আপনার অ্যাপ্লিকেশন কোডটি কোনও নোংরা এসকিউএল স্ক্রিপ্টটি সম্পন্ন করার সাথে খাপ খাইয়ে দেবে না suit সময়ে

এটি যেখানে ডাটাবেস স্তর অখণ্ডতা আপনার বেকন সংরক্ষণ করবে।


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

ডাটাবেসে কোনও এফকে বাধা না থাকলে সে কি আপনাকে ঘৃণা করবে যাতে কোনও টেবিলে পরিবর্তন করার আগে সে কী সম্পর্ক রাখতে পারে তা সে বলতে পারে? ( ক্লু, উত্তর হ্যাঁ )


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

9
পছন্দ করেছেন সীমাবদ্ধতা রয়েছে যাতে অ্যাপ্লিকেশনগুলি ধারাবাহিক ডেটার উপর নির্ভর করতে পারে। এফকে অক্ষম করা 'এটিতে প্রবেশ করা' পাগলামি।
ধান 7

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

5
আমি একেবারে সত্যতা দিতে পারি আমার ক্ষেত্রে আমি মাইআইএসএএম-তে আটকে গিয়েছিলাম যা প্রকৃতপক্ষে বিদেশী কী সমর্থন করে না, তাই আমি অ্যাপ্লিকেশন দ্বারা প্রয়োগ করা অখণ্ডতা সহ 250 গিগাবাইট ডেটা শেষ করেছি। যখন আরও পরিচালনাযোগ্য আকারে ব্যাকলগটি পাওয়ার জন্য ডেটা ছাঁটাই শুরু করা হয়েছিল এবং যখন স্পষ্ট হয়ে গেল যে অ্যাপ্লিকেশনটি নিজেই এটিকে পুরোপুরি পরিচালনা করতে সক্ষম হচ্ছিল না, বিশৃঙ্খলা সৃষ্টি হয়েছিল। আমি জানি না কেন আমি অতীত কালকে ব্যবহার করছি; এই এখনও ঘটছে তা এখন এবং সমস্যা (দুই বছর) এখনো সমাধান করা এখনো। * সুঘ্রাট *
27:25

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

17

ডাটাবেসে আপনার সম্পর্ক থাকা উচিত।

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

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


1
সত্য। আমার বলা উচিত ছিল যে সীমাবদ্ধতা যাচাইয়ের পারফরম্যান্স অ্যাপ্লিকেশনটির চেয়ে ডাটাবেসে আরও ভালভাবে পরিচালনা করা হবে।
কर्क

13
  • আমরা আর একটি ব্যাক-এন্ডে বাস করি না <-> একটি ফ্রন্ট-এন্ড ওয়ার্ল্ড।
  • বেশিরভাগ সমাধানগুলিতে একটি ওয়েব ফ্রন্ট-এন্ড, একটি মোবাইল ফ্রন্ট-এন্ড, একটি ব্যাচ-ফ্রন্ট-এন্ড এবং আইপ্যাডের ফ্রন্ট-এন্ড ইত্যাদি জড়িত involve
  • ডেটাবেস ইঞ্জিনগুলির রেফারেনশিয়াল অখণ্ডতা প্রয়োগের জন্য ইতিমধ্যে কোডের কয়েক হাজার পরীক্ষিত লাইন রয়েছে।

আপনি যখন লিখতে ডোমেন সমস্যা সমাধানের কোড পান তখন আপনি কি সত্যিই রেফারেন্সিয়াল অখণ্ডতা প্রয়োগকারী কোডটি লেখার এবং পরীক্ষার সামর্থ্য করতে পারেন?


2
"আমরা আর একটি ব্যাক-এন্ড <>> একটি ফ্রন্ট-এন্ড ওয়ার্ল্ডে বাস করি না।" আমরা কি কখনও করেছি? কয়েক বছর আগে, আমি একটি ডেটাবেস সিস্টেমে কাজ করেছি যাতে কমপক্ষে দুই ডজন বিভিন্ন ভাষায় এতে অ্যাক্সেস পাওয়া প্রোগ্রাম লেখা ছিল। কিছু প্রোগ্রাম 1970 এর দশকে প্রথম প্রকাশ করেছিল।
মাইক শেরিল 'ক্যাট রিকল'

2

আপনি যদি ডেটাবেস স্তরে আপনার ডেটা অখণ্ডতা, সীমাবদ্ধতা, সম্পর্ক ইত্যাদি বৈধতা না দিয়ে থাকেন তবে এর অর্থ হ'ল প্রোডাক্ট ডাটাবেস অ্যাক্সেস (ডিবি অ্যাক্সেস সরঞ্জাম সহ অন্য কোনও ক্লায়েন্টের মাধ্যমে) আপনার ডেটা গোলমাল করা এত সহজ to

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

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


1

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

সদৃশ কোড

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

প্রচেষ্টা

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

দক্ষতা

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

নিয়ন্ত্রণ

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

সমাপ্তি পয়েন্টস

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

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


1
লোকেরা যদি সুচিন্তিত জবাবগুলিকে হ্রাস করে কারণ এটি তাদের ডগমা সংক্রান্ত সাথে একমত নয়, এসই স্ট্যাকএক্সচেঞ্জ আরও খারাপ জায়গায় পরিণত হয়।
কার্ল লেথ

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

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

0

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

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

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

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

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

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

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

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


0

আপনার কয়েকটি খুব ভাল উত্তর আছে তবে আরও কিছু বিষয় রয়েছে

ডাটাবেস যা করতে ডিজাইন করা হয়েছে তা ডেটা অখণ্ডতা

অ্যাপ্লিকেশন স্তরে কোনও এফকে ডিলিটের মতো যথাযথ সামঞ্জস্যতা করা ভয়ঙ্কর হবে

ডেটা অখণ্ডতায় দক্ষতা একটি ডিবিএর সাথে

প্রোগ্রাম স্তরে আপনি সন্নিবেশ, আপডেট, বাল্ক আপডেট, বাল্ক সন্নিবেশ, বাল্ক মুছুন ...
পাতলা ক্লায়েন্ট, ঘন ক্লায়েন্ট, মোবাইল ক্লায়েন্ট ....
ডেটা অখণ্ডতা কোনও প্রোগ্রামারের দক্ষতা নয় - প্রচুর নকল কোড এবং কেউ গোলমাল করবে এটি আপ

বলুন যে আপনি হ্যাক হয়ে গেছেন - আপনি যেভাবেই সমস্যায় পড়েছেন তবে ডেটাবেসে কোনও সততা সুরক্ষা না থাকলে কোনও হ্যাকার একটি ছোট গর্তের মাধ্যমে অনেক ক্ষতি করতে পারে

আপনাকে এসকিউএল বা টিএসকিউএল এর মাধ্যমে সরাসরি ডেটা ম্যানিপুলেট করার দরকার হতে পারে
কেউ কোনও ডেটা নিয়ম মনে রাখে না


0

আপনার প্রশ্নের কোনও অর্থ হয় না: আপনি যদি ডাটাবেস পরিবর্তন করতে পারেন তবে এটি কোড, আপনি যদি ডাটাবেস পরিবর্তন করতে না পারেন তবে আপনাকে অন্য কোথাও নিজের সীমাবদ্ধতা তৈরি করতে হবে।

একটি ডাটাবেস যা আপনি পরিবর্তন করতে পারেন তা হ'ল রুবি, জাভাস্ক্রিপ্ট, সি # বা অ্যাডা যে কোনও লাইন হিসাবে কোডের মতো।

আপনার সিস্টেমে কোথায় সীমাবদ্ধতা রাখবেন সে প্রশ্নটি নির্ভরযোগ্যতা, ব্যয় এবং উন্নয়নের স্বাচ্ছন্দ্যে ফোটে।


0

এখানে অনেক ভালো উত্তর রয়েছে। আমি যুক্ত করব যে আপনি যদি Y এর ভাষায় কোনও অ্যাপ লেখা থাকে তবে আপনি Y তে ডাটাবেস-সীমাবদ্ধতার মতো কোড তৈরি করতে পারেন And যদি বাস্তবায়নের নয় ঈশ্বর আপনাকে সাহায্য ঠিক একই। অথবা যখন কোনও জ্ঞানসম্পন্ন ব্যবসায়ী ব্যবহারকারী মাইক্রোসফ্ট অ্যাক্সেস ব্যবহার করে আপনার ডাটাবেসের সাথে সংযুক্ত হন।

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.