সঞ্চিত পদ্ধতি বনাম ইনলাইন এসকিউএল

Question

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

আমি এর প্রযুক্তিগত যুক্তি জানতে চাই (এমন পদ্ধতিতে যা আমি এটি পরে কারও কাছে ব্যাখ্যা করতে পারি)।

কেউ কি আমাকে একটি ভাল উত্তর তৈরি করতে সহায়তা করতে পারে?

Comments

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

— marc_s

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

— অ্যারন বারট্র্যান্ড

Answer 1

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

আমি এখনও নিম্নলিখিত কারণে ডিবিএ পক্ষ থেকে সঞ্চিত পদ্ধতি পছন্দ করি (এবং তাদের বেশিরভাগই পারফরম্যান্সে বিশাল প্রভাব ফেলতে পারে):

• যদি আমার কাছে একাধিক অ্যাপ থাকে যা একই ক্যোয়ারীগুলি পুনরায় ব্যবহার করে থাকে তবে একটি সঞ্চিত পদ্ধতিতে বিভিন্ন কোডবেসে একাধিকবার একই অ্যাডহক ক্যোয়ারিকে লিটারের পরিবর্তে সেই যুক্তিকে আবদ্ধ করে। যে অ্যাপ্লিকেশনগুলি একই প্রশ্নগুলি পুনরায় ব্যবহার করে সেগুলি ক্যাপ ব্লাটেম না করে প্ল্যান ক্যাশে ব্লাট এর বিষয় হতে পারে। এমনকি সাদা জায়গার ক্ষেত্রেও পার্থক্য একই পরিকল্পনার একাধিক সংস্করণ সঞ্চিত হতে পারে (অপব্যয়)।
• অ্যাপ্লিকেশন সোর্স কোড অ্যাক্সেস না করে বা অ্যাপ্লিকেশনটি ঠিক কী করছে তা দেখার জন্য ব্যয়বহুল ট্রেস না চালিয়ে কোনও জিজ্ঞাসা কী করছে তা আমি পরিদর্শন ও সমস্যা সমাধান করতে পারি।
• অ্যাপ্লিকেশনটি কী কী ক্যোয়ারী চালাতে পারে, কোন টেবিলগুলি অ্যাক্সেস করতে পারে এবং কোন প্রসঙ্গে, ইত্যাদিও আমি নিয়ন্ত্রণ করতে পারি (এবং আগে থেকেই জানতে পারি) বিকাশকারীরা যদি তাদের অ্যাপ্লিকেশনটিতে অ্যাড-হক প্রশ্নগুলি লিখছে, তবে তাদের হয় তা করতে হবে আমার শার্টের আস্তিনটি যখনই টেবিলের অ্যাক্সেসের প্রয়োজন হয় তখন তার সম্পর্কে জানতে পারি বা ভবিষ্যদ্বাণী করতে পারি না, বা আমি যদি কম দায়বদ্ধ / প্রলোভনযুক্ত এবং / অথবা সুরক্ষা-সচেতন হয়ে থাকি তবে আমি কেবল সেই প্রচার করতে যাচ্ছি ব্যবহারকারীরা ডিবিও করতে যাতে তারা আমাকে পারা বন্ধ করে দেয়। সাধারণত এটি করা হয় যখন বিকাশকারীরা ডিবিএ বা ডিবিএর চেয়ে অনড় থাকে। এই শেষ পয়েন্টটি আমাদের খারাপ, এবং আপনার প্রয়োজনীয় প্রশ্নগুলি সরবরাহ করার জন্য আমাদের আরও ভাল হওয়া দরকার।
• সম্পর্কিত নোটে, সঞ্চিত পদ্ধতিগুলির সেটগুলি আমার সিস্টেমে কী কী প্রশ্নগুলি চলতে পারে তা আবিষ্কার করার খুব সহজ উপায় qu যত তাড়াতাড়ি কোনও অ্যাপ্লিকেশনকে প্রক্রিয়াটি বাইপাস করার এবং তার নিজস্ব অ্যাডহক কোয়েরি জমা দেওয়ার অনুমতি দেওয়া হয়েছে, তাদের সন্ধান করার জন্য, আমাকে একটি ট্রেস চালাতে হবে যা পুরো ব্যবসায়ের চক্রকে আচ্ছাদিত করে, বা অ্যাপ্লিকেশন কোডের সমস্তটি পার্স করে (আবার, কোয়েরির মতো মনে হচ্ছে এমন কোনও কিছু পেতে আমার অ্যাক্সেস নাও থাকতে পারে)। সঞ্চিত প্রক্রিয়াগুলির তালিকা দেখতে সক্ষম হওয়া (এবং sys.sql_modulesনির্দিষ্ট সামগ্রীর উল্লেখের জন্য একক উত্সকে গ্রেপ করা ) প্রত্যেকের জীবনকে আরও সহজ করে তোলে।
• এসকিউএল ইঞ্জেকশনটি রোধ করতে আমি অনেক বেশি দৈর্ঘ্যে যেতে পারি; এমনকি যদি আমি ইনপুট নিই এবং এটি ডায়নামিক এসকিউএল দিয়ে চালিত করি, তবে যা ঘটতে দেওয়া হচ্ছে তার অনেকগুলি নিয়ন্ত্রণ করতে পারি। ইনলাইন এসকিউএল স্টেটমেন্টগুলি তৈরি করার সময় কোনও বিকাশকারী কী করছে তার উপর আমার কোনও নিয়ন্ত্রণ নেই।
• আমি অ্যাপ্লিকেশন উত্স কোড অ্যাক্সেস না করেই ক্যোয়ারী (বা প্রশ্নগুলি) অপ্টিমাইজ করতে পারি, পরিবর্তনগুলি করার ক্ষমতা, কার্যকরভাবে প্রয়োগ করার জন্য অ্যাপ্লিকেশন ভাষার জ্ঞান, কর্তৃপক্ষ (ঝামেলা মনে করবে না) পুনরায় সংকলন এবং পুনরায় স্থাপনার জন্য অ্যাপ্লিকেশন ইত্যাদি অ্যাপ্লিকেশন বিতরণ করা হলে এটি বিশেষত সমস্যাযুক্ত।
• এসএসএমএসে দ্রুত, অ্যাপ্লিকেশনটির কিছুটা ধীর গতির বিষয় হতে পৃথক প্রশ্নগুলি এড়ানোর জন্য আমি স্টোরেজ পদ্ধতিতে নির্দিষ্ট সেট বিকল্পগুলি জোর করতে পারি ? সমস্যা। এর অর্থ হ'ল দুটি পৃথক অ্যাপ্লিকেশনের জন্য অ্যাডহক কোয়েরিতে কল করার জন্য একটির কাছে থাকতে পারে SET ANSI_WARNINGS ONএবং অন্যটির কাছে থাকতে পারে SET ANSI_WARNINGS OFFএবং তাদের প্রত্যেকের পরিকল্পনার নিজস্ব অনুলিপি থাকবে। তারা যে পরিকল্পনাটি পাবে তা ব্যবহারের প্যারামিটার, স্থানের পরিসংখ্যান ইত্যাদির উপর নির্ভর করে। প্রতিটি ক্ষেত্রে কোয়েরিকে প্রথমবার বলা হয়, যা বিভিন্ন পরিকল্পনা তৈরি করতে পারে এবং তাই খুব আলাদা পারফরম্যান্সের কারণ হতে পারে।
• আমি ডেটা টাইপের মতো জিনিসগুলি কীভাবে নিয়ন্ত্রণ করতে পারি এবং কীভাবে প্যারামিটারগুলি ব্যবহার করা হয় তা নির্দিষ্ট ওআরএম থেকে আলাদা - EF এর মতো কিছু পূর্ববর্তী সংস্করণগুলি প্যারামিটারের দৈর্ঘ্যের উপর ভিত্তি করে কোনও ক্যোয়ারিকে প্যারামিটারাইজ করবে, সুতরাং আমার যদি N'Smith 'এবং অন্য একটি প্যারামিটার থাকত জনসন 'আমি এই পরিকল্পনার দুটি ভিন্ন সংস্করণ পেয়েছি। তারা এটি স্থির করেছে। তারা এটি ঠিক করে ফেলেছে তবে আরও কী ভাঙা আছে?
• আমি এমন কিছু করতে পারি যা ওআরএম এবং অন্যান্য "সহায়ক" ফ্রেমওয়ার্ক এবং গ্রন্থাগারগুলি এখনও সমর্থন করতে সক্ষম হয় নি।

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

