কেন আমরা NULLs অনুমতি দেব না?

Question

আমি ডাটাবেস ডিজাইন সম্পর্কে এই একটি নিবন্ধ পড়া মনে করি এবং আমি এটি মনে আছে এটি আপনার নাল নয় ক্ষেত্রের বৈশিষ্ট্য থাকা উচিত। যদিও কেন এই ঘটনাটি ছিল তা আমার মনে নেই।

আমি যা ভাবতে পারি তা হ'ল, একজন অ্যাপ্লিকেশন বিকাশকারী হিসাবে আপনাকে NUL এবং একটি সম্ভাব্য অস্তিত্বহীন ডেটা মান (উদাহরণস্বরূপ, স্ট্রিংগুলির জন্য খালি স্ট্রিং) পরীক্ষা করতে হবে না ।

তবে আপনি তারিখ, তারিখ সময় এবং সময় (এসকিউএল সার্ভার ২০০৮) এর ক্ষেত্রে কী করবেন? আপনাকে কিছু historicতিহাসিক বা তুষারপাতের তারিখ ব্যবহার করতে হবে।

এই সম্পর্কে কোন ধারণা?

Comments

এই উত্তরের NULL dba.stackexchange.com/questions/5176/…

— ডেরেক

সত্যি? আরডিবিএমএস কেন আমাদের মোটামুটি নুল ব্যবহার করার অনুমতি দেয়? যতক্ষণ না আপনি তাদের সাথে কীভাবে व्यवहार করতে হয় জানেন ততক্ষণ নুলের সাথে কোনও ভুল নেই।

— Fr0zenFyr

এটি কি বিআই ডেটা মডেলিং ছিল? আপনার ফ্যাক্ট টেবিলগুলিতে সাধারণত নালগুলিকে অনুমতি দেওয়া উচিত নয় ... অন্যথায়, সঠিকভাবে ব্যবহৃত হলে নালগুলি আপনি বন্ধু friends =)

— সাম ইয়ি

@ ফ্র0জেনফায়ার, কেবলমাত্র কোনও আরডিবিএমএস আমাদের কিছু করার অনুমতি দেয় কারণ এটি করা ভাল কোনও ধারণা নয়। কোনও কিছুই আমাদেরকে কোনও টেবিলে প্রাথমিক কী বা একটি অনন্য কী ঘোষণা করতে বাধ্য করে না, তবে কিছু ব্যতিক্রম ছাড়া আমরা যেভাবেই করি।

— লেনার্ট

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

— ওয়াল্টার মিট্টি

Answer 1

আমি মনে করি যে প্রশ্নটি খারাপভাবে বর্ণিত হয়েছে, কারণ এই শব্দটির দ্বারা বোঝা যাচ্ছে যে আপনি ইতিমধ্যে স্থির করেছেন যে নালগুলি খারাপ। সম্ভবত আপনি বোঝাতে চেয়েছিলেন "আমাদের কি NUL গুলি দেওয়া উচিত?"

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

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

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

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

নুলকে ভয় পাবেন না, তবে কখন এবং কোথায় তাদের ব্যবহার করা উচিত এবং কখন এবং কোথায় তাদের উচিত নয় তা শিখতে বা নির্দেশ দিতে রাজি হন।

Comments

"কিছু অযৌক্তিক টোকেন মানটি যে এটি অজানা তা উপস্থাপনের জন্য" এটি প্রেরণক মান

— আলেকজান্ডার

আপনি birth_dateযেখানে জন্মের তারিখ সংরক্ষণ করেন সেখানে আলাদা টেবিল তৈরি করতে আপনাকে কী বাধা দেয় ? যদি জন্মের তারিখটি অজানা থাকে তবে কেবল জন্ম তারিখটি don'tোকাবেন না birth_date। নাল বিপর্যয় are

— এল্ডার আগালারভ

@ এল্ডারআগালরভ এটি ট্রাম্প যুক্তিযুক্ত বলে মনে হচ্ছে ("বিপর্যয়" কেন? কীভাবে? কার জন্য? আপনার মতামত যে কোনও কিছু "বিপর্যয়" তাই করে না)। যাইহোক জন্মের তারিখ কেবল একটি উদাহরণ। আপনার যদি কর্মী বা সদস্য বা গ্রাহকগণের 15 টি সম্ভাব্য অবনমিত কলাম রয়েছে, আপনি 15 গৌণ টেবিল তৈরি করতে যাচ্ছেন? যদি আপনার 50 হয়? যদি আপনার ডিডাব্লু ফ্যাক্ট টেবিলটিতে 500 থাকে? আপনার ডেটাবেজ থেকে বড় খারাপ ভীতিজনক নাল রাখার রক্ষণাবেক্ষণ আপনার "ভয়ঙ্কর" ভয়ঙ্কর কোনও ভয়ঙ্কর হিসাবে 10x হিসাবে খারাপ হয়ে যায় ...

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

