আমি কখন সঞ্চিত পদ্ধতি ব্যবহার করব?


19

যদি আমার কোডে আমার সমস্ত ব্যবসার যুক্তি থাকে এবং সত্তা ফ্রেমওয়ার্কটি ব্যবহার করি তবে কোন পরিস্থিতিতে (যদি কোনও হয়) আমি কিছু ব্যবসায়িক যুক্তিগুলি কোডের মধ্যে রাখার পরিবর্তে সঞ্চিত পদ্ধতিতে আরও ভালভাবে চালিত করতে পারি ?

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

যদি এটি কোনও পার্থক্য করে তবে আমি এমএসএসকিউএল এবং সত্তা ফ্রেমওয়ার্ক ব্যবহার করছি।


এই পরিস্থিতিতে আমি আগে সঞ্চিত পদ্ধতি ব্যবহার করেছি:

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

এই প্রশ্নটি জিজ্ঞাসা করার আগে আমি অন্যান্য পোস্টগুলি দেখেছি:


4
আপনার উভয় পরিস্থিতি সঞ্চিত প্রক্রিয়া লেখার জন্য পুরোপুরি বৈধ কারণ। তারা জিজ্ঞাসা করছেন কেন এগুলি বৈধ?
রবার্ট হার্ভে

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

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

উত্তর:


10

আপনার ইতিমধ্যে বেশ কয়েকটি পুরোপুরি ভাল দৃশ্য রয়েছে।

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

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

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


ধন্যবাদ জোয়েল, আপনি কয়েকটি অন্যান্য দৃশ্যের কথা বলেছিলেন যা আমি ভাবিনি।
অ্যামি ব্যারেট

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

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

2

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

যদি এটি কোনও পার্থক্য করে তবে আমি এমএসএসকিউএল এবং সত্তা ফ্রেমওয়ার্ক ব্যবহার করছি।

মতিন আমার জ্ঞান সীমাবদ্ধ, তবে যতদূর আমি দেখতে পারেন, মতিন (হয় মাত্র ) অন্য কোন মত ORM; এবং ভাগ্যক্রমে কাঁচা এসকিউএল ব্যবহার করতে সক্ষম ।

আমি যদি আপনার দুটি প্রধান বিষয় গ্রহণ করি:

একটি জটিল প্রতিবেদন যা চালাতে কয়েক মিনিট সময় নিচ্ছিল (এটি একটি ওয়েব অ্যাপ্লিকেশনে একটি পৃষ্ঠা ছিল)। আমি দেখতে পেয়েছি যে আমি এসকিউএল লিখতে পারি যা লিনকিউ সরবরাহ করে যা তার চেয়ে অনেক বেশি দক্ষ (চালাতে কয়েক সেকেন্ড সময় নেয়)।

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

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

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

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

এখানে দেখার মতো কিছুই নেই।

অন্যরা কিছু পয়েন্ট দেখে:

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

তবে তা SQLকরতে পারে। এখানে কোন জাদু জড়িত নেই।

আপনার ডাটাবেস ইএফ দিয়ে ভাল খেলছে না

আবার: উপযুক্ত হলে EF ব্যবহার করুন ।

লিঙ্কযুক্ত সার্ভারগুলির সাথে সার্ভারের সীমানা অতিক্রম করে এমন ডেটা নিয়ে আপনাকে কাজ করতে হবে

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

আপনার কাছে অত্যন্ত জটিল তথ্য পুনরুদ্ধার পরিস্থিতি রয়েছে যেখানে পর্যাপ্ত কর্মক্ষমতা নিশ্চিত করতে "বেয়ার মেটাল" এসকিউএল প্রয়োজন

আবার: "সীমানা মতিন "।

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

ঠিক আছে. আমি সম্ভবত সঙ্গে যেতে ।

এখন পর্যন্ত কেবল অর্ধ পয়েন্ট সঞ্চিত পদ্ধতির পক্ষে করা হয়েছিল।


সম্ভবত কর্মক্ষমতা বিবেচনা রয়েছে, যা সঞ্চিত পদ্ধতির পক্ষে কথা বলে।

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

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

2) তবুও এটি একটি ডিবিতে জটিল প্রশ্নগুলি সংরক্ষণ করার পক্ষে যুক্তিযুক্ত ছিল । দুটি বিষয় বিবেচনা করতে হবে:

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

খ) যদি ক্যোয়ারী যাইহোক সময় নেয়, তবে কেন একটি সঞ্চিত পদ্ধতির ক্ষুদ্র গতির জয় নিয়ে বিরক্ত করুন।

TL; ড

সঞ্চিত পদ্ধতিগুলির বিরুদ্ধে সরাসরি কিছুই বলে না । সুতরাং সঞ্চিত পদ্ধতি ব্যবহার করা ঠিক আছে - যদি এটি আপনাকে খুশি করে।

তবে অন্যদিকে: আমি কোনও যথাযথ ব্যবহারের ক্ষেত্রে কল্পনা করতে পারি নি যা স্পষ্টতই বক্তব্য রাখে ।

আমি কখন সঞ্চিত পদ্ধতি ব্যবহার করব?

যথাযথ উত্তরটি: যখনই আপনি পছন্দ করেন । কিন্তু অন্যান্য অপশন আছে।


0

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

সত্তা কাঠামোটি একটি সুনির্দিষ্ট কাজ করে এবং কার্য সম্পাদন সঞ্চিত পদ্ধতি ব্যবহারের কাছাকাছি বা সমান হবে। আপনি সত্তা কাঠামোটি বেছে নিয়েছেন কারণ আপনি এসকিউএল সম্পর্কিত হতে চান না এবং ফ্রেমওয়ার্কটি আপনার জন্য এসকিউএল তৈরি করতে দেবে।

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

