ডাটাবেসের সীমাবদ্ধতার কী হয়েছিল?


46

আমি যখন আরডিবিএমএসের জন্য ডাটাবেস মডেলগুলি পর্যালোচনা করি, তখন আমি সাধারণত অবাক হয়ে খুব কমই বাধা পাই না (পিকে / এফকে বাদ দিয়ে)। উদাহরণস্বরূপ, শতাংশ প্রায়শই টাইপের কলামে সংরক্ষণ করা হয় int(যখন tinyintএটি আরও উপযুক্ত হবে) এবং CHECKমানটি ০.১০০ সীমাতে সীমাবদ্ধ করার কোনও বাধা নেই । একইভাবে এসইএসইতে, চেক সীমাবদ্ধতার প্রস্তাব দেওয়া উত্তরগুলি প্রায়শই মন্তব্যগুলি গ্রহণ করে যে ডেটাবেস সীমাবদ্ধতার জন্য ভুল জায়গা।

যখন আমি বাধাগুলি কার্যকর না করার সিদ্ধান্তের বিষয়ে জিজ্ঞাসা করি, তখন দলের সদস্যরা প্রতিক্রিয়া জানান:

  • হয় যে তারা এমনকি জানে না যে এই জাতীয় বৈশিষ্ট্যগুলি তাদের পছন্দসই ডাটাবেসে বিদ্যমান। এটি কেবল ওআরএম ব্যবহার করে প্রোগ্রামারদের থেকে বোধগম্য, তবে ডিবিএর থেকে যারা কম প্রদত্ত আরডিবিএমএসের সাথে 5+ বছরের অভিজ্ঞতা আছে বলে দাবি করে তাদের থেকে অনেক কম।

  • অথবা যে তারা প্রয়োগ স্তরে এ জাতীয় প্রতিবন্ধকতাগুলি প্রয়োগ করে এবং ডাটাবেসে সেই নিয়মগুলি সদৃশ করা এসএসওটি লঙ্ঘন করা ভাল ধারণা নয়।

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

দলগুলিকে এফকে ব্যবহার না করার পছন্দ সম্পর্কে জিজ্ঞাসা করার সময়, তারা তা বলে:

  • এটি পিটা, উদাহরণস্বরূপ, যখন অন্য উপাদানগুলিতে রেফারেন্সযুক্ত কোনও উপাদানটি সরিয়ে ফেলতে হয়।

  • NoSQL শিলা রয়েছে এবং সেখানে কোনও বিদেশী কী নেই। অতএব, আরডিবিএমএসে আমাদের তাদের দরকার নেই।

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

আমি যখন অ্যাপ্লিকেশনটি নিজেই দেখি, তখন আমি পদ্ধতিগতভাবে দুটি নিদর্শন লক্ষ্য করি:

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

  • অ্যাপ্লিকেশন ধরে নিয়েছে যে ডাটাবেস থেকে আসা সমস্ত ডেটা পুরোপুরি বৈধ। এটি হ'ল, যদি 102শতাংশ হিসাবে আসে, তবে কিছু না কিছু ক্রাশ হবে, বা এটি কেবল ব্যবহারকারীর মতো প্রদর্শিত হবে যা অদ্ভুত পরিস্থিতির দিকে পরিচালিত করবে।

  • যদিও 99% এরও বেশি প্রশ্নের একক অ্যাপ্লিকেশন দ্বারা সম্পন্ন করা হয়, সময়ের সাথে সাথে স্ক্রিপ্টগুলি প্রদর্শিত শুরু হয় — হয় স্ক্রিপ্টগুলি যখন প্রয়োজন হয় তখন হাতে হাতে চালিত হয়, বা ক্রোন জবগুলি। কিছু ডেটা অপারেশন নিজে হাতে ডাটাবেসটিতে সঞ্চালিত হয়। উভয় স্ক্রিপ্ট এবং ম্যানুয়াল এসকিউএল ক্যোয়ারিতে অবৈধ মানগুলি প্রবর্তনের উচ্চ ঝুঁকি রয়েছে।

এবং এখানে আমার প্রশ্ন আসে:

চেক সীমাবদ্ধতা ছাড়াই এবং অবশেষে এমনকি বিদেশী কী ছাড়াও মডেল রিলেশনাল ডাটাবেসের কারণগুলি কী?


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


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