@ অ্যারনবার্ট্র্যান্ড যদি আপনার টেবিলটিতে 15 টি সম্ভাব্য কমানো কলাম থাকে তবে তা সত্যিই খারাপ গন্ধ লাগে ^^ বিপুল সংখ্যক কলাম অন্তর্নিহিতভাবে খারাপ নয়, তবে এটি একটি খারাপ নকশা বা প্রয়োজনীয় সংযোজনকে নির্দেশ করতে পারে। তবে এটি প্রশ্ন উত্থাপন করবে।

— প্রগ্রেমথগুলি

@ উইল্ডকার্ড তাই আপনি 1900-01-01কোনও নাল তারিখ / সময় মূল্য এড়াতে লোকদের দোকান দেখেন নি ? ঠিক আছে তাহলে। এছাড়াও, NULL = অজানা এবং অজানা = মিথ্যা। আমি নিশ্চিত নই যে এই কারণে মানুষ জন্মগ্রহণ না করে অন্য কোন সমস্যার কারণ হতে পারে তা জেনে নেই (যেমন তারা জটিল আরডিবিএমএসের অন্তর্নিহিত অনেক কিছুই জেনে জন্মগ্রহণ করেন না)। আবার, হাত নেড়ে এবং বলে "সমস্যা! বিপর্যয়!" এটা তোলে না।

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

Answer 2

প্রতিষ্ঠিত কারণগুলি হ'ল:

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

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

• কোনও নির্দিষ্ট NULL এর অর্থগত অর্থ প্রয়োগের উপর ছেড়ে দেওয়া হয়েছে , প্রকৃত মানগুলির থেকে পৃথক।

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

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

এর অর্থ এই নয় যে নুলকে কখনই অনুমতি দেওয়া উচিত নয়। এটা তোলে নেই সেখানে যেখানেই থাকুন না কেন সম্ভবপর শূন্য নামঞ্জুর করার জন্য অনেক ভাল কারণ আছে তর্ক করবেন না।

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

ফ্যাবিয়ান পাস্কাল "নুলস ন্যালিফাইড" তে বেশ কয়েকটি যুক্তি দিয়ে সাড়া দিয়েছেন ।

Comments

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

— জ্যাক ডগলাস

জ্যাক: ঠিক আছে, তবে "বর্তমান বাস্তবায়নগুলি এটি করতে পারে না" স্থিতিশীলতার পক্ষে কোনও আর্গুমেন্ট নয় :-)

— 12:32-

বিমানটি নিখুঁত না হওয়ায় এ জাতীয় কথা কি আমাদের উড়তে হবে না?

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

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

— এরউইন স্মাউট

"নুল কনফিউশন" লিঙ্কটি মারা গেছে।

— jpmc26

Answer 3

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

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

Comments

আমি বিভিন্ন ধরণের একটি ব্যবহারকারী-সংজ্ঞায়িত সেট nullএবং তাদের সাথে যাওয়ার জন্য একটি ব্যবহারকারী-সংজ্ঞায়িত বহু-মূল্যবান যুক্তি রাখার পরামর্শ দিচ্ছি : পি

— জ্যাক ডগলাস

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

— সেন্ডিনেল

NULL এর উপস্থিতি বিশেষ-কেসিং বা সেন্ডিনেল মানগুলির প্রয়োজন হয় না। এগুলি কেবলমাত্র কিছু লোকেরা কীভাবে NULL নিয়ে কাজ করার সিদ্ধান্ত নেয় তার লক্ষণ মাত্র।

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

এটি লক্ষণীয় যে '' পোস্টগ্রিএসকিউএল (যদিও ওরাকল নয়) থেকে নাল থেকে আলাদা এবং এটি আপনাকে একটি দ্বিগুণ চিহ্ন দেয় এবং আপনি সংখ্যার কলামগুলির জন্য 0 ব্যবহার করতে পারেন। 0 এর সাথে সমস্যাটি হ'ল এটি বিদেশী কীগুলির জন্য কাজ করে না।

— ক্রিস ট্র্যাভারস

Answer 4

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

1. নাল মানগুলি বিকাশকে আরও কঠিন এবং বাগ প্রবণ করে তোলে।
2. নাল মানগুলি ক্যোয়ারী, সঞ্চিত পদ্ধতি এবং আরও জটিল এবং বাগ প্রবণ দেখায়।
3. নাল মানগুলি স্থান গ্রহণ করে (? স্থির কলাম দৈর্ঘ্যের উপর ভিত্তি করে বাইটগুলি বা ভেরিয়েবল কলাম দৈর্ঘ্যের জন্য 2 বাইট) take
4. নাল মানগুলি প্রায়শই সূচক এবং গণিতে প্রভাবিত করতে পারে।

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

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

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

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