সুতরাং, যদি না কাঠামোগত নিযুক্ত করা হচ্ছে প্রয়োজনীয়তাটি না পূরণ করে আমি কোনও সঞ্চিত পদ্ধতিতে কোনও স্থানান্তরিত করব না।

আমি মনে করি যে সবচেয়ে খারাপটি ঘটতে পারে তা হ'ল যে ব্যক্তি সত্তা কাঠামোটি ব্যবহার করতে পছন্দ করে এবং তারপরে সমস্ত সঞ্চিত প্রক্রিয়াটি লিখে দেয়। এখন একটির একটি অতিরিক্ত স্তর রয়েছে যা কোনও মূল্য যুক্ত করে না।


100% শেষ অনুচ্ছেদের সাথে একমত
ইভান

0

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

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

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

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

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


0

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

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

সম্পাদনা: যখন বিকাশকারীরা আমাকে ব্যবসায় / ডেটা অ্যাক্সেস লজিক সম্পর্কে জিজ্ঞাসা করে, আমি বলি যে ব্যবসায়িক যুক্তি ডেটা কীভাবে আচরণ করে এবং ইন্টারঅ্যাক্ট করে সে সম্পর্কে, যখন ডেটা অ্যাক্সেস লজিক কীভাবে ডেটা সংরক্ষণ এবং পুনরুদ্ধার করা হয় about

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

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

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


2
আপনি কীভাবে ব্যবসায়িক যুক্তি এবং ডেটা অ্যাক্সেস লজিককে সংজ্ঞায়িত করবেন ?
অ্যামি ব্যারেট


লিঙ্কগুলির জন্য ধন্যবাদ ডেটা অ্যাক্সেস লেয়ারটি ডেটা অ্যাক্সেস লজিকের মতো? আমি জিজ্ঞাসা করলাম যেহেতু ডেটা অ্যাক্সেস লেয়ারের সাথে জড়িত কোনও আসল যুক্তিযুক্ত বলে মনে হচ্ছে না - কেবল সাধারণ সিআরইউডি অপারেশন।
অ্যামি ব্যারেট

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

@ রবার্টহারভে যদিও এই কাস্টম পদ্ধতিগুলি ব্যবসায় যুক্তিযুক্ত স্তরের অন্তর্ভুক্ত নয়?
অ্যামি ব্যারেট

-4

আমি মনে করি এখানে তিনটি বিষয় আছে।

  1. এসকিউএলে ব্যবসায়ের যুক্তিটি খারাপ is এমনকি যদি এটি দ্রুত পৃথকভাবে চালায় তবে তা স্কেল করে না।

  2. ট্রেডিয়োনালি স্প্রোকগুলি সর্বদা বিমূর্ত স্তর হিসাবে সমস্ত ডেটা অ্যাক্সেসের জন্য ব্যবহার করা উচিত। গ্রাহক অ্যাপ্লিকেশনগুলিকে প্রভাবিত না করে পারফরম্যান্স বা অন্যান্য ডেটালেয়ার পরিবর্তনের জন্য ডিবিএ সক্ষম করা।

  3. EF স্প্রোকস দিয়ে দুর্দান্ত খেলছে না। আপনি লিনকের গতিশীল ক্যোয়ারী জেনারেশন থেকে সরে গিয়ে 'ভাল' বৈশিষ্ট্য এবং উত্পাদনশীলতা লাভগুলি হারাবেন।

সুতরাং আমার সামগ্রিক পরামর্শ হতে হবে

  • সমস্ত এসকিউএল প্রশ্নের জন্য SPROCs ব্যবহার করুন,

  • এগুলিতে ব্যবসায়িক যুক্তি বা কোনও ধরণের লুপ রাখবেন না,

  • EF ব্যবহার করবেন না।


কারণ সমস্ত এসকিউএল ডিবি সার্ভারে চলে আপনি অতিরিক্ত গণনা বাক্সের চেয়ে অতিরিক্ত ডিবিএস দিয়ে স্কেল করতে পারবেন।
ইয়ান

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

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

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

3
এটি সামগ্রিকভাবে খারাপ পরামর্শ। ডেটা অ্যাক্সেসের জন্য প্রচুর বিকল্প রয়েছে যা হ্যান্ড-কোডিং স্টোরেজ প্রক্রিয়াগুলির সুবিধাগুলি রাখে এবং ঠিক একইভাবে সম্পাদন করে। আপনি সরাসরি ইএফ থেকে স্প্রোকস চালাতে পারেন; প্রকৃতপক্ষে, আপনি সরাসরি EF থেকে যে কোনও এসকিএল কোয়েরি চালাতে পারেন । কিছু ব্যবসায়িক যুক্তি একটি ডাটাবেস সার্ভারে আরও ভাল চলে, তাই আপনি স্পষ্টভাবে বলতে পারবেন না যে এটি এখানে নিষিদ্ধ। অবজেক্ট রিলেশনাল ম্যাপারগুলি একটি 80% সরঞ্জাম; এগুলি কখনই আপনার ডেটা অ্যাক্সেস প্রক্রিয়াগুলিকে সম্পূর্ণরূপে প্রতিস্থাপন করার উদ্দেশ্যে নয়। সেগুলির জন্য যা ব্যবহার করা হচ্ছে তার জন্য সঞ্চিত পদ্ধতি ব্যবহার করুন: 20% যা একটি ওআরএম ভাল করে না।
রবার্ট হার্ভে
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.