ডাটাবেস কতটা ব্যবসায়িক যুক্তি প্রয়োগ করা উচিত?


107

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

এই পদ্ধতির মধ্যে কোনটি সাধারণত ভাল?

আমি যে ডিবিতে ভাবতে পারি ব্যবসায়িক যুক্তি প্রয়োগের উপকারগুলি হ'ল:

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

কনস:

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

দ্রষ্টব্য: আমি যে ডাটাবেসগুলির কথা বলছি সেগুলি হ'ল এসিকিউএল সার্ভার, ওরাকল, মাই এসকিএল ইত্যাদি সম্পর্কিত সম্পর্কিত জনপ্রিয় ডাটাবেস are

ধন্যবাদ!


3
আপনি এই প্রশ্নের উত্তর দরকারী খুঁজে পেতে পারেন ।
blrfl

7
এই আর্গুমেন্টের ইতিমধ্যে হয়েছে বিস্তারিত বিতর্ক । আমরা এখানে কথোপকথনে অর্থের সাথে আরও কী যুক্ত করতে পারি?
রবার্ট হার্ভে

2
@ গ্যাनेट: খুব কাছেও নেই।
রবার্ট হার্ভে


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

উত্তর:


82

ব্যবসায়িক যুক্তি ডাটাবেসের মধ্যে যায় না

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

ডাটাবেসগুলি কয়েকটি জিনিস সত্যিই ভাল করে:

  1. তারা ডেটা সঞ্চয় এবং পুনরুদ্ধার করে
  2. তারা বিভিন্ন ডেটা সত্তার মধ্যে সম্পর্ক স্থাপন এবং প্রয়োগ করে
  3. তারা উত্তরের জন্য ডেটা জিজ্ঞাসা করার উপায় সরবরাহ করে
  4. তারা কর্মক্ষমতা অপ্টিমাইজেশন সরবরাহ করে।
  5. তারা অ্যাক্সেস নিয়ন্ত্রণ সরবরাহ করে

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

এবং অবশ্যই, এমন কিছু জিনিস থাকতে পারে যা কার্য সম্পাদন এবং অন্যান্য কারণে একটি ডাটাবেসে সম্পাদিত হয়:

  1. অ্যাকাউন্টিং পিরিয়ড বন্ধ করা হচ্ছে
  2. ক্রান্চিং সংখ্যা
  3. নাইট ব্যাচ প্রক্রিয়া
  4. ব্যর্থ ওভার

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

সর্বত্র সঞ্চিত প্রক্রিয়া

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

তবে আপনি কী ঝুঁকি নিচ্ছেন?

  1. বিক্রেতা লক-ইন
  2. বিশেষ দক্ষতা সেট সহ বিকাশকারীদের প্রয়োজন
  3. স্পার্টান প্রোগ্রামিং সরঞ্জামগুলি, সামগ্রিকভাবে
  4. অত্যন্ত শক্ত সফটওয়্যার সংযুক্তকরণ coup
  5. উদ্বেগের কোনও বিচ্ছেদ নেই

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

তাহলে সাধারণ অনুশীলন কী?

আমি বলব যে একটি সাধারণ, আধুনিক পদ্ধতি হল আপনার টেবিলগুলিকে মডেল করে এমন ক্লাস তৈরির জন্য একটি অবজেক্ট-রিলেশনাল ম্যাপার (যেমন সত্তা ফ্রেমওয়ার্ক) ব্যবহার করা। এরপরে আপনি কোনও সংগ্রহস্থলের মাধ্যমে আপনার ডাটাবেসের সাথে কথা বলতে পারেন যা কোনও সংস্থার সফ্টওয়্যার বিকাশকারীকে খুব পরিচিত এমন একটি পরিস্থিতি objects ORM गतिशीलভাবে আপনার ডেটা মডেল এবং অনুরোধ করা তথ্যের সাথে সম্পর্কিত এসকিউএল উত্পন্ন করে, যা ডাটাবেস সার্ভারের পরে ক্যোয়ারির ফলাফলগুলি ফেরত প্রক্রিয়াকরণ করে।

এই ভাল কাজ করে? খুব ভাল, এবং সঞ্চিত পদ্ধতি এবং মতামত লেখার চেয়ে অনেক বেশি দ্রুত। এটি সাধারণত আপনার ডেটা অ্যাক্সেসের প্রয়োজনীয়তার প্রায় 80% কভার করে, বেশিরভাগ CRUD। অন্যান্য 20% কভার কি? আপনি এটি অনুমান করেছেন: সঞ্চিত প্রক্রিয়াগুলি, যেগুলি সমস্ত প্রধান ওআরএম সরাসরি সমর্থন করে।

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


