একটি "প্রাকদর্শন মোড" দিয়ে ডাটাবেস সঞ্চিত পদ্ধতি

Question

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

এটি সম্পাদন করার একটি উপায় হ'ল ifপ্যারামিটারের জন্য কেবল বিবৃতি রচনা করা এবং দুটি সম্পূর্ণ কোড ব্লক থাকা; যার মধ্যে একটি আপডেট করে এবং ডেটা দেয় এবং অন্যটি কেবল ডেটা দেয়। তবে কোড অনুলিপি এবং অপেক্ষাকৃত কম ডিগ্রির আত্মবিশ্বাসের কারণে এটি অনাকাঙ্ক্ষিত যে প্রাকদর্শন ডেটা আসলে কোনও আপডেটের সাথে কী ঘটবে তার সঠিক প্রতিচ্ছবি।

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

দ্রষ্টব্য: লেনদেন রোলব্যাকগুলি কোনও বিকল্প নয় কারণ এই প্রক্রিয়া কলটি কোনও লেনদেনে নিজেই বাসা বাঁধতে পারে। এটি এসকিউএল সার্ভার ২০১২-তে পরীক্ষা করা হয়েছে।

CREATE TABLE dbo.user_table (a int);
GO

CREATE PROCEDURE [dbo].[PREVIEW_EXAMPLE] (
  @preview char(1) = 'Y'
) AS

CREATE TABLE #dataset_to_return (a int);

BEGIN TRANSACTION; -- preview mode required infrastructure
  DECLARE @output_to_return TABLE (a int);
  SAVE TRANSACTION savepoint;

  -- do stuff here
  INSERT INTO dbo.user_table (a)
    OUTPUT inserted.a INTO @output_to_return (a)
    VALUES (42);

  -- catch preview mode
  IF @preview = 'Y'
    ROLLBACK TRANSACTION savepoint;

  -- save output to temp table if used for return data
  INSERT INTO #dataset_to_return (a)
  SELECT a FROM @output_to_return;
COMMIT TRANSACTION;

SELECT a AS proc_return_data FROM #dataset_to_return;
RETURN 0;
GO

-- Examples
EXEC dbo.PREVIEW_EXAMPLE @preview = 'Y';
SELECT a AS user_table_after_preview_mode FROM user_table;

EXEC dbo.PREVIEW_EXAMPLE @preview = 'N';
SELECT a AS user_table_after_live_mode FROM user_table;

-- Cleanup
DROP TABLE dbo.user_table;
DROP PROCEDURE dbo.PREVIEW_EXAMPLE;
GO

আমি এই কোড এবং ডিজাইনের ধরণ সম্পর্কে প্রতিক্রিয়া খুঁজছি, এবং / অথবা একই সমস্যার অন্যান্য সমাধান বিভিন্ন ফর্ম্যাটে উপস্থিত থাকলে।

Answer 1

এই পদ্ধতির বিভিন্ন ত্রুটি রয়েছে:

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

   পূর্বরূপ উত্পন্ন হওয়ার পরে অপারেশনটি চালিয়ে যাওয়ার সময়সীমা আপনার কী আছে? অথবা সম্ভবত এটি নির্ধারণ করার উপায় যে প্রাথমিক SELECTসময়ে সংশোধন করার সময় ডেটা একই অবস্থায় রয়েছে ?

2. এটি একটি সামান্য বিষয় কারণ উদাহরণ কোডটি তাড়াতাড়ি করা যেতে পারে এবং সত্য ব্যবহারের ক্ষেত্রে প্রতিনিধিত্ব করতে পারে না তবে কেন কোনও INSERTক্রিয়াকলাপের জন্য "প্রাকদর্শন" থাকবে? INSERT...SELECTএরকম কোনও কিছুর মাধ্যমে একাধিক সারি সন্নিবেশ করার সময় এটি বোধগম্য হতে পারে এবং সারিগুলির একটি পরিবর্তনশীল সংখ্যক সন্নিবেশ করা যেতে পারে, তবে এটি একটি সিঙ্গলটন ক্রিয়াকলাপের জন্য খুব বেশি অর্থবোধ করে না।

