আপনি যখন বুলিয়ান মান নির্ধারণ করতে না পারেন তখন কী করবেন?


38

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

উদাহরণ: আসুন আমরা বলি যে আপনার কাছে একটি সত্তা গাড়ি রয়েছে যার একটি হ্যাশ রেডিও প্যারামিটার রয়েছে। এখন আপনাকে এই ডেটা মডেলটিতে ডেটা আমদানি করতে হবে, তবে ডেটাগুলিতে কেবলমাত্র "মডেল" এবং "রঙ" কলাম রয়েছে, রেডিও থাকা বা না থাকা সম্পর্কে কিছুই নেই। আপনি একটি "hasRadio" কলামে কি রাখবেন, যদি এটি ডিজাইনের দ্বারা বাতিল করা যায় না?

এই পরিস্থিতিতে সেরা পদ্ধতির কী? আমরা কি কেবল কোম্পানিকে ম্যানুয়ালি অনুপস্থিত ডেটা পূরণ করতে বলি? নাকি এটি মিথ্যা হিসাবে ডিফল্ট?


70
আমার জন্য NULL অনুমতি দেওয়া সঠিক সমাধান হবে। "ভবিষ্যতে আমাদের সিস্টেমে কোনও সমস্যা সৃষ্টি করার" চেয়ে আপনার সিনিয়র কি আরও নির্দিষ্ট ছিলেন? যদি তা না হয় তবে আরও নির্দিষ্ট কারণে তাকে জিজ্ঞাসা করুন।
লার্সবে

48
আপনার এটি FileNotFoundঅবশ্যই ডিফল্ট করা উচিত ।
আপনি

7
"বুলিয়ান ফিল্ড", "ইসভালিডহাসরাডিও" বা অন্য কিছু যুক্ত করা কি সম্ভব হবে না , বা এটি কি জিনিসগুলি ভেঙে দেবে?
হাইড

9
সঠিক সমাধান হ'ল ইনপুট ডেটা আবর্জনা বিবেচনা করা এবং পুরো লেনদেন বাতিল করা এবং তারপরে যদি সেই ডেটা আবর্জনা বিবেচনা না করা হয় তবে কার্য সংজ্ঞাটি সামঞ্জস্য করার দাবি করুন । এখানে আর কোন উপায় নেই।
সার্জে বর্শ্চ

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

উত্তর:


129

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

এটি সাধারণত নিম্নলিখিতগুলির মধ্যে একটির দিকে পরিচালিত করে:

  • নির্দিষ্ট কলামের জন্য একটি ভাল ডিফল্ট মান রয়েছে, ব্যবহারকারীরা প্রাথমিকভাবে সমস্ত রেকর্ডের জন্য একই রকম হয় যদি তা মনে করেন না, প্রয়োজনের পরে তারা সহজেই সঠিক মানগুলি সেট করতে পারেন

  • অন্যান্য তথ্য থেকে কীভাবে আদর্শ ডিফল্ট মান নির্ধারণ করা যায় সে সম্পর্কে একটি নিয়ম রয়েছে, যাতে আপনি এই নিয়মটিকে কোডের মধ্যে রাখতে পারেন

  • ব্যবহারকারী বা আপনার গ্রাহক ইনপুট ডেটা প্রসারিত করবেন এবং এটি ডাটাবেসে আমদানি হওয়ার আগে অনুপস্থিত মানগুলি (সম্ভবত ম্যানুয়ালি) সরবরাহ করবে

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

আপনার ক্ষেত্রে প্রবীণরা এটি পছন্দ করেন বা না চান তা যদি না হয় তবে বুলিয়ান মানের জন্যও শেষ কেসটি অবিচ্ছিন্ন বা অজানা অবস্থার প্রতিনিধিত্ব করতে NULL এর মতো কিছু দরকার। যদি কোনও অস্পষ্ট প্রযুক্তিগত কারণ থাকে যা একটি নির্দিষ্ট কলামের জন্য NULL মান ব্যবহার করতে নিষেধ করে, আপনার অতিরিক্ত বুলিয়ান কলামটি (যেমন hasRadioIsUnknown) প্রবর্তন করে বা একটি 3 ব্যবহার করে "অজানা" রাষ্ট্রকে ভিন্ন উপায়ে অনুকরণ করতে হবে একটি বুলিয়ান পরিবর্তে -valued শুমার (যেমন HasNoRadio=0, HasRadio=1, Unknown=2)। তবে আপনার সিনিয়রদের সাথে আবার কথা বলুন, আপনি একটি প্রয়োজনীয় প্রয়োজনীয় বিশ্লেষণ করার পরে, এই জাতীয় কাজটি সত্যিই প্রয়োজনীয় কিনা তা নিশ্চিত করতে।


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

