কেন অবশ্যই টিভিপিগুলি কেবলমাত্র প্রস্তুত হতে হবে এবং অন্যান্য ধরণের পরামিতিগুলি কেন প্রস্তুত হতে পারে না

19

এই ব্লগের পরামিতিগুলি অনুসারে কোনও ফাংশনে বা সঞ্চিত পদ্ধতিগুলি মূলত যদি OUTPUTপ্যারামিটার না হয় তবে তা পাস-বাই-ভ্যালু হয় এবং মূলত যদি তারা OUTPUTপরামিতি হয় তবে পাস-বাই-রেফারেন্সের নিরাপদ সংস্করণ হিসাবে বিবেচিত হবে ।

প্রথমে আমি ভেবেছিলাম টিভিপি জোর করে বলার লক্ষ্যটি READONLYবিকাশকারীদের কাছে স্পষ্টভাবে ইঙ্গিত দেওয়া ছিল যে টিভিপিটিকে OUTPUTপ্যারামিটার হিসাবে ব্যবহার করা যাবে না , তবে আরও কিছু করা আবশ্যক কারণ আমরা নন-টিভিপি হিসাবে ঘোষণা করতে পারি না READONLY। উদাহরণস্বরূপ নিম্নলিখিত ব্যর্থতা:

create procedure [dbo].[test]
@a int readonly
as
    select @a

এমএসজি 346, স্তর 15, রাজ্য 1, পদ্ধতি পরীক্ষা
"@ ক" প্যারামিটারটি কেবলমাত্র ঘোষণা করা যাবে না কারণ এটি কোনও সারণী-মূল্যবান প্যারামিটার নয়।

যেহেতু টিভিপিতে পরিসংখ্যান সংরক্ষণ করা হয় না তাই ডিএমএল কার্যক্রম বন্ধ করার পিছনে যুক্তি কী?
এটি OUTPUTকোনও কারণে টিভিপিকে প্যারামিটার হিসাবে না দেখার সাথে সম্পর্কিত ?

— এরিক
সূত্র

19

ব্যাখ্যাটির সংমিশ্রণে আবদ্ধ বলে মনে হচ্ছে: ক) এই প্রশ্নটিতে উল্লিখিত হয়নি এমন লিঙ্কযুক্ত ব্লগের একটি বিশদ, খ) কীভাবে প্যারামিটারগুলি সর্বদা প্রবেশ ও আউট হয়ে গেছে, গ) এবং প্রকৃতিতে কীভাবে টিভিপিগুলির ফিটনেস রয়েছে? টেবিল ভেরিয়েবলের।

লিঙ্কযুক্ত ব্লগ পোস্টে থাকা অনুপস্থিত বিবরণটি হ'ল কীভাবে ভেরিয়েবলগুলি সঞ্চিত প্রক্রিয়া এবং ফাংশনগুলিতে এবং আউট করা হয় (যা "ওপুটপুট প্যারামিটার হলে পাস-বাই-রেফারেন্সের একটি সুরক্ষিত সংস্করণ" এর প্রশ্নে শব্দবন্ধের সাথে সম্পর্কিত) :

টিএসকিউএল সঞ্চিত পদ্ধতি এবং ফাংশনগুলিতে পরামিতিগুলি পাস করার জন্য একটি অনুলিপি / অনুলিপি-শব্দার্থক শব্দ ব্যবহার করে ....

... যখন স্টোরড প্রোকটি সম্পাদন শেষ করে (কোনও ত্রুটি না মেরে) একটি অনুলিপি তৈরি করা হয় যা স্টোরক প্রোচে এটির সাথে করা কোনও পরিবর্তন সহ প্যারামিটারটি পাস করে আপডেট করে।

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

যদি OUTPUT কীওয়ার্ডটি উপস্থিত না থাকে তবে কোনও অনুলিপি তৈরি করা হয় না।

নীচের লাইন:
সঞ্চিত প্রকোসগুলিতে পরামিতিগুলি কোনও ত্রুটির সম্মুখীন হয়ে থাকলে কখনও কখনও সংরক্ষণ করা প্রকল্পের আংশিক সম্পাদন প্রতিফলিত করে না।

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