নীচে একটি খুব সরল টেবিল কাঠামো যা প্রয়োজনীয় নালামযোগ্য কলাম এবং ওয়ান-টু-ওয়ান সম্পর্ক উভয়ই দেখায়।

আমি জানি যে আমি পার্টিতে কিছুটা দেরি করেছি যেহেতু এই প্রশ্নটি বহু বছর আগে জিজ্ঞাসা করা হয়েছিল তবে আশা করি এটি এই বিষয়ে কিছুটা আলোকপাত করতে সহায়তা করবে এবং এর সাথে কীভাবে সেরা সমাধান করা যায়।

Comments

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

— প্রোগ্রামার

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

— নিকোলাস আগুয়েরে

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

— প্রোগ্রামার

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

— নিকোলাস আগুয়েরে

... এটি প্রায় সর্বদা পূরণ করা হবে এবং তারপরে কর্মীর কাছে 1to1 সম্পর্কযুক্ত একটি টার্মিনেট টেবিল তৈরি করুন। আমি সারাদিন ডিবিএ এবং বিকাশকারী হিসাবে বিভিন্ন ডেটাবেজ নিয়ে কাজ করি এবং আমি আনন্দিত যে আপনার প্রস্তাবিত কাঠামোটি আমি এখনও পেরেছি। বিশেষত বিকাশকারীর দৃষ্টিকোণ থেকে, সমস্ত কিছু রচনা এবং ত্রুটিটি পরীক্ষা করা দুঃস্বপ্ন হবে কারণ আপনি জানেন না যে এটি কোন টেবিল থেকে আসছে। এমনকি একটি জয়েন লেখার পরেও, সফ্টওয়্যারটিতে ফিরে আসা ডেটাতে নাল ডেটা সহ এমন একটি ক্ষেত্র থাকবে যা আপনাকে এখনও এটি পরীক্ষা করতে হবে।

— নিকোলাস আগুয়েরে

Answer 5

এনইউএলএল বিভ্রান্তকারী বিকাশকারীদের সাথে সম্পর্কিত সমস্ত সমস্যা ছাড়াও, এনইউএলগুলির আরও একটি গুরুতর অসুবিধা রয়েছে: পারফরম্যান্স

NULL'able কলামগুলি পারফরম্যান্সের দৃষ্টিকোণ থেকে একটি দুর্যোগ। একটি উদাহরণ হিসাবে পূর্ণসংখ্যা গণিত বিবেচনা করুন। NULL ব্যতীত বুদ্ধিমান বিশ্বে, সিপিইউ চক্রের তুলনায় 1 সারির চেয়ে দ্রুত গতিতে কোনও গণনা সম্পাদনের জন্য সিমড নির্দেশাবলী ব্যবহার করে ডাটাবেস ইঞ্জিন কোডে পূর্ণসংখ্যার গাণিতিক পরীক্ষা করা "সহজ"। যাইহোক, আপনি NUL পরিচয় করার মুহুর্তে, আপনাকে NUL তৈরি করা সমস্ত বিশেষ কেসগুলি পরিচালনা করতে হবে। আধুনিক সিপিইউ নির্দেশাবলী সেট (পড়ুন: x86 / x64 / এআরএম এবং জিপিইউ লজিক) কেবল এটি দক্ষতার সাথে করার জন্য সজ্জিত নয়।

উদাহরণ হিসাবে বিভাগ বিবেচনা করুন। খুব উচ্চ স্তরে, নাল নন পূর্ণসংখ্যার সাথে এটি আপনার যুক্তি প্রয়োজন:

if (b == 0)
  do something when dividing by error
else
  return a / b

NULL এর সাথে এটি আরও জটিল হয়ে ওঠে। একসাথে bআপনার জন্য সূচকের প্রয়োজন হবে যদি bএটি নাল এবং একইভাবে হয় a। চেক এখন হয়ে যায়:

if (b_null_bit == NULL)
   return NULL
else if (b == 0) 
   do something when dividing by error
else if (a_null_bit == NULL)
   return NULL
else 
   return a / b

নুল গাণিতিক (প্রায় ২-৩x এর একটি উপাদান দ্বারা) একটি আধুনিক সিপিইউতে চালানোর জন্য ন্যূনাল পাটিগণিত উল্লেখযোগ্যভাবে ধীর er

আপনি সিমডি প্রবর্তন করলে এটি আরও খারাপ হয়। সিমডির সাহায্যে একটি আধুনিক ইন্টেল সিপিইউ একক নির্দেশায় 4 x 32-বিট পূর্ণসংখ্যা বিভাগগুলি সম্পাদন করতে পারে:

x_vector = a_vector / b_vector
if (fetestexception(FE_DIVBYZERO))
   do something when dividing by zero
return x_vector;