1
@ জ্যাকসবিবি: আপনি একটি উত্তর পোস্ট করতে পারেন, যেহেতু "আমি কয়েক দশক ধরে এটি দেখেছি" একটি খুব আলাদা দৃষ্টি দেয় যে আমার যে ঘটনাটি ঘটেছিল তা তিন-চার বছর আগে হাজির হয়েছিল (এই যে আমি আইটিতে কম সময়ের জন্য কাজ করেছি) দশক, ঘটনা সম্পর্কে আমার দৃষ্টিভঙ্গি সম্ভবত ভুল)। সুতরাং, সিদ্ধান্তগুলিও খুব আলাদা হবে।
আর্সেনি মরজেনকো

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

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

3
আমি তোমার সাথে ১১০% আছি।
পেরিটা ব্রেটা

উত্তর:


28

ডাটাবেসগুলির জন্য বিভিন্ন ব্যবহারের ক্ষেত্রে পার্থক্য করা গুরুত্বপূর্ণ।

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

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

এই বিভিন্ন ব্যাকগ্রাউন্ডের বিকাশকারীরা যখন মিলিত হন আপনি সংস্কৃতি সংঘর্ষ পান।

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


5
+! ঘরে হাতির উল্লেখ করার জন্য 1: একটি অ্যাপ্লিকেশন কেবল একটি ডিবি ব্যবহার করে এবং একটি ডিবি মাত্র একটি অ্যাপ্লিকেশন দ্বারা ব্যবহৃত হয় তা ভ্রান্ত অনুমান
Tulains Cordord

4
@ টুলাইনস কর্ডোভা, আমি ভেবেছিলাম এখানকার ঘরে হাতিটি গুগলের পে-রোল সিস্টেম। :)
মাচাদো

5
@ মাখাদো এটি প্রতিভা: "আমি তাদের
তুলিনাস কর্ডোভা

2
আপনার অ্যাপ্লিকেশন কোডটি এসিডি না হওয়ায় সঠিকভাবে সীমাবদ্ধ ডাটাবেসগুলি রাখাও সহজ।
ম্যাথু হোয়াইট

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

15

আজকাল আরও বেশি সিস্টেম বিতরণ করা পরিবেশে মেঘের উপর চলছে এবং "স্কেল আপ" এর পরিবর্তে "স্কেল আউট" করার কৌশল অবলম্বন করছে। যদি আপনি অনলাইন ইন্টারনেট-মুখোমুখি অ্যাপ্লিকেশন যেমন ই-কমার্স অ্যাপ্লিকেশনগুলির সাথে কাজ করে থাকেন তবে এটি আরও বেশি গুরুত্বপূর্ণ।

বলা হচ্ছে, সমস্ত অ্যাপ্লিকেশন যা স্কেল করার কথা সেগুলি সিএপি উপপাদ্য দ্বারা সীমাবদ্ধ , যেখানে আপনাকে 3 টির মধ্যে 2 টি বেছে নিতে হবে: ধারাবাহিকতা, উপলব্ধতা এবং পার্টিশন সহনশীলতা (নেটওয়ার্ক ফল্ট সহনশীলতা)।

সিএপি উপপাদ্য অধ্যয়ন করে আপনি দেখতে পাচ্ছেন যে খুব বেশি পছন্দ নেই, তবে উপলভ্যতা বা ধারাবাহিকতা হারাতে বেছে নেওয়া হয়েছে, যেহেতু আপনি নেটওয়ার্কটিতে 100% সময়কে সত্যই বিশ্বাস করতে পারবেন না।

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

সুতরাং, বেশ কয়েকটি অ্যাপ্লিকেশনগুলি রিলেশনাল ডাটাবেসের সীমাবদ্ধতাগুলিকে ছাড়তে বেছে নিচ্ছে, যেহেতু রিলেশনাল ডাটাবেসগুলি ধারাবাহিকতায় খুব ভাল, তবে উপলব্ধতার ব্যয়ে।

ব্যক্তিগত দ্রষ্টব্য: আমিও পুরানো fashion ডাটাবেস সীমাবদ্ধতাগুলি বছরের পর বছর এবং বিকাশের খারাপ বিকাশ এবং বিকাশকারীদের যে দলগুলি আসে এবং যায় সেগুলির বিরুদ্ধে প্রতিরক্ষার সর্বশেষ লাইন।

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

- সম্পাদনা: -

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

