এসকিউএল সার্ভার ২০১২-তে এখনও একটি বড় সংখ্যা নেই নির্বাচন করুন?

Question

প্রত্যাবর্তনের দিনগুলিতে, এটি করা select * from tableবা select count(*) from tableনা করা পারফরম্যান্সের হিটের কারণ হিসাবে বিবেচিত হয়েছিল big

এটি কি এসকিউএল সার্ভারের পরবর্তী সংস্করণগুলিতে এখনও রয়েছে (আমি 2012 ব্যবহার করছি, তবে আমি অনুমান করি যে প্রশ্নটি 2008 - 2014 এ প্রযোজ্য হবে)?

সম্পাদনা: যেহেতু লোকেরা আমাকে এখানে কিছুটা চড় মারছে বলে মনে হচ্ছে, আমি এটি একটি মানদণ্ড / একাডেমিক দৃষ্টিকোণ থেকে দেখছি, এটি "সঠিক" জিনিসটি করা উচিত কিনা তা নয় (অবশ্যই এটি নয়)

Answer 1

আপনি যদি SELECT COUNT(*) FROM TABLEকেবলমাত্র একটি সারি (গণনা) ফেরান, তুলনামূলকভাবে হালকা এবং সেই ডাটামটি পাওয়ার উপায়।

এবং SELECT *এটি কোনও শারীরিক সংখ্যা-নয়, এটি আইনী এবং অনুমোদিত।

তবে সমস্যাটি SELECT *হ'ল আপনি অনেক বেশি ডেটা মুভমেন্টের কারণ হতে পারেন। আপনি টেবিলের প্রতিটি কলামে পরিচালনা করেন। যদি আপনার SELECTকেবল কয়েকটি কলাম অন্তর্ভুক্ত থাকে তবে আপনি কোনও উত্তর বা সূচী থেকে আপনার উত্তর পেতে সক্ষম হবেন যা I / O হ্রাস করে এবং সার্ভারের ক্যাশেতেও প্রভাব ফেলে।

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

SELECT *সমস্ত কলামের নাম টাইপ না করা এর একমাত্র আসল সুবিধা । তবে এসএসএমএস থেকে আপনি আপনার ক্যোয়ারিতে কলামের নাম পেতে ড্র্যাগ এবং ড্রপ ব্যবহার করতে পারেন এবং আপনার প্রয়োজন নেই এমনগুলি মুছতে পারেন।

একটি উপমা: কেউ ব্যবহার করে SELECT *যখন তারা প্রতিটি কলামের প্রয়োজন হবে না, তারা হবে এছাড়াও ব্যবহার SELECTএকটি ছাড়া WHERE(অথবা অন্য কোনো সীমিত দফা) যখন তারা প্রত্যেক সারি প্রয়োজন নেই?

Answer 2

ইতিমধ্যে সরবরাহকারীর উত্তরের পাশাপাশি, আমি মনে করি যে আধুনিক ওআরএম যেমন এন্টি ফ্রেমওয়ার্কের সাথে কাজ করার সময় বিকাশকারীরা প্রায়শই খুব অলস হন। ডিবিএ'র এড়াতে তাদের যথাসাধ্য চেষ্টা করার পরেও SELECT *বিকাশকারীরা প্রায়শই শব্দার্থগত সমতুল্য উদাহরণ লিখেন, সি # লিন্কে:

var someVariable = db.MyTable.Where(entity => entity.FirstName == "User").ToList();

সংক্ষেপে, এর ফলাফল নিম্নলিখিত হবে:

SELECT * FROM MyTable WHERE FirstName = 'User'

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

হ্যাঁ, কমপক্ষে আমার জন্য, এটি হ'ল এবং সর্বদা একটি বড় নম্বর হবে। এগুলি করার আরও "লুকানো" ব্যয় সম্পর্কেও আমাদের শিক্ষিত হওয়া দরকার।

অভিযোজ্য বস্তু

মন্তব্যগুলিতে অনুরোধ অনুসারে আপনার প্রয়োজন কেবলমাত্র ডেটা টানার একটি নমুনা এখানে:

var someVariable = db.MyTable.Where(entity => entity.FirstName == "User")
                             .Select(entity => new { entity.FirstName, entity.LastNight });

Answer 3

