কোনও সম্পর্কিত ডেটাবেজে সীমাবদ্ধতা - কেন সেগুলি পুরোপুরি সরিয়ে নেই?


20

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

ওআরএম সরঞ্জামগুলি যেমন এন্টি কনটেক্সট, লিনক টুডাটা, এনএইচবারনেটগুলি নিজেও প্রতিবন্ধকতাগুলি পরিচালনা করে, কমপক্ষে আপনি জানেন যে কোন টেবিলগুলির একে অপরের প্রয়োজন। সার্ভারের ভিতরে সীমাবদ্ধতাগুলি করা দু'বার একই পরিবর্তন (জোর করে) করা সম্পর্কে?

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

এটি আমাকে অবাক করে এবং আমি কীভাবে এটি পরিচালনা করব তা নিশ্চিত নই।

আমার সহজ জগতে, সেটিংটি বেশিরভাগ উদ্দেশ্য হারাতে বাধা তৈরি করে। ঠিক আছে যদি ডিজাইনটির অজান্তে হোস্টগুলি থেকে ডাটাবেস অ্যাক্সেস করা হত।

এই দৃশ্যে আপনি কীভাবে অভিনয় করবেন?
কেন কেবল ডিবি থেকে সমস্ত প্রতিবন্ধকতা সরিয়ে অ্যাপ্লিকেশন পর্যায়ে রাখবেন না?


6
আপনি সর্বদা একটি একক ORM সরঞ্জামের মাধ্যমে ডেটা অ্যাক্সেস করার পরিকল্পনা করছেন? বা আপনি ব্যবহারের প্রতিটি ওআরএম সরঞ্জাম জুড়ে সমস্ত বাধা সঠিকভাবে প্রতিরূপ "মজাদার" করার পরিকল্পনা করছেন?
ডোনাল ফেলো

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

4
গৌণ নিটপিক: আমার মনে হয় আপনি টেবিলগুলির মধ্যে "সম্পর্ক "গুলির মধ্যে বিদেশী কী সংযোগগুলি কল করলে এটি কিছুটা বিভ্রান্ত হয়। রিলেশনাল ডাটাবেসে "সম্পর্ক" হ'ল টেবিলগুলি নিজেরাই, সংযোগগুলি নয়। বিশেষত যখন আমরা তখন "রিলেশনাল ডিজাইন" সম্পর্কে কথা বলি - তার অর্থ কি টেবিলগুলি বোঝায় বা বিদেশী কীগুলি বোঝায়?
টমাস প্যাড্রন-ম্যাকার্থি

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

1
আপনার ডাটাবেসটি আপনার অ্যাপ্লিকেশন কোডটির বহিরাগত হতে চলেছে। এছাড়াও, আপনার ওআরএম আপনার প্রয়োগের কার্যকারিতা ক্ষতিগ্রস্থ করছে এবং কমপক্ষে নির্দিষ্ট ব্যবহারের ক্ষেত্রে আপনি এটিকে বাইপাস করতে চান এমন একটি ভাল সুযোগ রয়েছে। আপনি যদি এখন এটি না জানেন, আপনি অবশেষে এটি জানতে পারবেন। samsaffron.com/archive/2011/03/30/… । এছাড়াও, সমস্ত প্রতিবন্ধকতা সরিয়ে ফেলা আপনার ডাটাবেসটিকে সম্পূর্ণরূপে অক্ষম করে যখন এটি আপনার অখণ্ডতা রক্ষা করতে সক্ষম হয় যখন এটি আপনার ব্যতীত অন্য অ্যাপ্লিকেশনগুলি দ্বারা ব্যবহার করা হয়, যা এক্সেলের সাথে হল থেকে নিচে চালিত কোনও বাস্তব অ্যাপ্লিকেশন হতে পারে।
ক্রেগ

উত্তর:


46

ডিবি থেকে প্রতিবন্ধকতা অপসারণ না করার দুটি সাধারণ কারণ :

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

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


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

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

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

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