অংশ 1 যোগফল: পরিবর্তনশীল মান সর্বদা অনুলিপি করা হয়; তারা তাদের মেমরি ঠিকানা দ্বারা উল্লেখ করা হয় না।
পার্ট 1 টি মাথায় রেখে, চলক মানগুলি সর্বদা অনুলিপি করার নীতিটি যখন ভেরিয়েবলটি বেশ বড় হয় তখন রিসোর্সের সমস্যাগুলিকে ডেকে আনতে পারে। আমি দেখতে কিভাবে ফোঁটা ধরনের পরিচালনা করা হয় পরীক্ষিত হয় নি ( VARCHAR(MAX), NVARCHAR(MAX), VARBINARY(MAX), XML, এবং যারা যে আর ব্যবহার করা উচিত: TEXT, NTEXT, এবং IMAGE), কিন্তু এটা নিরাপদ বলতে চাই যে তথ্য কোনো টেবিল প্রেরণ করা হচ্ছে বেশ বড় হতে পারে। টিভিপি বৈশিষ্ট্য বিকাশকারীদের পক্ষে তাদের শীতল নতুন বৈশিষ্ট্যটিকে স্বাস্থ্যকর সংখ্যক সিস্টেম (যেমন আরও একটি স্কেলযোগ্য পদ্ধতির প্রয়োজন) নষ্ট করা থেকে রোধ করার জন্য একটি সত্য "পাস-বাই-রেফারেন্স" দক্ষতা কামনা করা অর্থপূর্ণ হবে। আপনি ডকুমেন্টেশনে দেখতে পাচ্ছেন যে তারা এগুলি করেছিল:

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

এছাড়াও, এই মেমরি পরিচালনার উদ্বেগটি কোনও নতুন ধারণা ছিল না যেহেতু এটি এসকিউএলসিআরআর এপিআই-তে পাওয়া যায় যা এসকিউএল সার্ভার ২০০৫ সালে চালু হয়েছিল (এসকিউএল সার্ভার ২০০৮ সালে টিভিপিগুলি চালু হয়েছিল)। এসকিউএলসিআর কোডে পাস করার সময় NVARCHARএবং VARBINARYডেটা যখন (কোনও এসকিউএলসিআরএল অ্যাসেমব্লির মধ্যে .NET পদ্ধতিতে ইনপুট প্যারামিটার) থাকে তখন আপনার কাছে হয় যথাক্রমে SqlStringবা SqlBinaryযথাক্রমে "মান দ্বারা" পদ্ধতির সাথে যেতে, বা আপনি "রেফারেন্স দ্বারা" যেতে পারেন "হয় SqlCharsবা SqlBytesযথাক্রমে ব্যবহার করে পন্থা । SqlCharsএবং SqlBytesধরনের .NET CLR ডেটা পূর্ণ স্ট্রিমিং যেমন যে আপনি (2 GB পর্যন্ত ডান) একটি সম্পূর্ণ 200 মেগাবাইট অনুলিপি বিরোধিতা মান বৃহৎ মূল্যবোধের ছোট খন্ডে টান করতে পারেন জন্য অনুমতি দেয়।

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

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

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

অতএব:READONLY শব্দ TVPs যেহেতু তারা ছক ভেরিয়েবল যে আসলে "রেফারেন্স দ্বারা" পাস হয় উপর DML অপারেশন প্রতিরোধ করা প্রয়োজন হয়, এবং অত: পর তাদের কোনো পরিবর্তন অবিলম্বে প্রতিফলিত হবে, এমনকি যদি সঞ্চিত পদ্ধতি কোনো ত্রুটির সম্মুখীন, এবং নেই এটি রোধ করার অন্যান্য উপায়।

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

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

খুব বিস্তারিত ব্যাখ্যা। ধন্যবাদ। সুতরাং কোনও সঞ্চিত প্রক্রিয়া সহ উত্তীর্ণ টেবিল ভেরিয়েবল (ব্যবহারকারী টিভিপি TYPEভেরিয়েবল বা ক DECLARE x as TABLE (...)) পরিবর্তিত করার কোনও উপায় নেই ? বৃহত্তর মেমরির পদক্ষেপ সহ আমি কি এটি করতে পারি, তার পরিবর্তে কোনও ফাংশন সহ set @tvp = myfunction(@tvp)যদি আমার ফাংশনের RETURNSমানটি টিভি ডি টাইপের মতো একই ডিডিএল সহ একটি টেবিল হয়?

— এমপ্যাগ

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

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

আবার ধন্যবাদ. আমি মূলত একটি টেম্প টেবিল পদ্ধতির ব্যবহার করার সিদ্ধান্ত নিয়েছি।

— এমপ্যাগ

5

_{সম্প্রদায় উইকি উত্তর মার্টিন স্মিথ প্রশ্নের উপর একটি মন্তব্য থেকে উত্পন্ন}

এর জন্য একটি সক্রিয় সংযোগ আইটেম রয়েছে (এরল্যান্ড সোমমারস্কোগ জমা দিয়েছেন):

স্বাচ্ছন্দ্য সীমাবদ্ধতা যে এসপিরা একে অপরকে কল করলে টেবিলের পরামিতিগুলি কেবল পঠনযোগ্য

মাইক্রোসফ্টের একমাত্র প্রতিক্রিয়া এখনও অবধি বলেছে (জোর দেওয়া)

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

শ্রীনী আচার্য
সিনিয়র প্রোগ্রাম ম্যানেজার
এসকিউএল সার্ভার রিলেশনাল ইঞ্জিন

— পল হোয়াইট
সূত্র