যদিও এটি বৈধ, তবে এটি আমার কাছে ধূসর অঞ্চল, কারণ আমি আজই কোনও ডাটাবেস ইঞ্জিন খুঁজে পাই না যা মূল প্রশ্নে প্রস্তাবিত মত সাধারণ বাঁধা সমর্থন করে না।


"আমি আজই এমন কোনও ডাটাবেস ইঞ্জিন খুঁজে পাই না যা মূল প্রশ্নে প্রস্তাবিত মত সাধারণ বাঁধাগুলিকে সমর্থন করে না।" মাইএসকিউএল চেক সীমাবদ্ধতাগুলি এখনও সমর্থন করে?
ভিনসেন্ট সাভার্ড

@ ভিনসেন্টস্যাভার্ড, সম্ভবত এমএস এসকিউএল ঠিক যাচাই করবেন না, তবে একরকম বিধিনিষেধ রয়েছে: dev.mysql.com/doc/refman/5.7/en/constraint-in अवैध-data.html
মাচাদো

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

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

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

10

চেক সীমাবদ্ধতা ছাড়াই এবং অবশেষে এমনকি বিদেশী কী ছাড়াও মডেল রিলেশনাল ডাটাবেসের কারণগুলি কী?

প্রথমে পরিষ্কার হয়ে যাক যে আমি এখানে আরডিবিএম সম্পর্কেই কথা বলছি, নন-এসকিউএল ডাটাবেসগুলি সম্পর্কে নয়।

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

বছরের পর বছর ধরে আমার অভিজ্ঞতায় আমি বলতে পারি যে এর কয়েকটি কারণ হতে পারে:

  • ক্ষেত্রে নতুনদের বা শখ প্রোগ্রামার, আল মডেলিং দক্ষতা ACK
  • ডাটাবেস জগতের সাথে সত্যিকারের যোগাযোগ না করেই ওআরএমগুলির বিস্তৃত বা প্রায় একচেটিয়া ব্যবহার
  • কোনও দল বা ছোট প্রকল্পে ডিবিএ বা অন্য ডেটা মডেলিং বিশেষজ্ঞের অনুপস্থিতি
  • উন্নয়নের প্রথম পর্যায়ে ডিবিএ বা ডেটা মডেলিং বিশেষজ্ঞের সাথে জড়িত থাকার অভাব
  • ইচ্ছাকৃত নকশা সিদ্ধান্ত বিকাশকারী সম্প্রদায়ের যে যে এমনকি একটি চেক বাধ্যতা যে প্রয়োগ করে একটি নির্দিষ্ট কলাম শুধুমাত্র থাকতে পারে বিবেচনা করে এর একটি অংশ দ্বারা 1,2 or 3একটি মান, বা যে "বয়স" কলাম হতে হবে >= 0হয় "ডাটাবেসের মধ্যে ব্যবসা লজিক থাকার" । এমনকি ডিফল্ট ধারাগুলি কারও কারও দ্বারা যুক্তি হিসাবে বিবেচনা করা হয় যা কোনও ডাটাবেসের সাথে সম্পর্কিত নয়, কারণ আপনি এই সাইটে বেশ কয়েকটি সাম্প্রতিক প্রশ্নোত্তর দেখতে পারেন। এই বিকাশকারীরা যাতে এটি বিবেচনা করে, স্পষ্টতই সম্ভব কম কয়েকটি প্রতিবন্ধকতা ব্যবহার করবে এবং কোডে এমনকি রেফারেন্সিয়াল অখণ্ডতা এবং / অথবা icক্যবদ্ধভাবে সবকিছু করবে। আমি মনে করি এটি একটি চূড়ান্ত অবস্থান।
  • কী-মান স্টোরেজ হিসাবে আরডিবিএম ব্যবহার করুন, নো-এসকিউএল আচরণ অনুকরণের জন্য কারণ প্রয়োজনীয় ডিফল্টগুলি যেখানে আরডিবিএমএস সারণীগুলি কী-মান ভান্ডারগুলি পৃথক করে আলাদা করতে পারে।
  • ধরে নিই যে ডাটাবেসটি সর্বদা "অ্যাপ" দ্বারা লিখিত থাকবে এবং যে কোনও ব্যক্তিকে কখনই কোনও এসকিউএল ক্লায়েন্টের মাধ্যমে বিশাল ডেটা লোড, বা সারিগুলি সম্পাদনা বা সন্নিবেশ করার প্রয়োজন হবে না (অ্যাপ্লিকেশনটি সন্নিবেশিত খারাপ ডেটা সংশোধন করার ক্ষেত্রে)। সেরা ক্ষেত্রে এসেনারিও সর্বদা একটি অ্যাপ্লিকেশন থাকবে ("অ্যাপ্লিকেশন" ছাড়াও) ডাটাবেসে ডিএমএল নির্দেশনা জারি করে: একটি এসকিউএল ক্লায়েন্ট।
  • ডেটা ব্যবসায়ীর মালিকানাধীন , অ্যাপ্লিকেশনটির নয় তা উপলব্ধি করে না Not

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

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


