নালযোগ্য বিদেশী কী খারাপ অভ্যাস?

Question

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

ডাটাবেসে আসলে অনেকগুলি NUL থাকবে না, কারণ NULL এর জন্য একটি বিদেশী কী সহ একটি রেকর্ড অস্থায়ীভাবে অর্ডারটির জন্য কোনও গ্রাহক সংযুক্ত না হওয়া পর্যন্ত।

(আমার ক্ষেত্রে এটি কোনও অর্ডার এবং গ্রাহক নয়)।

সম্পাদনা: একটি নিবন্ধিত গ্রাহকের সাথে লিঙ্ক করার জন্য কী?

Comments

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

— গাহোয়া

আমি প্রথমে প্রশ্নটি নলযোগ্য প্রাথমিক কী হিসাবে পড়েছি এবং কিছু দৃ strong

— ়

Answer 1

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

পাশের নোটে; লিঙ্ক টেবিলটি ব্যবহার করা অগত্যা এটিকে এন থেকে এন করে তোলে না, যদি আপনি লিঙ্ক টেবিলের মধ্যে থাকা বিদেশী কী ব্যবহার করেন যা আপনার অর্ডার টেবিলটিকে সেই লিঙ্ক টেবিলের প্রাথমিক কী হিসাবে দেখায় তবে সম্পর্কটি এখনও 1..n হয়। অর্ডার অনুযায়ী লিঙ্ক সারণিতে কেবল একটি প্রবেশ হতে পারে can

Comments

উত্স__ নির্ধারণ_লিঙ্ক বা উত্স নির্ধারণ

— Svisstack

আমি যখন কোনও লিঙ্ক টেবিল থাকা ভাল তখন কোনও পরিস্থিতি সম্পর্কে শুনতে আগ্রহী হয়ে উঠি, আমি কোনও অবস্থাতেই যাইনি যেখানে এটি কোনওভাবেই প্রক্রিয়া প্রবাহকে উন্নত করতে পারে।

— রিমিয়াস

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

— প্যাট্রিক হাগনে

Answer 2

না নুলাবল এফকে নিয়ে কোনও ভুল নেই। এটি সাধারণ যখন এফকে নির্দেশিত সত্তা প্রাথমিক কী রেফারেন্স সারণীর সাথে (শূন্য বা এক) সাথে (1 বা অনেক) সম্পর্কের মধ্যে থাকে।

একটি উদাহরণ হতে পারে যদি কোনও টেবিলে আপনার কোনও শারীরিক ঠিকানা এবং কোনও মেইলিং অ্যাড্রেস অ্যাট্রিবিউট (কলাম) থাকে, যাতে কোনও এড্রেস টেবিলের এফকে থাকে। আপনি যখন শারীরিক ঠিকানাটি কেবলমাত্র পোস্ট অফিসের বাক্স (মেলিং ঠিকানা) এবং মেইলিং ঠিকানাটি শারীরিক ঠিকানার (যেমন না) ঠিক একইরকম হয় তখন হ্যান্ডেল করার জন্য শারীরিক ঠিকানাটিকে হ্রাস করতে পারে।

Answer 3

নালামযোগ্য কলামগুলি 5NF এর মাধ্যমে 1NF এ থাকতে পারে তবে আমি যা পড়েছি তা 6NF তে নয়।

আপনি যদি ক্রিস ডেটের চেয়ে আরও ভাল জানেন তবে "প্রথম সাধারণ ফর্মটি আসলে কী বোঝায়"। যদি x এবং y উভয়ই নমনীয় হয় এবং সত্যই কিছু সারিতে x এবং y উভয় হয় nullতবে WHERE x=yফল পাওয়া যায় না true। এটি যুক্তিসঙ্গত সন্দেহের বাইরে প্রমাণ করে যে নাল একটি মান নয় (কারণ কোনও আসল মান সর্বদা নিজের সমান হয়)। আর যেহেতু আরএম লিখেছেন যে "একটি টেবিলের প্রতিটি কক্ষে অবশ্যই একটি মান থাকতে হবে", যে কোনও জিনিসই সম্ভবত নালগুলি যুক্ত করে, এটি কোনও সম্পর্কযুক্ত জিনিস নয় এবং এভাবে 1 এনএফের প্রশ্নও উঠে না।

আমি শুনেছি এটি যুক্তি দিয়েছিল যে সাধারণভাবে নুলযোগ্য কলামগুলি সাধারণীকরণের প্রথম ডিগ্রি ভঙ্গ করে।

যুক্তিটির অন্তর্নিহিত শব্দটির জন্য উপরে দেখুন।

তবে বাস্তবে এটি অত্যন্ত ব্যবহারিক।

কেবলমাত্র যদি আপনি মাথা ব্যাথার প্রতিরোধক হয়ে থাকেন যা এটি সাধারণত পুরো পৃথিবী জুড়ে ঘটে। এ জাতীয় একটি মাথাব্যথা (এবং এটি কেবলমাত্র একটি ছোট্ট, তুলনামূলকভাবে অন্যান্য nullঘটনাগুলির সাথে তুলনামূলকভাবে ) WHERE x=yএসকিউএল-এর প্রকৃত অর্থ হ'ল WHERE x is not null and y is not null and x=y, তবে বেশিরভাগ প্রোগ্রামাররা কেবল সেই সত্য সম্পর্কে অবগত নন এবং কেবল এটি পড়েন। কখনও কখনও কোনও ক্ষতি ছাড়াই, অন্য সময় না।