3. এটি অনাকাঙ্ক্ষিত কারণ ... অপেক্ষাকৃত কম আত্মবিশ্বাসের যে প্রাকদর্শন ডেটা আসলে কোনও আপডেটের সাথে কী ঘটবে তার একটি সঠিক প্রতিচ্ছবি।

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

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

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

   আমাদের কি সি # কোড এবং সেই সাথে সঞ্চিত পদ্ধতিতে লেনদেন পরিচালনা করতে হবে?

5. যদি উপরে উল্লিখিত বিষয়গুলির জন্য গণনা করা হয়, তবে এখনও একটি জটিল ত্রুটি রয়েছে: স্বল্প সময়ের জন্য অপারেশনটি পরিচালিত হচ্ছে (অর্থাত্ পূর্বের আগে ROLLBACK), কোনও নোংরা-পঠিত প্রশ্ন (ব্যবহার করা WITH (NOLOCK)বা ব্যবহার করা প্রশ্নগুলি SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED) তথ্য দখল করতে পারে এক মুহুর্ত পরে নেই নোংরা-পাঠ্য ক্যোয়ারী ব্যবহার করা যে কোনও ব্যক্তিকে ইতিমধ্যে এই বিষয়ে সচেতন হওয়া উচিত এবং সেই সম্ভাবনাটি স্বীকার করে নেওয়া উচিত, এটির মতো ক্রিয়াকলাপগুলি ডেবাগ অসঙ্গতিগুলি প্রবর্তনের সম্ভাবনাকে ব্যাপকভাবে বৃদ্ধি করে যা ডিবাগ করা খুব কঠিন (যার অর্থ: আপনি কতটা সময় ব্যয় করতে চেয়ে ব্যয় করতে চান কোনও সমস্যা আবিষ্কার করুন যার প্রত্যক্ষ প্রত্যক্ষ কারণ নেই?)।

6. এর মতো একটি প্যাটার্ন আরও লক আটকানো এবং আরও লেনদেন লগ ক্রিয়াকলাপ তৈরি করে উভয়ই বৃদ্ধি ব্লক করে সিস্টেমের কার্যকারিতা হ্রাস করে। (আমি এখন দেখতে পাচ্ছি যে @ মার্টিনস্মিথ প্রশ্নটির একটি মন্তব্যে এই 2 টি বিষয়ও উল্লেখ করেছেন।)

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

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

8. একটি কম গুরুতর সমস্যা যা কেবলমাত্র INSERTঅপারেশনগুলির কম সম্ভাবনার দৃশ্যের সাথে সম্পর্কিত হওয়া উচিত : "পূর্বরূপ" ডেটা DEFAULTসীমাবদ্ধতা ( Sequences/ NEWID()/ NEWSEQUENTIALID()) দ্বারা নির্ধারিত কলাম মানগুলির সাথে সন্নিবেশ করানো মত নয় IDENTITY।

9. অস্থায়ী সারণীতে টেবিল ভেরিয়েবলের বিষয়বস্তু লেখার অতিরিক্ত ওভারহেডের প্রয়োজন নেই। ROLLBACKছক চলক ডাটা প্রভাবিত করবে না (যা তুমি কেন বলেন আপনি প্রথম স্থানে ছক ভেরিয়েবল ব্যবহার করা হয়েছে), তাই এটি কেবল আরো জানার জন্য হবে SELECT FROM @output_to_return;শেষে, এবং তারপর এমনকি অস্থায়ী তৈরি বিরক্ত করবেন না ছক।

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

যা নেমে আসে তা হ'ল:

• একটি "পূর্বরূপ" করা ব্যবহারকারীর মুখোমুখি ক্রিয়াকলাপগুলির পক্ষে খুব একটা বোঝায় না। রক্ষণাবেক্ষণ অপারেশনের জন্য আমি এটি প্রায়শই করি যাতে আমি অপারেশনটি চালিয়ে যেতে পারি তবে কী মুছে ফেলা / আবর্জনা সংগ্রহ করা হবে তা আমি দেখতে পারি। আমি কল করা একটি alচ্ছিক পরামিতি যুক্ত করি @TestModeএবং একটি IFবিবৃতি করি যা হয় হয় SELECTযখন @TestMode = 1অন্যটি এটি করে DELETE। আমি কখনও কখনও @TestModeঅ্যাপ্লিকেশন দ্বারা আহৃত স্টোরড পদ্ধতিগুলিতে প্যারামিটারটি যুক্ত করি যাতে আমি (এবং অন্যরা) ডেটার স্থিতিকে প্রভাবিত না করে সহজ পরীক্ষা করতে পারি, তবে এই প্যারামিটারটি অ্যাপ্লিকেশন দ্বারা কখনও ব্যবহৃত হয় না।

• কেবলমাত্র "ইস্যুগুলির" শীর্ষ বিভাগ থেকে এটি পরিষ্কার ছিল না:

  যদি আপনার প্রয়োজন / ডিএমএল বিবৃতিটি কার্যকর করা হয় তবে কী কী প্রভাব ফেলতে হবে তা দেখার জন্য "পূর্বরূপ" / "পরীক্ষা" মোড চান তবে এটি সম্পাদন করার জন্য লেনদেন (যেমন BEGIN TRAN...ROLLBACKপ্যাটার্ন) ব্যবহার করবেন না । এটি এমন একটি নিদর্শন যা সর্বোত্তমভাবে কেবলমাত্র একটি একক ব্যবহারকারী সিস্টেমে কাজ করে এবং সেই পরিস্থিতিতে একটি ভাল ধারণাও নয়।

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

  যদি ক্যোয়ারী যথেষ্ট দীর্ঘ / জটিল হয় তবে আপনি এটিকে একটি ইনলাইন টেবিল-মূল্যবান ফাংশনে আবদ্ধ করতে পারেন। তারপরে আপনি SELECT * FROM dbo.MyTVF(params);"প্রাকদর্শন" মোডের জন্য একটি সাধারণ করতে পারেন এবং "এটি করুন" মোডের মূল মান (গুলি) -এ যোগ দিতে পারেন। উদাহরণ স্বরূপ:

  UPDATE tab
  SET    tab.Col2 = tvf.ColB
         ...
  FROM   dbo.Table tab
  INNER JOIN dbo.MyTVF(params) tvf
          ON tvf.ColA = tab.Col1;

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

  যদি অপারেশনটি সম্ভবত একটি নির্দিষ্ট% বা ব্যবসায়িক বিধি দ্বারা বিডের পরিমাণ পরিবর্তন করতে হয় তবে তা উপস্থাপনা স্তর (জাভাস্ক্রিপ্ট?) এ পরিচালনা করা যায়।

• যদি আপনাকে শেষ-ব্যবহারকারী-মুখোমুখি ক্রিয়াকলাপের জন্য "প্রিভিউ" করতে হয়, তবে আপনাকে প্রথমে তথ্য স্থিতি গ্রহণ করতে হবে (ফলাফলের জন্য ক্ষেত্রের সমস্ত ক্ষেত্রের একটি হ্যাশ UPDATEঅপারেশন বা মূল মানগুলির জন্য সেট করা হবে) DELETEঅপারেশন) এবং তারপরে, অপারেশনটি সম্পাদন করার আগে, টেবিলের উপর একটি লক করে এমন কোনও লেনদেনের মধ্যে - বর্তমান তথ্যের সাথে ক্যাপচার হওয়া রাষ্ট্রের তথ্যটি তুলনা করুন HOLDযাতে এই তুলনা করার পরে কোনও পরিবর্তন হয় না - এবং যদি কোনও পার্থক্য থাকে তবে একটি নিক্ষেপ করুন ত্রুটি এবং একটি ROLLBACKবদলে সাথে এগিয়ে UPDATEবা DELETE।

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

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