3

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

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

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


2

এটি এমন একটি সমস্যা যা আমি আমার সমস্ত ক্যারিয়ারের সাথে লড়াই করেছি (প্রায় 40 বছর) এবং আমার ডিবিএমএস লেখার সময়ও। আমার শেষ পয়েন্টের একটি বিবরণ এখানে: http://unibase.zenucom.com । সুতরাং এখানে আমার চিন্তা।

  1. সাধারণত বলার ক্ষেত্রে বেশিরভাগ সীমাবদ্ধতাগুলি অ্যাপ্লিকেশনটিতে আরও ভালভাবে পরিচালনা করা হয় যাতে অ্যাপ্লিকেশনের বিভিন্ন অংশগুলি বিভিন্ন বাধা প্রয়োগ করতে পারে। উদাহরণস্বরূপ একটি রাষ্ট্রীয় কোড সমস্ত বিচার বিভাগে প্রয়োগ নাও হতে পারে।
  2. একদিকে যেমন% সতর্কতা অবলম্বন করুন। মার্কআপগুলি হয় 100% বা আপনি ভেঙে যান :)
  3. সীমাবদ্ধতাগুলি নেতিবাচকভাবে সর্বোত্তমভাবে বর্ণিত হয়। অর্থাত্ তারা কী হতে পারে না, তাদের কী হওয়া উচিত নয়। এটি সর্বদা একটি সহজ তালিকা।
  4. বিদেশী কীগুলি সর্বদা ভাল এবং ব্যবহার করা উচিত। দাড়ি. এফকে হ'ল আরডিবিএমএসের কয়েকটি অর্থপূর্ণ নির্মাণের মধ্যে একটি এবং এটি খুব দরকারী। সর্বাধিক অসুবিধা সিদ্ধান্ত নিচ্ছে যে এফকে সরিয়ে ফেলা হলে কোনও মান দ্বিধায়িত করতে হবে বা এফকে রেকর্ডটি মোছার কারণ না হিসাবে নির্ভরশীল সারিগুলি ব্যবহার করতে হবে।
  5. আসল বিশ্বে প্রতিবন্ধকতাগুলি সাধারণত একক ক্ষেত্রের মান সীমাবদ্ধতার চেয়ে জটিল।
  6. এমনকি অ্যাপ্লিকেশন পর্যায়ে কিছু প্রতিবন্ধকতা ভাল অপারেশনের বিরুদ্ধে কাজ করে। উদাহরণস্বরূপ আক্রমণাত্মক তারিখ চেকিং ত্রুটিগুলি স্পষ্টত ভাল তারিখগুলিতে লুকিয়ে রাখে। অন্যথায় বোধগম্য তারিখগুলিতে ত্রুটিগুলির একটি পরিমাপ পেতে আপনার অপারেটরের ত্রুটি দরকার।

1

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


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

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

7
@ থমাসকিলিয়ান: নাহ; ঠিক বিপরীত। ভুল ডেটা পাবেন না, বিশেষত কারণ ডাটাবেসের সীমাবদ্ধতা রয়েছে। যদি আপনার ব্যবসায়ের যুক্তি কোডে সঠিক হয় তবে আপনি কখনই প্রথম স্থানে এই প্রতিবন্ধকতাগুলি লঙ্ঘন করবেন না। কোডে কোনও ত্রুটি ঘটে থাকলে, স্ক্র্যাপ থেকে ডাটাবেসকে নিরাপদে রাখার সময় সেই বাধাগুলি আপনাকে এই বাগ সম্পর্কে সতর্ক করবে।
আর্সেনী মোরজেনকো

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

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

1

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

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

সেরা ফলাফলের জন্য, এসকিউএল ব্যবহার করে সারণী তৈরি করুন এবং ম্যানুয়ালি সীমাবদ্ধতা যুক্ত করুন, তবে কখনও কখনও লোকেরা এটি করতে পারে না।


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