3
আপনার দুর্দান্ত উত্তরের জন্য আপনাকে ধন্যবাদ, @ রবার্ট হার্ভে। তবে আমি "বিক্রেতা লক-ইন" যুক্তিটি সম্পর্কে ভাবছিলাম: কোনও অ্যাপ্লিকেশন তৈরি করতে কোনও বিক্রেতার লক-ইন ব্যবহার করার জন্য কোনও নির্দিষ্ট প্রযুক্তি ব্যবহার করে না (বলুন,। নেট বা জাভা স্ট্যাক)? বা কোনও ডিবি-এর তুলনায় কোনও অ্যাপ-ভিত্তিক স্ট্যাক বিক্রেতার লক-ইন এর সুবিধা রয়েছে?
রাফেল

3
@ রবার্ট হার্ভে, কিন্তু .NET- তে থাকা অ্যাপ্লিকেশন যুক্তির অংশটি এখনও। নেট এ লকড রয়েছে। একই পিএইচপি এবং জাভা জন্য যায়।
পেসিয়ার 16

2
@ পেসারিয়ার: বিক্রেতা-লককিন দ্বারা, আমি ডেটাবেস বিক্রেতার কথা উল্লেখ করছি। প্রকৃত অনুশীলনে, ডাটাবেস (এবং প্রোগ্রামিং স্ট্যাক) খুব কমই প্রতিস্থাপন করা হয়।
রবার্ট হার্ভে

2
@ কাই: ঠিক আছে, আপনি এটি দুটি উপায়ই করতে পারবেন না। হয় আপনি স্টাব এবং বিদ্রূপ ব্যবহার করেন এবং পরীক্ষাটি কৃত্রিম যে সত্যের সাথে বাঁচেন বা আপনি এমন একটি পরীক্ষা লিখুন যা বাস্তববাদী, এবং কিছুটা বিলম্বের সাথে বেঁচে থাকুন। আমি সন্দেহ করি যে যদিও আপনার ট্রেড অফটি 10 ​​সেকেন্ড বনাম 30 সেকেন্ডের।
রবার্ট হার্ভে

3
হতে পারে দেরীতে তবে আমি এই মতামত নিয়েছি যে ব্যবসায়ের লজিক প্রয়োগকারী সঞ্চিত পদ্ধতিগুলি ব্যবসায়িক লজিক স্তরের অন্তর্ভুক্ত, ডেটা স্তর নয়। এগুলি ওআরএমের প্রয়োজন নেই এমন এক ধরণের পৃথক ল্যাং।
প্যারালাইফ 4:56 এ 16:56

16

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

আমি আপনার পক্ষে মতামত বিতর্ক।

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

select <whatever>
from group g
where fn_invoker_has_access_to_group(g.group_id)

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

উপরের সমস্যার একটি সাধারণ সমাধান হ'ল ফাংশন থেকে যুক্তিটি বের করে এটিকে কোয়েরিতে মার্জ করা। এখন আপনি এনক্যাপসুলেশন এবং নকল যুক্তি ভাঙ্গলেন।

আর একটি সমস্যা যা আমি দেখতে পাচ্ছি তা একটি লুপে সঞ্চিত প্রক্রিয়াগুলি কল করছে কারণ সঞ্চিত ফলাফল ফলাফল সেটগুলিতে যোগদান বা ছেদ করার কোনও উপায় নেই।

declare some_cursor
while some_cursor has rows
    exec some_other_proc
end

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

সাধারণভাবে, আমি দেখতে পাচ্ছি যে ডেটাবেসগুলি এখানে খারাপ:

  1. গুনতি
  2. আইট্রেশন (তারা সেট অপারেশনের জন্য অনুকূলিত হয়)
  3. ভারসাম্য লোড করুন
  4. পদান্বয়

ডাটাবেসগুলি এখানে ভাল:

  1. লক করা এবং আনলক করা
  2. ডেটা এবং তাদের সম্পর্ক বজায় রাখা
  3. অখণ্ডতা নিশ্চিত করা

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

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

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

কোনও উইজেটের সাথে কী করা যেতে পারে এবং উইজেটগুলি সন্ধানের ব্যবসায়ের নিয়মগুলি আপনার অ্যাপ্লিকেশনটিতে অন্তর্ভুক্ত Def


8
এসকিউএল সার্ভারে কেবল দুর্বল লিখিত এসপিএসকে একটি লুপে কল করা দরকার, আপনি এটি প্যারামিটারে ডেটার সেটগুলি প্রেরণ করতে এবং সেট-ভিত্তিক প্রক্রিয়া করতে পারেন।
এইচএলজিইএম

2
এসকিউএল সার্ভার একটি উপ-অনুকূল কোয়েরি প্ল্যান উত্পন্ন করবে যখনই যেখানে কোনও ক্লাসে কোনও ইউডিএফ থাকবে।
জিম জি।

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

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