পারফরম্যান্স: নির্বাচন * এর সাথে একটি কোয়েরি সম্ভবত কখনই একটি কভারিং কোয়েরি হবে না ( সরল আলাপের ব্যাখ্যা , স্ট্যাক ওভারফ্লো ব্যাখ্যা )।

ফিউচার-প্রুফিং: আপনার ক্যোয়ারী আজ সমস্ত সাতটি কলাম ফিরে আসতে পারে তবে যদি কেউ পরের বছরে পাঁচটি কলাম যুক্ত করে তবে এক বছরে আপনার প্রশ্নটি বারো কলাম ফিরে আসবে, আইও এবং সিপিইউ নষ্ট করে দিবে।

সূচীকরণ: আপনি যদি নিজের মতামত এবং টেবিল-মূল্যবান ফাংশনগুলি এসকিউএল সার্ভারে সূচীকরণে অংশ নিতে চান তবে সেই মতামতগুলি এবং ফাংশনগুলি অবশ্যই স্কিমেবাইন্ডিং দ্বারা তৈরি করা উচিত, যা SELECT * ব্যবহার নিষিদ্ধ করে।

সেরা অনুশীলন : SELECT *উত্পাদন কোড ব্যবহার করবেন না।

সাবকিউয়ের জন্য, আমি পছন্দ করি WHERE EXISTS ( SELECT 1 FROM … )।

সম্পাদনা করুন : নীচে ক্রেগ ইয়ংয়ের মন্তব্যে সম্বোধন করার জন্য, একটি সাবকোয়ারিতে "নির্বাচন 1" ব্যবহার করা "" অনুকূলিতকরণ "নয় - তাই আমি আমার ক্লাসের সামনে দাঁড়াতে এবং বলতে পারি" নির্বাচন করুন * ব্যবহার করবেন না, কোনও ব্যতিক্রম নেই! "

একমাত্র ব্যতিক্রম সম্পর্কে আমি ভাবতে পারি যেখানে ক্লায়েন্ট পিভট-টেবিল ক্রিয়াকলাপটি করছেন এবং বর্তমান এবং ভবিষ্যতের সমস্ত কলাম প্রয়োজন।

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

নোট করুন যে আমি COUNT(*)এটির ব্যতিক্রম বিবেচনা করি কারণ এটি "*" এর আলাদা সিনট্যাকটিক্যাল ব্যবহার।

Answer 4

এসকিউএল সার্ভার ২০১২-এ (বা 2005 সালের কোনও সংস্করণ) ব্যবহার SELECT *...করা কোনও প্রশ্নের কোনও শীর্ষ স্তরের SELECT বিবৃতিতে কেবল সম্ভাব্য পারফরম্যান্স সমস্যা।

সুতরাং এটি দেখেছে (*), subqueries এ, অস্তিত্ব clause এ CTEs মধ্যে একটা সমস্যা হয় না, কিংবা এ SELECT COUNT(*)..ইত্যাদি, ইত্যাদি নোট করুন এটি সম্ভবত সত্য ওরাকল জন্য, এবং DB2, এবং হয়ত PostGres (নিশ্চিত না) , তবে এটি খুব সম্ভবত মাইএসকিএল-র ক্ষেত্রে প্রচুর ক্ষেত্রে সমস্যা a

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

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

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

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

এর ফলশ্রুতিটি হ'ল আপনি যদি কোনও প্রশ্নের নীচের / অভ্যন্তরীণ স্তরে 'নির্বাচন করুন ..' ব্যবহার করেন তবে তা আর গুরুত্বপূর্ণ নয়। পরিবর্তে, যা সত্যিই গুরুত্বপূর্ণ তা হ'ল শীর্ষ স্তরের নির্বাচন করুন কলাম তালিকার মধ্যে। আপনি যদি SELECT *..শীর্ষে না ব্যবহার করেন, তবে এটি আবার একবারে অবশ্যই ধরে নিতে হবে যে আপনি সমস্ত কলামগুলি চান এবং তাই কলামের অনুকূলিতকরণ কার্যকরভাবে নিয়োগ করতে পারে না।

(* - দ্রষ্টব্য যে ভিউগুলিতে একটি পৃথক, গৌণ বাধ্যতামূলক সমস্যা রয়েছে *যেখানে তারা "*" ব্যবহার করার সময় কলাম তালিকায় পরিবর্তনটি সর্বদা নিবন্ধভুক্ত করেন না this এটি সমাধান করার অন্যান্য উপায় রয়েছে এবং এটি কার্য সম্পাদনকে প্রভাবিত করে না))

