আমার কি কলামগুলিতে স্পষ্টভাবে DENY আপডেট করা উচিত যা আপডেট করা উচিত নয়?

Question

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

উদাহরণ স্বরূপ:

create table dbo.something (
    created_by varchar(50) not null,
    created_on datetimeoffset not null
);

একবার মান সেট হয়ে গেলে এই দুটি কলাম কখনই পরিবর্তন করা উচিত নয়। অতএব, আমি স্পষ্টভাবে would তাদের উপর অনুমতি নেই।DENYUPDATE

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

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

এই পরিস্থিতিতে সেরা অনুশীলন কি?

Comments

মন্তব্য সংরক্ষণাগারভুক্ত ।

— পল হোয়াইট GoFundMonica বলেছেন

Answer 1

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

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

Answer 2

আমি এর প্রযুক্তিগত দিকটিতে @ অ্যারনের সাথে সম্পূর্ণ সম্মত agree

এর বাইরে আমি বলব, সেরা অনুশীলনের বিষয়ে:

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

2. কখনও কখনও পরিবর্তন করা উচিত নয় এমন কিছুতে পরিবর্তন করতে চান এমন কাউকে বিশ্বাস করবেন না ;-), (এমনকি তারা কেন জানেন কেন তারা জানেন না)।

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

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

4. @ jpmc26 যোগাযোগের প্রয়োজনীয়তার বিষয়ে সঠিক, তবে কী কী যোগাযোগের প্রয়োজন তা সঠিক নয়। হ্যাঁ, অন্যরা যা অনুরোধ করছে তা আপনার শুনতে হবে এবং তাদের যুক্তি বোঝার চেষ্টা করা উচিত, যার মধ্যে আপনি কোনও বিষয়ে অস্পষ্ট থাকলে প্রশ্ন জিজ্ঞাসা করা।

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

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

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

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

তাই:

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

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

   বছর কয়েক পরে তিনি এই যুক্তি তৈরি করার জন্য ক্ষমা চেয়েছিলেন ;-)

Answer 3

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

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

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

সুতরাং এই ভয়কে প্রশ্রয় দেওয়ার জন্য আপনার কয়েকটি করণীয় করা উচিত:

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

Answer 4

আপনার বিরোধী বক্তব্য রয়েছে

• কলামগুলি কখনই আপডেট করা উচিত নয়
• তাদের কোনও কারণে মানগুলি আপডেট করতে হবে

প্রথমটি নির্ধারণ করা কি সত্যই আপনার উপর নির্ভর করে?

প্রুফ ছাড়াই অ্যাপটি কাজ করার জন্য আপনি সর্বনিম্ন সুযোগ সুবিধাকে নিক্ষেপ করুন অ্যাপটিকে কখনই মান আপডেট করার প্রয়োজন হবে না।

ডেটা অখণ্ডতার জন্য দায়ী কে?

এসকিউএল সীমাবদ্ধতার সাথে আপনি কি ডেটা অখণ্ডতার গ্যারান্টি দিতে পারেন? না আপনি পারবেন না কারণ প্রায়শই ব্যবসায়ের নিয়ম রয়েছে যা ডেটাবেস যা করতে পারে তার বাইরে চলে যায়।

বিক্রেতা ID উচিত কখনও পরিবর্তন করেন কিন্তু কি যদি দুটি বিক্রেতাদের একত্রিত করে। কখনও না বল না.

যদি অ্যাপ টিমটি ডেটাটিকে দূষিত করে এবং তারা বলে যে তাদের সেই কর্তৃত্বের প্রয়োজন ছিল তবে তা তাদের উপর। যদি অ্যাপ টিমগুলি আপনার পক্ষে কাজ করে তবে আপনি ডিক্টেট করতে পারেন।

উপযুক্ত প্রশ্নটি হ'ল অ্যাপটি কখনই ডেটা আপডেট করে।

Comments

সংক্রান্ত " অ্যাপ্লিকেশন দলের তথ্য contaminates যদি তারা বলেছিল তারা যে কর্তৃত্ব ছিল তারপর, এটা তাদের উপর নয়। " উম, আপনি কি কখনও একটি পেজার সম্পন্ন করেছেন এবং 2:00 পূর্বাহ্ণ আপ woken হয়েছে - 4:00 পূর্বাহ্ণ কারণ কিছু ভুল হয়েছে? আপনি সকাল 2:00 টায় অ্যাপ টিমকে কল করতে পারবেন না এবং তাদের সমস্যাটি ঠিক করতে বলুন । এটি ডিবিএর সমস্যা, কারণ অ্যাপ টিম ক) কী ঠিক করতে হবে তা জানে না, খ) কীভাবে এটি ঠিক করতে হয় তা জানে না , এবং সি) এটির সমাধানের জন্য ডিবি অনুমতি নেই। এবং শেষে উত্থাপিত প্রশ্নের জন্য, বিকাশকারী কখনও বলেনি যে অ্যাপটির ডেটা আপডেট করা উচিত ; এটি ছিল "সম্ভবত কোনও দিন আমি চাই"।

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

— পাপারাজ্জো

"দায়িত্ব কর্তৃত্বের সাথে যায়" এমন প্রিন্সিপালটিতে আমি আপনার সাথে একমত। তবে এটি অনেক লোকের পক্ষে বাস্তবতা নয়। আমি যে জায়গাগুলিতে কাজ করেছি সেই আদর্শের পক্ষে যুক্তি দিয়েছি। আমি খুব কমই এটি ঘটতে দেখি। তা ছাড়া এটি কোনও যুক্তি নয়, এটি একটি আলোচনা।

— সলোমন রুটজকি

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

— জো ডাব্লু

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

— সলোমন রুটজকি