1
এই উদাহরণটি ডিবিতে বিজ লজিকের মূল অংশগুলি রাখার পক্ষেও যুক্তি: প্লেগের মতো পুনরাবৃত্ত পদ্ধতির (সেট-ভিত্তিক এক্সপ্রেশনগুলির পরিবর্তে কোড বা কার্সার লুপ) এড়ানোর জন্য। প্রোগ্রামাররা পুনরূদ্ধার পদ্ধতিতে (লুপ, ট্র্যাভার্স) অবজেক্টের সেটগুলি চিকিত্সা করার ঝোঁক দেয়, সম্ভবত অহেতুক লোড বা অনেকগুলি একক ক্যোয়ারী রাউন্ডট্রিপগুলির SELECT N + 1 সমস্যা দেখা দেয়। এসকিউএল বা ভাষা ভিত্তিক এক্সপ্রেশন (উদাঃ লিনকিউ) ব্যবহার করে, যখনই সম্ভব হবে তার পরিবর্তে সেট সেট ভিত্তিক ব্যবহার করতে বাধ্য করা হবে।
এরিক হার্ট 15

10

আমি 2 টি পৃথক সংস্থায় কাজ করেছি যার বিষয়ে এই বিষয়টির বিভিন্ন দৃষ্টিভঙ্গি ছিল।

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

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

সুতরাং যখন প্রয়োজন হয় তখন সাবধানতার সাথে স্টোরড পদ্ধতি ব্যবহার করুন।


3
সঞ্চিত পদ্ধতিগুলি ইউনিট পরীক্ষামূলক। কিছু কৌশল জন্য এখানে দেখুন ।
রবার্ট হার্ভে

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

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

1
আপনি যদি ডিবি এবং প্রয়োজনীয় বস্তু, এসপি, পরীক্ষা তৈরি করেন এবং তারপরে এটি ছিঁড়ে ফেলেন তবে এটি একটি ইউনিট পরীক্ষা। এটি কাজের একটি ইউনিট পরীক্ষা করে।
টনি হপকিনসন

2
সঞ্চিত পদ্ধতিগুলি অনুসারে পারফরম্যান্সের লাভগুলি কমে যায়নি?
জেফো

9

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

আপনি যেমনটি লক্ষ্য করেছেন, টি-এসকিউএল (বা অন্যান্য জনপ্রিয় আরডিবিএমএস এর সমতুল্য) জটিল ব্যবসায়ের যুক্তি কোডিংয়ের জন্য ঠিক সর্বোত্তম জায়গা নয়।

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


2
কোনও "অতিরিক্ত মূল্যের" কী / মান স্টোর হিসাবে ডাটাবেস ব্যবহার করা পুরোপুরি বৈধ কৌশল, কারণ নোএসকিউএল অনুশীলনকারীদের সৈন্যদল সত্যায়ন করবে।
রবার্ট হার্ভে

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

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

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

@ রাফেল বা আপনি পোস্টগ্রেএসকিউএল use
ডেমি

9

যদি আপনার ব্যবসায়িক যুক্তিতে সেট অপারেশনগুলি জড়িত থাকে তবে সম্ভবত এটির জন্য একটি ভাল জায়গা ডাটাবেসে থাকে কারণ ডেটাবেস সিস্টেমগুলি সেট অপারেশন সম্পাদন করতে সত্যিই ভাল।

http://en.wikipedia.org/wiki/Set_operations_(SQL)

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

যদিও এগুলি কঠোর এবং দ্রুত নিয়ম নয় তবে এটি একটি ভাল সূচনার পয়েন্ট।


6

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

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


3

কয়েক বছর পরে, এখনও প্রশ্নটি গুরুত্বপূর্ণ ...

আমার জন্য সরল নিয়মের থাম্ব: এটি যদি কোনও যৌক্তিক বাধা বা সর্বব্যাপী প্রকাশ (একক বিবৃতি) হয় তবে এটি ডাটাবেসে রাখুন (হ্যাঁ, বিদেশী কী এবং চেক সীমাবদ্ধতাগুলিও ব্যবসায়ের যুক্তি are যদি এটি পদ্ধতিগত হয় তবে লুপ এবং শর্তসাপেক্ষ শাখা (এবং সত্যই কোনও অভিব্যক্তিতে রূপান্তরিত করা যায় না) দ্বারা কোডে রেখে দিন put

ট্র্যাশ ডাম্প ডিবি এড়িয়ে চলুন

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

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

পদ্ধতিগত কোডের পরিবর্তে এক্সপ্রেশন (সেট-ভিত্তিক)

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

ডিবি ডেটা অখণ্ডতা প্রক্রিয়া ব্যবহার করুন

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

সঞ্চিত পদ্ধতি?

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

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


2

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

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

আধুনিক সময়ের অ্যাপ্লিকেশন বিকাশকারীটির দ্বিতীয় মডেলের সাথে আরও সখ্যতা থাকবে। আপনি যদি একটি বৃহত্তর ক্লায়েন্ট-সার্ভার সিস্টেমের সাথে বড় হন তবে আপনি সম্ভবত অন্য শিবিরে থাকবেন।

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


2

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

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

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


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