1
এটি একটি কার্যকরী সমস্যা। মডেলগুলির (এক্সেলস এবং নতুনটির সাথে) মেলে না বলে এই মামলাগুলি বিবেচনায় নিয়ে মাইগ্রেশন প্রক্রিয়াটি পর্যালোচনা করা উচিত। কেবলমাত্র কীভাবে এগিয়ে যেতে হবে তা হ'ল স্টেকহোল্ডাররা (গ্রাহক বা যে কেউ)। প্রযুক্তিগতভাবে আপনি এটি বিভিন্ন উপায়ে সমাধান করতে পারেন তবে কার্যত কেবলমাত্র একটিতে। অধিকার.
লাইভ

12
আমি এই ভাঙ্গন পছন্দ করি। আমার এই প্রসঙ্গে শূন্যতার জন্য বিরক্তি আমার বেশিরভাগ ক্ষেত্রে এর স্পষ্ট অর্থের অভাবে হয়। অজানা পরিষ্কার। তবে নাল মানে কি অজানা বা প্রযোজ্য নয়? কেউ জানবে কীভাবে? এটি আপনার কাছে বোঝাপড়া করার অর্থ এই নয় যে অন্যরা সবাই এটি একইভাবে দেখবে।
candied_orange

বিকল্প 4: একটি নির্দিষ্ট কলামের মান অনুপস্থিত রেকর্ডগুলি আসলে অকেজো এবং এটিকে আমদানি থেকে বাদ দেওয়া উচিত। বিকল্প 5: কারও কাছে আগত সমস্ত ডেটা আমদানি হওয়ার আগে সংশোধন করা দরকার। প্রচুর বিকল্প, কেবল প্রয়োজন এবং বাজেটের উপর নির্ভর করে। পুরানো ডেটা আমদানি সর্বদা একটি বিশাল জগাখিচুড়ি।
jpmc26

@ জেএমপিসি 26: ভাল, আমি বিকল্প 4 অন্তর্ভুক্ত করিনি যেহেতু আমি ওপি আক্ষরিকভাবে যা লিখেছি তা আটকে রাখতে চেয়েছিলাম (কোনও ক্ষেত্রে নিখোঁজ হওয়া ডেটা অবশ্যই আমদানির ডেটার অন্তর্ভুক্ত নয়, কোনও রেকর্ড ছাড়াই)। বিকল্প 5 টি প্রকৃতপক্ষে উল্লেখ করার মতো, যেহেতু এটি NULL মানগুলির প্রয়োজনীয়তা এড়ানোর আরেকটি উপায়। সেই অনুসারে আমার উত্তর সম্পাদনা করেছেন।
ডক ব্রাউন

39

এটি কোনও প্রযুক্তিগত প্রশ্ন নয়; এটি একটি ব্যবসায়ের নিয়ম প্রশ্ন। সুতরাং, আপনাকে "ব্যবসায়" জিজ্ঞাসা করতে হবে।

পণ্যের মালিক এবং / অথবা স্টেকহোল্ডার (গুলি) এর কাছে যোগাযোগ করুন এবং এর মতো কিছু বলুন:

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

কিছু আলোচনা সম্ভবত আগত হবে। তবে, এটি মূলত এটি। প্রযুক্তিগত সমাধানটি আরও বিচ্ছুরিত বিধি বিধান থেকে স্বাভাবিকভাবে প্রবাহিত হবে।


9

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

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

কিছুটা পার্থক্য সম্ভবত ডেটা মডেলের মিল নয় to এটির সাথে লেনদেন করা মূলত উভয় ডেটা মডেলের সাথেই (ঘনিষ্ঠভাবে) পরিচিত হওয়া এবং কীভাবে পুরানোটিকে নতুনটিতে মানচিত্র করা যায় তা জেনে রাখা বিষয় is যতক্ষণ না নতুন এটি পুরানোটিকে ক্যাপচার করতে সক্ষম। (যদি তা না হয় তবে আপনার দলে সম্ভবত খুব বড় সমস্যা রয়েছে)) এটি সহজেই কলাম অনুলিপি করার চেয়ে আরও বেশি কাজ করার প্রয়োজন হতে পারে। ডার্কউইং এর একটি দুর্দান্ত উদাহরণ দেয় (পাশাপাশি কেন অন্ধভাবে NUL গুলি serোকানো ভুল জিনিস)) এটি উপর elaborating, যদি পুরাতন মডেল একটি ছিল ReceivedDateএবং InProgressবিট এবং নতুন মডেল একটি হয়েছে StartDateএবং ProcessingEndTime, আপনি যদি এবং সেট কিভাবে সিদ্ধান্ত নিতে হবে ProcessingEndTime। এটি কীভাবে ব্যবহৃত হবে তার উপর নির্ভর করে একটি যুক্তিসঙ্গত (তবে স্বেচ্ছাচারী) পছন্দ হতে পারে এটির মতো হতে পারে setStartDate (বা খুব শীঘ্রই যদি এটি সমস্যার কারণ হয়ে থাকে)।

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

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

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