5
+1: ডিবি যদি ব্যবসায়ের ডেটা (কেবলমাত্র অ্যাপ্লিকেশন কনফিগার না করে) সঞ্চয় করে রাখে, তবে ডাটাবেসটি লাইভ আউট হওয়ার বা বর্তমান অ্যাপের বাইরে প্রসারিত হওয়ার সম্ভাবনা 100% এর কাছাকাছি পৌঁছেছে
বাইনারি ওয়ারিয়ার

27

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


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

15

আমাকে কী বিঘ্নিত করছে তা এসকিউএল সার্ভারের ভিতরে "ক্যাসকেড নয়" দিয়ে কনফিগার করা সমস্ত প্রতিবন্ধকতা।

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

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

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


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

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

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

10

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

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


6

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

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


বিষয়টি ডিবি থেকে সীমাবদ্ধ কার্যকারিতা সরিয়ে নিয়েছে এবং কোড বেসের মধ্যে সেটিংস / বিকাশের উপর নির্ভর করবে (যেমন। নেট স্পিকিং: সত্তা / লিনক 2 এসকিএল)।
ইন্ডিপেন্ডেন্ট

হ্যাঁ আমি জানি, তবে আমার বক্তব্যটি হ'ল আপনার প্রথমে বুঝতে হবে কেন প্রথমে সীমাবদ্ধতা রয়েছে এবং তারপরে কেন সেগুলি বাদ দেওয়া খারাপ ধারণা হতে পারে।
জেসেক প্রুশিয়া

সরানো হয়েছে! বাদ পড়েনি। আমি বুঝতে পেরেছি যে আপনি জাজের জ্ঞানের জন্য আফসোস করছেন, যা এটি সম্পর্কে ছিল না।
ইন্ডিপেন্ডেন্ট

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

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

6

ওয়েবে এটিই ইয়ে করেছে এবং তাদের সম্ভবত বিশ্বের বৃহত্তম ডাটাবেসগুলির মধ্যে একটি রয়েছে:

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDforum2006-11-29.pdf

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

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

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


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

10
হ্যাঁ এবং ভুলে যাবেন না - ভুলে যাবেন না - ফেসবুক এবং অ্যামাজনের মতো ইবে - গ্যাজিলিয়ন গুণ বড় ডেটাবেসগুলির 99.99% এর চেয়ে বড়, এবং তাদের জন্য ভাল যা সম্ভবত আপনার ডাটাবেসের জন্য ভাল তার থেকে খুব আলাদা।
টনি অ্যান্ড্রুজ

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

2
আপনার যদি পর্যাপ্ত সময়, দক্ষতা এবং অর্থ থাকে তবে আপনি একটি নির্দিষ্ট প্রয়োজনের সাথে শেষ পর্যন্ত কোনও আরডিবিএমএস, ওয়েব সার্ভার বা অপারেটিং সিস্টেম প্রোগ্রাম করতে পারেন।
জেফো

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

4

প্রথম - আমার উত্তর: না, আপনার ডেটা দেখাশোনা করার জন্য আপনার একা আবেদনের উপর নির্ভর করা উচিত নয়।

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

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

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


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

3

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

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

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

(ক্যাসকেড ইস্যু হিসাবে: এটি একটি ভাল জিনিস I'd সবকিছু ঠিক করার জন্য ক্যাসকেডের উপর নির্ভর না করে প্রথমে অন্য কিছু রেকর্ড মুছতে হবে এমন ত্রুটি ছুঁড়ে দিতে আমি পছন্দ করি Cas ক্যাসকেড তাত্ত্বিকভাবে দুর্দান্ত, তবে অগত্যা নয় অনুশীলনে তাই।)


2

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

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

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

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

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

সুতরাং, যদি না আপনি খুব বড় এন্টারপ্রাইজ প্রকল্পে কাজ করেন (এবং আমি চাই না) বা তরল জলের উপর দিয়ে হাঁটা করতে না পারি, সেই সীমাবদ্ধতাগুলি ডাটাবেসে রেখে দিন।


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

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