এখন, সিমড জমিতেও NULL পরিচালনা করার উপায় রয়েছে তবে এর জন্য আরও ভেক্টর এবং সিপিইউ রেজিস্ট্রার ব্যবহার করা উচিত এবং কিছু চতুর বিট মাস্কিং করা প্রয়োজন। এমনকি ভাল কৌশল সহ, NUL পূর্ণসংখ্যার গাণিতিকের পারফরম্যান্স পেনাল্টি এমনকি তুলনামূলকভাবে সহজ প্রকাশের জন্য 5-10x ধীর গতিতে বিস্ময় প্রকাশ করে।

উপরোক্ত কিছু কিছু সমষ্টি এবং কিছুটা হলেও ধরে রাখে holds

অন্য কথায়: এসকিউএল-এ NUL এর অস্তিত্ব হ'ল ডেটাবেস তত্ত্ব এবং আধুনিক কম্পিউটারগুলির প্রকৃত নকশার মধ্যে একটি প্রতিবন্ধক মিল। NULL বিকাশকারীদের বিভ্রান্ত করার একটি বেশ ভাল কারণ রয়েছে - কারণ বেশিরভাগ বুদ্ধিমান প্রোগ্রামিং ভাষায় একটি পূর্ণসংখ্যা NULL হতে পারে না - এটি কেবল কম্পিউটারগুলি কীভাবে কাজ করে তা নয়।

Answer 6

আকর্ষণীয় প্রশ্ন।

আমি যা ভাবতে পারি তা হ'ল, একজন অ্যাপ্লিকেশন বিকাশকারী হিসাবে আপনাকে NUL এবং একটি সম্ভাব্য অস্তিত্বহীন ডেটা মান (উদাহরণস্বরূপ, স্ট্রিংগুলির জন্য খালি স্ট্রিং) পরীক্ষা করতে হবে না।

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

তবে আপনি তারিখ, তারিখ সময় এবং সময় (এসকিউএল সার্ভার ২০০৮) এর ক্ষেত্রে কী করবেন? আপনাকে কিছু historicতিহাসিক বা তুষারপাতের তারিখ ব্যবহার করতে হবে।

এটি এখনই নালগুলির সাথে সমস্যাটি চিত্রিত করে, যথা একটি টেবিলের মধ্যে থাকা মানটির অর্থ "এই মানটি প্রয়োগ হয় না" বা "আমরা জানি না" হতে পারে। স্ট্রিং সহ, একটি খালি স্ট্রিং "এটি প্রযোজ্য নয়" হিসাবে পরিবেশন করতে পারে তবে তারিখ এবং সময়গুলির সাথে, এমন কোনও কনভেনশন নেই কারণ প্রচলিতভাবে যার অর্থ এটির কোনও বৈধ মান নেই। সাধারণত সেখানে আপনি NULL ব্যবহার করে আটকে যাবেন।

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

সম্পাদনা: একটি অঞ্চল যেখানে NUL গুলি অপরিহার্য, বিদেশী কীগুলিতে। এখানে তাদের সাধারণত একটির অর্থ থাকে, বহিরাগত যোগ শব্দের শূন্যের অনুরূপ। এটি অবশ্যই সমস্যার ব্যতিক্রম।

Answer 7

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

আপনার আরডিবিএমএস কীভাবে গণিতের মতো নির্বাচনী কাজগুলিতে এবং সূচকগুলিতে তাদের পরিচালনা করে তা সম্পর্কে কেবল সচেতন হন।

Answer 8

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

তদ্ব্যতীত, বেশ কয়েকটি উদাহরণে, NULL গুলি 3NF ভেঙে দেবে। যদিও আমি আমার অনেক সহকর্মীর মতো 3NF এর জন্য স্টিকার নই, তবে নিম্নলিখিত পরিস্থিতিটি বিবেচনা করুন:

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

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

সমস্ত স্কিমা জুড়ে কোনও NULs ছাড়াই অযোগ্য কলামগুলি সন্ধানের জন্য একটি দরকারী টি-এসকিউএল স্ক্রিপ্ট:

select 'IF NOT EXISTS (SELECT 1 FROM ' + QUOTENAME(s.name) + '.' + QUOTENAME(t.name) + ' WHERE ' + QUOTENAME(c.name) + ' IS NULL)
    AND (SELECT COUNT(*) FROM ' + QUOTENAME(s.name) + '.' + QUOTENAME(t.name) + ') > 1 PRINT ''' + s.name + '.' + t.name + '.' + REPLACE(c.name, '''', '''''') + ''''
    from sys.columns c
    inner join sys.tables t ON c.object_id = t.object_id
    inner join sys.schemas s ON s.schema_id = t.schema_id
    where c.is_nullable = 1 AND c.is_computed = 0
    order by s.name, t.name, c.name;

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

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

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

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

Comments

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

— পল হোয়াইট