Comments

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

— ডেভিড ক্রোয়েল

Answer 2

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

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

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

আরও নির্দিষ্টভাবে, নিম্নলিখিত উপাদানগুলি রয়েছে:

• সিরিয়াল এবং সমান্তরাল ক্যোয়ারী পরিকল্পনা যা ব্যবহারকারীর প্রসঙ্গটি ধরে রাখে না এবং ডিবি ইঞ্জিন দ্বারা পুনরায় ব্যবহারের অনুমতি দেয়।
• এক্সিকিউশন প্রসঙ্গ যা বিভিন্ন ডেটা পরামিতি সহ নতুন ব্যবহারকারীর দ্বারা ক্যোয়ারী প্ল্যানের পুনরায় ব্যবহারের অনুমতি দেয়।
• প্রক্রিয়া ক্যাশে যা আমরা অনুসন্ধান করি তার কার্যকারিতা তৈরি করতে ডিবি ইঞ্জিন অনুসন্ধান করে।

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

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

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

• দ্রষ্টব্য: এইডক এক্সিকিউশন পরিকল্পনা - বর্তমান ব্যয় প্রতিটি ব্যবহারকারীর প্রক্রিয়া দ্বারা, পরিকল্পনার মূল সংকলন ব্যয় দ্বারা বৃদ্ধি করা হয়। তবে কোনও পরিকল্পনার সর্বোচ্চ ব্যয়টি মূল সংকলন ব্যয়ের চেয়ে বেশি হতে পারে না ... অ্যাডহক প্রশ্নের ক্ষেত্রে ... শূন্যের ক্ষেত্রে। সুতরাং, এটি সেই মান দ্বারা "বৃদ্ধি" হবে ... শূন্য - যার মূল অর্থ এটি সর্বনিম্ন ব্যয় পরিকল্পনা হিসাবে থাকবে।