আসলে, নালামযোগ্য কলামগুলি সর্বাধিক মৌলিক ডাটাবেস ডিজাইনের বিধি লঙ্ঘন করে: একটি কলামে পৃথক তথ্য উপাদান একত্রিত করবেন না। নুলস ঠিক তাই করে কারণ তারা "এই ক্ষেত্রটি সত্যই উপস্থিত নয় / আছে" প্রকৃত মানটির সাথে বুলিয়ান মানটি একত্রিত করে।

Comments

"WHERE x নাল নয় এবং y টি নাল এবং x = y নয়" এর জন্য +1 সচেতন ছিল না।

— রবএম

খুব সুন্দরভাবে যুক্তি এবং উদাহরণ স্থাপন।

— পেডজ

একটি সমস্যা. যখন মানটি "অস্তিত্বহীন" থাকে (যা সত্য-জগতের পরিস্থিতি) এবং ডাটাবেস অ্যাট্রিবিউট নালাগুলি মঞ্জুরি দেয় না, বৈশিষ্ট্যের মধ্যে যে কোনও মানই WRONG হয়। মাথাব্যথা হিসাবে মনে রাখবেন, KISS, এটি কেবল সহজ রাখার অর্থ নয়, এর অর্থ এটি যতটা সম্ভব সহজ রাখুন, তবে কোনও সরল নয়। "রিলেশনাল মডেল" যদি অবাস্তব, মূ ?় ফলাফলের প্রয়োজন হয়, তবে সম্ভবত প্রয়োজনীয় বাস্তব-বিশ্বের ডেটা হ্যান্ডেল করার জন্য নিয়মগুলি প্রসারিত করতে হবে?

— চার্লস ব্রেটানা

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

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

ক্রিস ডেট, লজিক এবং ডেটাবেসস, ​​অধ্যায় 6, "কেন রিলেশনাল ডিবিএমএস যুক্তিটি বহু মূল্যবান হওয়া উচিত নয়", পৃষ্ঠা 145 that অধ্যায়টির উল্লেখগুলির তালিকাটিও আকর্ষণীয় হওয়া উচিত, বিশেষত ম্যাকগভেরানকে জড়িত।

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

Answer 4

আমি এটিতে কোনও ভুল দেখতে পাচ্ছি না যে এটি কেবল একটি optionচ্ছিক এন -1 সম্পর্ক যা বিদেশী-কীতে নাল দিয়ে উপস্থাপন করা হবে। অন্যথায় যদি আপনি আপনার লিঙ্ক টেবিলটি রাখেন তবে আপনাকে পরিচালনা করতে হবে যে এটি কোনও এনএন সম্পর্ক হয়ে ওঠে না, ফলে আরও বেশি সমস্যার সৃষ্টি হয়।

Comments

আসলে এটি 0-N সম্পর্ক, ,চ্ছিক 1-এন সম্পর্ক নয়। তবে আমি আপনার সাথে একমত

— এরিক জে।

পরিচালনা করবেন? এটি 0-থেকে -1 দিকে একটি সাধারণ অনন্য বাধা!

— wqw

হ্যাঁ এটি একটি অনন্য বাধা, তবে আপনার এই

— কোডটির

Answer 5

Relationচ্ছিক সম্পর্কগুলি অবশ্যই সম্পর্কের মডেলটিতে সম্ভব।

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

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

Answer 6

অসম্পূর্ণ অর্ডারগুলি পরিষ্কার করার জন্য NULL ব্যবহার করা ভাল উপায় হবে:

SELECT * FROM `orders`
WHERE `started_time` < (UNIX_TIMESTAMP() + 900) AND `customer_id` IS NULL

উপরের কোনও সম্পর্কিত গ্রাহক আইডি ছাড়াই 15 মিনিটেরও বেশি পুরানো অর্ডার প্রদর্শন করবে।

Answer 7

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

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

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

Comments

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

— লিভেন কার্ডোইন

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

— জনি করর

Answer 8

আপনি সর্বদা আপনার গ্রাহক টেবিলটিতে একটি কৃত্রিম সারি যুক্ত করতে পারেন, আইডি = -1 এবং গ্রাহক নাম = 'অজানা' এর মতো এবং তারপরে আপনি যখন সাধারণত গ্রাহকআইডকে অর্ডারে সেট করেন তখন এটি এ -1 এ সেট করে।

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

Comments

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

— মূল্য

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

— আইসডড্যান্ট

Answer 9

একচেটিয়া একাধিক সম্পর্কের জন্য নুলযোগ্য এফকে সম্পূর্ণরূপে ঠিক আছে।

Answer 10

আমি শুনেছি এটি যুক্তি দিয়েছিল যে সাধারণভাবে নুলযোগ্য কলামগুলি সাধারণীকরণের প্রথম ডিগ্রি ভঙ্গ করে। তবে বাস্তবে এটি অত্যন্ত ব্যবহারিক।

Comments

নালামযোগ্য কলামগুলি 5NF এর মাধ্যমে 1NF এ থাকতে পারে তবে আমি যা পড়েছি তা 6NF তে নয়।

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

Answer 11

হ্যাঁ কিছু ভুল আছে। এটি অবিশ্বাস্য হলে এটি কোনও বিদেশী কী নয়। কোড দ্বারা এটি ডাটাবেস ডিজাইন। সম্ভবত আপনি স্বাক্ষরযুক্ত একটি শূন্য লিঙ্ক করতে। বা যদি আপনি একটি অক্ষর কল ব্যবহার করে "স্বাক্ষরিত" না হয়। আপনার ডেটার অখণ্ডতা 100% রাখুন।