Answer 5

ব্যবহার না করার আরও একটি ছোট কারণ রয়েছে SELECT *: যদি কলামগুলির ক্রম পরিবর্তন হয় তবে আপনার আবেদনটি ভেঙে যাবে ... আপনি ভাগ্যবান হলে if আপনি যদি না হন তবে আপনার একটি সূক্ষ্ম ত্রুটি থাকবে যা দীর্ঘদিন ধরে সনাক্ত করা যায়। টেবিলের ক্ষেত্রগুলির ক্রম হল একটি বাস্তবায়ন বিশদ যা অ্যাপ্লিকেশনগুলির দ্বারা কখনই বিবেচনা করা উচিত নয়, কেবলমাত্র এটির ক্ষেত্রে দৃশ্যমান হলেও এটি যদি আপনি ব্যবহার করেন SELECT *।

Comments

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

— মিথ্যা রায়ান

Answer 6

এটি শারীরিক এবং সমস্যাযুক্তভাবে ব্যবহারের অনুমতি দেওয়া হয়েছে select * from tableতবে এটি একটি খারাপ ধারণা। কেন?

প্রথমত, আপনি দেখতে পাবেন যে আপনি যে কলামগুলি আপনার প্রয়োজন নেই সেগুলি ফিরে আসছেন (সংস্থান ভারী) heavy

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

তৃতীয়ত, এটি করা বিকাশকারীদের পক্ষে এটি আরও শক্ত করে তোলে। কলামের সমস্ত নাম পেতে আপনার কত ঘন ঘন এসএসএমএস থেকে ভিএস-তে ফিরতে হবে?

চতুর্থত, এটি অলস প্রোগ্রামিংয়ের লক্ষণ এবং আমি মনে করি না যে কোনও বিকাশকারী সেই খ্যাতি চান।

Comments

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

— গ্যাবর গারামি

আপনার দ্বিতীয় যুক্তি সম্পর্কিত, এটি একটি সাধারণ ভুল ধারণা - SELECT * এর সাথে সমস্যাটি মেটাডেটা অনুসন্ধান নয়, যেহেতু আপনি কলামগুলির নাম দিচ্ছেন, এসকিউএল সার্ভারকে এখনও তাদের নামগুলি বৈধ করতে হবে, ডেটা ধরণের ইত্যাদি পরীক্ষা করতে হবে

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

@ গ্যাবর নির্বাচন করুন * এর মধ্যে একটি সমস্যা ঘটে যখন আপনি এটিকে একটি দৃষ্টিতে রাখেন। যদি আপনি অন্তর্নিহিত স্কিমাটি পরিবর্তন করেন তবে দৃশ্যটি বিভ্রান্ত হয়ে উঠতে পারে - এটি এখন টেবিলের চেয়ে টেবিলের স্কিমা (নিজস্ব) এর আলাদা ধারণা রয়েছে। আমি এখানে এই সম্পর্কে কথা বলতে ।

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

Answer 7

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

এই কথাটি বলার পরে, আমার যখন সমস্যাটি Select *অংশটির অংশ হয় তখন আমার সমস্যা কম হয় EXISTS, যেহেতু প্রোগ্রামটিতে ফিরে আসা সমস্ত কিছুই নির্বাচনের সাফল্য বা ব্যর্থতার ইঙ্গিত দেয় এমন একটি বুলিয়ান। অন্যরাও এই অবস্থানের সাথে একমত হতে পারে না এবং আমি সে সম্পর্কে তাদের মতামতের প্রতি শ্রদ্ধা করি। Select *কোডের ক্ষেত্রে 'সিলেক্ট 1' কোড করার চেয়ে কোডের তুলনায় এটি সামান্য দক্ষ হতে পারে EXISTSতবে আমি মনে করি না যে কোনওভাবেই ডেটা দুর্নীতির কোনও বিপদ আছে।

Comments

প্রকৃতপক্ষে, হ্যাঁ, আমি বলতে চাইছিলাম বিদ্যমান ক্লজটি রেফারেন্স করব। আমার ভুল.

— মার্ক রস

Answer 8