অতএব, মেমরির চাপ সৃষ্টি হওয়ার পরে এই জাতীয় পরিকল্পনাটি প্রথম উচ্ছেদ করা সম্ভব বলে সম্ভবত যথেষ্ট সম্ভাবনা রয়েছে।

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

এখন, আমি যদি এক বা একাধিক বিষয় সম্পর্কে সত্যই ভুল হয় তবে আমি অবশ্যই সংশোধন করার জন্য উন্মুক্ত open

সবশেষে, লেখক লিখেছেন:

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

আমি বিশ্বাস করি যে লেখক "অ্যাডহক ওয়ার্কলোডের জন্য অনুকূলিতকরণ" বিকল্পটি উল্লেখ করছেন।

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

তবে, আপনাকে এই বিকল্পটি চালু করতে হবে, যেহেতু এটি ডিফল্টরূপে বন্ধ রয়েছে।

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

অতিরিক্ত তথ্যের জন্য, দয়া করে দেখুন:

https://technet.microsoft.com/en-us/library/ms181055(v=sql.105).aspx
http://sqlmag.com/datedia-performance-tuning/don-t-fear-dynamic-sql

সেরা,
হেনরি

Comments

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

— পিটার জেরকেন্স

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

— হেনরি

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

— অ্যারন বার্ট্র্যান্ড

দেখে মনে হচ্ছে আপনার "অ্যাডহক" এসকিউএলকে ঘৃণা করা এই ধারণাটির উপর ভিত্তি করে তৈরি করা হয়েছে যে এসকিএল কোনওভাবে মৃত্যুদণ্ডের মধ্যে পরিবর্তিত হচ্ছে ... পরামিতি জড়িত থাকার সময় এটি সম্পূর্ণ অসত্য হয় unt

— বি_লিট

Answer 3

টিএলডিআর: যতক্ষণ না আপনার ইনলাইন স্কেলটি প্যারামিটারাইজড হয় ততক্ষণ দুটির মধ্যে কোনও প্রশংসনীয় পারফরম্যান্স পার্থক্য নেই।

এই কারণেই আমি ধীরে ধীরে সঞ্চিত প্রক্রিয়াটি পর্যবসিত করেছি:

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

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

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

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

  ...

  * থেকে select (ফর্ম্যাট) select "নির্বাচন করুন

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

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

প্রকস ব্যবহারের জন্য বৈধ কারণ রয়েছে:

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