14
সংক্ষেপে: আপনি যদি লিগ্যাসি কোড নিয়ে কাজ করা খারাপ মনে করেন, তবে লিগ্যাসির ডেটা নিয়ে কাজ করার চেষ্টা করুন।
পিটার টেলর

0

ডেটামোডেল পরিবর্তন করুন।

আপনি hasradio স্বাভাবিক করতে পারেন এবং তারপরে আপনার আর কোনও নাল হবে না।

আপনি যদি বুলিয়ান মান নির্ধারণ করতে না পারেন তবে বুলেটিয়ান ব্যবহার করবেন না।

কোনও বুলিয়ান মান নালায় পরিণত হওয়ার অনুমতি দিয়ে এটি বুলিয়ান হওয়া বন্ধ করে দেয়। একটি বুলিয়ান 2 টি রাষ্ট্র থাকতে পারে: মিথ্যা, সত্য।

আপনার যা প্রয়োজন তা 3 টি রাজ্য: ভুয়া, সত্য, অজানা।

আপনার কাছে ডেটামোডেলটি পরিবর্তন করার বিকল্প নেই?

(এবং আমি অন্য একটি জিনিস ভেবেছিলাম, যদি অজগর বা জাভাতে আপনি আপনার ডাটাবেস থেকে ডেটা উদ্ধার করেন You


2
তথ্য মডেল এবং "আউট hasRadio স্বাভাবিক" পরিবর্তন করে, আমি যদি আপনি একটি নতুন টেবিল যুক্ত করার মত গড় কিছু অনুমান CarFeaturesক্ষেত্রের সাথে, Car_ID, Feature_ID, Has_Feature? একটি ভাল ধারণা মত মনে হচ্ছে।
জেপিএ

2
@ জেপা এটি কিছুটা জটিল পরিস্থিতি। আপনি যা করেন তার ক্ষেত্রে আপনাকে খুব পরিষ্কার হতে হবে, কারণ আমাদের পরিস্থিতিতে রেকর্ডের অনুপস্থিতির অর্থ অজানা। যদিও প্রায়শই রেকর্ডের অনুপস্থিতির অর্থ এটিতে বৈশিষ্ট্যটি নেই।
পিটার বি

1
আপনি এটি ভুল দেখছেন, পিটার। কেউ বলে না যে এর দুটিরও boolবেশি মান রয়েছে কারণ আপনি যেমন বলেছিলেন, তা হয় না not ক boolহয় হয় trueবা হয় false। যাইহোক, ওপিএস ক্ষেত্রে, ওপি boolসরাসরি কোনও আচরণ করে না , বরং একটি Option<bool>/Maybe<bool>, যা থাকতে পারে Some -> true/falseবা করতে পারে None
অ্যান্ডি

@ ডেভিডপ্যাকার আমার যুক্তিটি হ'ল এটি সম্ভবত কারণ হতে পারে <বিউল> আপনার এটিকে দূরবর্তীভাবে অনুরূপ কিছু বলা বন্ধ করা উচিত অথবা আপনি বিভ্রান্তি পেয়ে যাবেন। এবং আপনি যদি বুলিয়ান ব্যবহার করার জন্য জেদ করেন তবে এটির জন্য একটি নিরাপদ উপায় সন্ধান করুন।
পিটার বি

4
আমার মতে, nullable বুলেট পুরোপুরি ঠিক আছে। নাল মানগুলির সাথে আমার কখনও সমস্যা হয়নি, যদিও আমি এমন বিকাশকারীদের সাথে দেখা করেছি যারা করেছে did
অ্যান্ডি

-1

অন্যরা যেমন উল্লেখ করেছে, আপনার কাছে যা আছে তা হল একটি বুলিয়ান মান যা সত্যই বুলেটিয়ান নয় এবং সমস্যাটি হয় এটি বুলিয়ান হতে বাধ্য করা বা অন্যথায় এটি পরিচালনা করা handle

আপনি যা করতে পারেন তা হ'ল একক বুলিয়ান ফলাফলের পরিবর্তে দুটি বুলিয়ান ফলাফল পেতে। এগুলি হয় হয় একমত বা একমত হতে পারে না। যদি তারা সম্মত হয় তবে আপনার একটি সোজাসুজি সত্য / মিথ্যা ফলাফল রয়েছে।

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

এটি এখনও ফলাফলটিকে অনির্দিষ্টকালের হিসাবে জানাতে অনুমতি দেবে, সুতরাং মানটির এই অতিরিক্ত সংকোচনটি সম্পূর্ণরূপে হারাবে না, যতক্ষণ না মানটি সুনির্দিষ্টভাবে সমাধান করা এবং পুনরায় সেট করা যায়।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.