select *ভুল কেন , এর অনেকগুলি উত্তর , সুতরাং আমি যখন সঠিক বা কমপক্ষে ঠিক মনে করি তখন আমি তা কভার করব।

1) একটি উপস্থিতিতে, ক্যোয়ারির নির্বাচন অংশের বিষয়বস্তু উপেক্ষা করা হয়, তাই আপনি এমনকি লিখতে পারেন SELECT 1/0এবং এটি ত্রুটি ঘটবে না। EXISTSকেবল যাচাই করেছে যে কিছু ডেটা ফিরে আসবে এবং তার ভিত্তিতে একটি বুলিয়ান দেয়।

IF EXISTS(
    SELECT * FROM Table WHERE X=@Y
)

2) এটি আগুনের ঝড় শুরু করতে পারে তবে আমি select *আমার ইতিহাসের টেবিলটিতে ট্রিগারগুলি ব্যবহার করতে পছন্দ করি । এর দ্বারা select *, এটি ইতিহাসের টেবিলে কলামটি যুক্ত না করেই মূল টেবিলটি একটি নতুন কলাম পেতে বাধা দেয় এবং তত্ক্ষণাত ত্রুটিযুক্ত হয়ে প্রধান টেবিলটিতে সন্নিবেশ / আপডেট / মুছে ফেলা হয়। এটি এমন অনেক সময় প্রতিরোধ করেছে যেখানে ডেভেলপাররা কলাম যুক্ত করে এবং ইতিহাস টেবিলে যুক্ত করতে ভুলে গিয়েছিল।

Comments

আমি এখনও পছন্দ করি SELECT 1কারণ এটি স্পষ্টতই আপনার অভিপ্রায় ভবিষ্যতের কোড রক্ষণাবেক্ষণকারীকে জানিয়ে দেয়। এটি কোনও প্রয়োজন নয় , তবে আমি যদি ... WHERE EXISTS (SELECT 1 ...)এটি দেখতে পেলাম তবে স্পষ্টতই নিজেকে সত্যের পরীক্ষা হিসাবে ঘোষণা করে।

— 4:57 এ স্বশেক

@ জ্লাতানমানুষ লোক SELECT 1একটি মিথের উপর ভিত্তি করে ব্যবহার করেন যা পারফরম্যান্সের চেয়ে ভাল হবে SELECT *। যাইহোক, উভয় বিকল্প পুরোপুরি গ্রহণযোগ্য। অপ্টিমার উপস্থিতি যেভাবে পরিচালনা করে তার কারণে পারফরম্যান্সে কোনও ভিন্নতা নেই। বা স্পষ্টতই একটি সত্য পরীক্ষার ঘোষণা দেয় এমন শব্দ "বিদ্যমান" শব্দটির কারণে পাঠযোগ্যতার কোনও পার্থক্য নেই।

— বিভ্রান্ত

পয়েন্ট # 2 এ, আমি আপনার যুক্তি বুঝতে পারি, তবে এখনও ঝুঁকি রয়েছে। আমাকে 'আপনার জন্য একটি চিত্র আঁকুন' ... বিকাশকারী Column8ইতিহাসের টেবিলটি ভুলে মূল টেবিলটিতে যুক্ত করে। বিকাশকারী কলাম 8 রিয়েলটেডের একগুচ্ছ কোড লিখেছেন Then তারপরে তিনি Column9মূল টেবিলটিতে যুক্ত করেন; এইবার ইতিহাসে যুক্ত করার কথা মনে পড়ে। পরে পরীক্ষার সময় তিনি বুঝতে পারেন যে তিনি Column9ইতিহাসে যুক্ত করতে ভুলে গেছেন (আপনার ত্রুটি সনাক্তকরণ কৌশলকে ধন্যবাদ) এবং তাৎক্ষণিকভাবে এটি যুক্ত করে। এখন ট্রিগারটি কাজ করছে বলে মনে হচ্ছে তবে 8 এবং 9 কলামের ডেটা ইতিহাসের সাথে মিশে গেছে। : এস

— বিভ্রান্ত

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

— বিভ্রান্ত

@ ক্রেইগ ইউং এটি একটি সম্ভাবনা। তবে কাউকে যদি তারা তা করে তবে আমি গলা টিপে দেব। এটি এমন কোনও ভুল নয় যা আপনি সহজেই করতে পারেন

— আনহানডেলড এক্সপেশনসিয়ান