• পুনঃব্যবহার - যদিও আমি বলব যে পুনঃব্যবহারটি মূলত ব্যবসায়ের স্তরে ঘটতে হবে তা নিশ্চিত করার জন্য যে আপনি নন-ডিবি সম্পর্কিত ব্যবসায়িক বিধিগুলি বাইপাস করছেন না, তবুও আমাদের কাছে ঘটনামূলক, নিম্ন স্তরের "সর্বত্র ব্যবহৃত" প্রকারের ইউটিলিটি প্রোক এবং ফাংশন রয়েছে।

কিছু যুক্তি রয়েছে যা প্রকৃত পক্ষে সমর্থন করে না বা সহজেই আইএমও প্রশমিত করা হয়:

• পুনঃব্যবহার - আমি এটি উপরে "প্লাস" হিসাবে উল্লেখ করেছি, তবে এখানে এটি উল্লেখ করতেও চেয়েছিলাম যে পুনরায় ব্যবহারটি মূলত ব্যবসায়ের স্তরে হওয়া উচিত। ব্যবসায়ের স্তরটি অন্য নন-ডিবি পরিষেবাও চেক করতে পারে এমন সময় একটি রেকর্ড সন্নিবেশ করানোর জন্য একটি "পুনরায় ব্যবহারযোগ্য" হিসাবে বিবেচনা করা উচিত নয়।

• ক্যাশে প্ল্যান ব্লাট - যদি আপনি প্যারামিটারাইজিংয়ের পরিবর্তে মানগুলি সংশ্লেষ করেন তবে একমাত্র উপায় এটি হয়ে উঠবে। আপনি প্রকৃত পক্ষে কমই একাধিক পরিকল্পনা পেয়েছেন তা আসলে আপনাকে প্রায়শই ব্যথা দেয় যখন আপনার কোনও প্রশ্নের মধ্যে 'বা' থাকে

• বিবৃতি আকার - অধিগ্রহণকারী নামের উপর বর্ধিত অতিরিক্ত বর্গক্ষেত্রের ডেটা ফিরে আসার তুলনায় নগন্য হতে চলেছে। এটি যদি প্রতিষ্ঠানের পক্ষে ঠিক থাকে তবে এটি আমার পক্ষে ঠিক।

• সঠিক ক্যোয়ারীটি দেখে - কোডগুলিতে কোডগুলি অনুসন্ধান করা সহজ করে জিজ্ঞাসা করা কোডে মন্তব্য হিসাবে কলিংয়ের অবস্থান যুক্ত করার মতোই সহজ। সি # কোড থেকে এসএমএসে কোড অনুলিপি তৈরি করা কিছু সৃজনশীল ইন্টারপোলেশন এবং মন্তব্য ব্যবহারের মতোই সহজ:

      //Usage /*{SSMSOnly_}*/Pure Sql To run in SSMS/*{_SSMSOnly}*/
      const string SSMSOnly_ = "*//*<SSMSOnly>/*";
      const string _SSMSOnly = "*/</SSMSOnly>";
      //Usage /*{NetOnly_}{InterpolationVariable}{_NetOnly}*/
      const string NetOnly_ = "*/";
      const string _NetOnly = "/*";
  

• এসকিউএল ইঞ্জেকশন - আপনার প্রশ্নের প্যারামিটারাইজ করুন। সম্পন্ন. প্রকৃত পরিবর্তে ডায়নামিক এসকিএল ব্যবহার করা থাকলে এটি আসলে পূর্বাবস্থায় ফেরা যাবে।

• বাইপাস স্থাপনা - আমরা পাশাপাশি ডাটাবেস পর্যায়ে ডিওপস অনুশীলন করি, সুতরাং এটি আমাদের পক্ষে বিকল্প নয়।

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

• ইনলাইন স্ক্যুএল কার্যকর করার পরিকল্পনাগুলি ক্যাশেড নয় - কেবল মিথ্যা। একটি প্যারামিটারাইজড স্টেটমেন্ট, ঠিক তেমনি প্রোক নামটি দ্রুত হ্যাশ করা হয় এবং তারপরে সেই হ্যাশ দ্বারা একটি পরিকল্পনা অনুসন্ধান করা হয়। এটি 100% একই।

• পরিষ্কার হওয়ার জন্য আমি কোনও ওআরএম থেকে কাঁচা ইনলাইন স্কয়ারের উত্পন্ন কোডের কথা বলছি - আমরা কেবল ড্যাপার ব্যবহার করি যা সর্বোত্তমভাবে একটি মাইক্রো ওআরএম।

https://weblogs.asp.net/fbouma/38178

/programming//a/15277/852208