• আপনি end-user ফেসিং "প্রিভিউ" মোড করছেন, তাহলে ছাড়াও নির্বাচন হওয়ার পরেই রেকর্ডের রাষ্ট্র ক্যাপচার বরাবর ক্ষণস্থায়ী, এবং পরিমার্জন-সময়ে পরীক্ষণ, একটি অন্তর্ভুক্ত DATETIMEজন্য SelectTimeএবং মাধ্যমে জনপূর্ণ GETDATE()বা অনুরূপ কিছু। এটি অ্যাপ্লিকেশন স্তরের সাথে পাস করুন যাতে এটি সঞ্চিত পদ্ধতিতে ফিরে যেতে পারে (বেশিরভাগ ক্ষেত্রে সম্ভবত একক ইনপুট প্যারামিটার হিসাবে থাকে) যাতে এটি সঞ্চিত পদ্ধতিতে পরীক্ষা করা যায়। তারপরে আপনি নির্ধারণ করতে পারেন যে যদি অপারেশনটি "পূর্বরূপ" মোড না @SelectTimeহয় তবে তার মানটির বর্তমান মানটির আগে X মিনিটের বেশি হওয়া উচিত নয়GETDATE() । হতে পারে 2 মিনিট? 5 মিনিট? সম্ভবত 10 মিনিটের বেশি নয়। যদি DATEDIFFMINUTES এ থ্রেশোল্ডের উপরে থাকে তবে একটি ত্রুটি নিক্ষেপ করুন ।

Answer 2

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

CREATE TABLE dbo.user_table ( rowId INT IDENTITY PRIMARY KEY, a INT NOT NULL, someGuid UNIQUEIDENTIFIER DEFAULT NEWID() );
GO
CREATE PROCEDURE [dbo].[PREVIEW_EXAMPLE2]

    @preview CHAR(1) = 'Y'

AS

    SET NOCOUNT ON

    --!!TODO add error handling

    IF @preview = 'Y'

        -- Simulate INSERT; could be more complex
        SELECT 
            ISNULL( ( SELECT MAX(rowId) FROM dbo.user_table ), 0 ) + 1 AS rowId,
            42 AS a,
            NEWID() AS someGuid

    ELSE

        -- Actually do the INSERT, return inserted values
        INSERT INTO dbo.user_table ( a )
        OUTPUT inserted.rowId, inserted.a, inserted.someGuid
        VALUES ( 42 )

    RETURN

GO

এটি স্ব-ডকুমেন্টিং (যেমন IF ... ELSEঅনুসরণ করা সহজ), কম জটিলতা (টেবিল ভেরিয়েবল অ্যাপ্রোচ আইএমওর সাথে সেভ পয়েন্টের তুলনায়) হওয়ার সুবিধা রয়েছে, সুতরাং বাগগুলি হওয়ার সম্ভাবনা কম (@ কোডির দুর্দান্ত জায়গা) রয়েছে।

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

অন্যদিকে, আপনার NULL/ NOT NULLসম্পত্তি এবং আপনার সারণী এবং সারণী ভেরিয়েবলগুলি সেট করা উচিত , একটি প্রাথমিক কী নির্ধারণের কথা বিবেচনা করুন।

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

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

Answer 3

আমার উদ্বেগগুলি নিম্নরূপ।

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

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

• কিছু সঞ্চিত পদ্ধতি প্রতিবার একই ফর্ম্যাট ডেটা ফেরত দেয় না; sp_WhoIsAtive কে একটি সাধারণ উদাহরণ হিসাবে ভাবেন।

আমি এটি করার জন্য আরও ভাল উপায় সরবরাহ করি নি তবে আমি মনে করি না আপনার কাছে যা আছে তা একটি ভাল প্যাটার্ন is