বিদেশী চাবিতে কী সমস্যা?

Question

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

(স্ট্যাক ওভারফ্লো নীতিগুলির সাথে মিল রেখে আলোচনাকে এড়াতে) কেন মানুষের কিছু দৃ some় কারণ রয়েছে?

সম্পাদনা: "আমার কাছে এখনও একটি বিদেশী কী তৈরি করার কারণ আছে, তাই এটি সম্ভবত আমার প্রথম সেট আপ করার কারণ হতে পারে" "

Comments

আমি মনে করি না যে জোল এফকে ব্যবহার করে না, এটি কেবলমাত্র তিনি ডেটাবেসগুলি প্রয়োগ করে না। যৌক্তিকভাবে, তারা এখনও এফকে!

— ড্যারেন টমাস

তিনি বলেছিলেন যে তিনি বিদেশী কী ব্যবহার করেন না, তবে আমি ড্যারেনের সাথে একমত যে তার অর্থ কী সে বিদেশী কী চুক্তি ব্যবহার করে না doesn't এক সারণীর একটি কলাম যার মানগুলি অন্য সারণীর প্রাথমিক / অনন্য কী থেকে নেওয়া হবে বলে মনে করা হচ্ছে বিদেশী কীগুলি, আপনি সীমাবদ্ধতা যুক্ত করুন কিনা।

— টনি অ্যান্ড্রুজ

... সাধারণত প্রতিবন্ধকতা না যুক্তি বোকামি: এটি প্রয়োগ কোডটিতে কোনও বাগ থাকলেও বা যদি আপনার কোনও ডেটা "ফিক্স" করার জন্য পর্দার আড়ালে কাজ করে থাকে তবে তা সর্বকালে সততা নিশ্চিত করে।

— টনি অ্যান্ড্রুজ

টনির মন্তব্যের জন্য +1। বৈশিষ্ট্যটি এবং বিদেশী কীগুলির যৌক্তিক ধারণার মধ্যে খুব বেশি বিভ্রান্তি রয়েছে।

— জনএফএক্স

@ ড্যানমন, আপনি কোথায় ছাপ পেয়েছেন তা আমি জানি না I আমি আসলে উপরে বলেছি "সাধারণত প্রতিবন্ধকতা যুক্ত না করা বোকামি: এটি সর্বকালে নিখরচায়তা বজায় রাখে"

— টনি অ্যান্ড্রুজ 19

Answer 1

বিদেশী কীগুলি ব্যবহার করার কারণগুলি:

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

বিদেশী কীগুলি ব্যবহার না করার কারণগুলি:

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

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

Comments

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

— ম্যাট রোগিশ

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

— ম্যাট রোগিশ

স্পষ্টত - এটি ডিবি-র কাজ হওয়া উচিত, যেহেতু একমাত্র একমাত্র এটি একাধিক সমকালীন ক্লায়েন্টের মুখে লেনদেনের গ্যারান্টি দিতে পারে।

— স্কয়ারকোগ

+1 দুর্দান্ত উত্তর - এফকে সীমাবদ্ধতা ব্যবহার না করার দ্বিতীয় কারণটি "ধারাবাহিকতা ভাঙ্গা শক্ত করে তোলে" যা আসলে ভাল জিনিস বলে মনে হচ্ছে !

— বিল কারভিন

বিদেশী কীগুলি এফএআর ব্যবহারের সুবিধাগুলি আমার মতে সেগুলি ব্যবহার না করার যে কোনও সুবিধা ছাড়িয়ে যায়।

— নিক বেডফোর্ড

Answer 2

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

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

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

Comments

আমি পাতনযুক্ত "বিদেশী কীগুলি আপনার দাঁত ব্রাশ করার মতো: ব্যবহার করতে যাচ্ছি: এগিয়ে যান, এগুলি না করে তবে আপনি যখন হাসেন তখন সাবধানতা অবলম্বন করুন"

— মার্ক সোওল

আমি ব্যক্তিগতভাবে দেখতে পেয়েছি যে

— আরডিবিএমএসের নীতিগুলি

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

— বরুণগ

Answer 3

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

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

Comments

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

— অনাথকে পেয়েছি

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

— অ্যালেক্সকুস

এগুলি সমস্ত লিপি / অ্যাটউডের প্রতিক্রিয়া "আতউড: ... আপনি সূচীগুলিতে স্থাপন করেছেন এমন বিদেশী কীগুলির উপর ভিত্তি করে তারা এটি আবিষ্কার করে ... স্পলস্কি: [হেসে] ধরে নিলেন যে আপনি এটি করেন At আটউড: আচ্ছা, ধরে নিই আপনি আপনার ডাটাবেসটি সঠিকভাবে সেট আপ করেছেন ... "

— মেমডেভোপার

ডাটাবেজ বলা হয় না রিলেশনাল কারণ সম্পর্ক সারণির মধ্যে (ডাটাবেস প্রতি ধরনের সত্ত্বা মধ্যে সম্পর্ক কোন ধরণের আছে!), কিন্তু কারণ টেবিল নিজেরাই সম্পর্ক , গণিত পদ। উইকিপিডিয়া দেখুন ।

— ম্যাসিমিলিয়ানো ক্রাউস

Answer 4

যে কোনও রিলেশনাল ডাটাবেস মডেলের জন্য বিদেশী কীগুলি প্রয়োজনীয় ।

Comments

মডেল, হ্যাঁ। বাস্তবায়ন, প্রয়োজনীয় নয়, কেবল সম্ভবত দরকারী।

— dkretz

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

— সেন্টিনেল

না, বিদেশী কীগুলি "সম্পর্কিত" নির্দেশ করতে বাধ্যতামূলক নয়

— সিলভার মুন

এটি আসলে খুব বেশি ব্যাখ্যা করে না।

— Nae থেকে

Answer 5

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

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

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

Comments

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

— জয় গডসে

Answer 6

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

---

বিদেশী কীগুলি স্বয়ংক্রিয় পরীক্ষাকে জটিল করে তোলে

মনে করুন আপনি বিদেশী কী ব্যবহার করছেন। আপনি একটি স্বয়ংক্রিয় পরীক্ষা লিখছেন যা বলছে "যখন আমি একটি আর্থিক অ্যাকাউন্ট আপডেট করি তখন এটি লেনদেনের একটি রেকর্ড সংরক্ষণ করে।" এই পরীক্ষায়, আপনি কেবল দুটি টেবিল নিয়ে উদ্বিগ্ন: accountsএবং transactions।

তবে accountsএর একটি বিদেশী কী রয়েছে contractsএবং contractsএর একটি এফকে টু রয়েছে clientsএবং clientsএর একটি এফকে টু রয়েছে citiesএবং citiesএফকে টু রয়েছে states।

এখন ডাটাবেস আপনাকে চারটি টেবিলের সাথে ডেটা স্থাপন না করে পরীক্ষা চালানোর অনুমতি দেবে না যা আপনার পরীক্ষার সাথে সম্পর্কিত নয় ।

এটি সম্পর্কে কমপক্ষে দুটি সম্ভাব্য দৃষ্টিভঙ্গি রয়েছে:

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

পরীক্ষা চলাকালীন অস্থায়ীভাবে বিদেশী কী চেক বন্ধ করাও সম্ভব হতে পারে। মাইএসকিউএল, অন্ততপক্ষে এটি সমর্থন করে ।

Comments

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

— জেলপট

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

— জিবি

এছাড়া DBMS যে সীমাবদ্ধতার করার মঞ্জুরি দেয় ডেফার্ড যাতে তারা শুধুমাত্র পরীক্ষিত হয় যখন আপনি পুরো লেনদেন কমিট, সন্নিবেশ করুন, আপডেট ক্রম তাই হয়, ডিলিট ব্যাপার না

— a_horse_with_no_name

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

— কীঅফজে

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

— আন্দ্রেয়াস বার্গস্ট্রোম

Answer 7

"তারা মুছে ফেলা রেকর্ডকে আরও জটিল করে তুলতে পারে - যেখানে আপনি অন্যান্য সারণীতে রেকর্ড রয়েছে সেখানে" মাস্টার "রেকর্ড মুছতে পারবেন না যেখানে বিদেশী কীগুলি এই সীমাবদ্ধতা লঙ্ঘন করবে।"

এটি মনে রাখা গুরুত্বপূর্ণ যে এসকিউএল স্ট্যান্ডার্ড বিদেশী কী মুছে ফেলা বা আপডেট করা হলে নেওয়া কর্মগুলি সংজ্ঞায়িত করে। আমি যাদের সম্পর্কে জানি তারা হ'ল:

• ON DELETE RESTRICT- অন্যান্য সারণীতে যে কোনও সারি এই কলামে কীগুলি মুছে ফেলা থেকে আটকাচ্ছে। উপরে বর্ণিত কেন রে এটিই বলেছিলেন।
• ON DELETE CASCADE - অন্য টেবিলের একটি সারি যদি মুছে ফেলা হয়, তবে এই সারণীতে যে কোনও সারি মুছে ফেলা হবে delete
• ON DELETE SET DEFAULT - অন্য টেবিলের একটি সারি যদি মুছে ফেলা হয় তবে কলামের ডিফল্ট হিসাবে উল্লেখ করে যে কোনও বিদেশী কী সেট করুন।
• ON DELETE SET NULL - অন্য টেবিলের একটি সারি যদি মুছে ফেলা হয়, তবে এই টেবিলটিতে উল্লেখ করে যে কোনও বিদেশী কী সেট করে ফেলুন ull
• ON DELETE NO ACTION- এই বিদেশী কী কেবল এটি বিদেশী কী হিসাবে চিহ্নিত করে; অর্থাত্ ওআর ম্যাপারগুলিতে ব্যবহারের জন্য।

এই একই ক্রিয়াগুলি প্রযোজ্য ON UPDATE।

ডিফল্ট মনে হয় যা নির্ভর করে SQL আপনি যে সার্ভারটি ব্যবহার করছেন।

Answer 8

@ আইফাসিং - এটি ঠিক এমন এক ধরণের মানসিকতা যা রক্ষণাবেক্ষণের দুঃস্বপ্ন দেখা দেয়।

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

Comments

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

— zxq9

Answer 9

এগুলি ব্যবহার না করার একটি ভাল কারণ রয়েছে: আপনি যদি তাদের ভূমিকা বা কীভাবে সেগুলি ব্যবহার করবেন তা বুঝতে না পারলে।

ভুল পরিস্থিতিতে, বিদেশী মূল সীমাবদ্ধতাগুলি দুর্ঘটনার জলপ্রপাতের প্রতিক্রিয়ার দিকে নিয়ে যেতে পারে। যদি কেউ ভুল রেকর্ডটি সরিয়ে দেয় তবে এটিকে পূর্বাবস্থায় ফেলা একটি বিশাল কাজ হয়ে উঠতে পারে।

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

Comments

ব্যাকআপ ব্যতীত উত্পাদনে একটি সারি মুছে ফেলা বৈধ যুক্তি নয়। আপনি যদি সেগুলি বুঝতে না পারেন তবে এটিকে বাদ দেওয়ার পরিবর্তে আপনার এটি সম্পর্কে শেখার বিষয়টি বিবেচনা করা উচিত।

— গিলাইম

@ গুইলাউম আমি মনে করি তার উত্তরটি কিছুটা ব্যঙ্গাত্মক ছিল, আক্ষরিকভাবে নেওয়া উচিত নয়: আপনি যদি সেগুলি বুঝতে না পারেন, তবে সেগুলি ব্যবহার করবেন না। তবে অবশ্যই আপনার উভয়টি বোঝা এবং ব্যবহার করা উচিত ।

— বেনিয়ামিন

এই। এগুলি দরকারী সরঞ্জাম, তবে একজন নবজাতকের হাতে, তারা বিপজ্জনক সরঞ্জাম।

— কেন্ট ফ্রেড্রিক

Answer 10

এগুলি ব্যবহার না করার কোনও ভাল কারণ নেই ... যতক্ষণ না অনাথ সারিগুলি আপনার কাছে বড় জিনিস না বলে আমার ধারণা।

Comments

অনাথ সারি কেন একটি বড় ব্যাপার?

— Seun Osewa

মাল্টিথ্রেডিংয়ের কী হবে? এগুলি নির্দিষ্ট পরিস্থিতিতে বহুবিবাহের দুঃস্বপ্ন দেখা দিতে পারে। একাধিক থ্রেডে ডাটাবেস লেখার একটি জটিল অ্যাপ্লিকেশনে যা একে অপরের রেফারেন্স করার প্রয়োজন হতে পারে, ব্যবসায়ের যুক্তিতে রেফারেন্সিয়াল অখণ্ডতা নিয়ন্ত্রণ করা ভাল particularly বিশেষত যদি টেবিলগুলি স্থির হয়ে যায়।

— কিথ পিনসন

আমি রাজী. এছাড়াও, আমি ওফান সারিগুলিকে পছন্দ করি যা আমি পরে নির্ধারিতভাবে পুনরুদ্ধার করতে পারি, সেগুলি নির্দয়ভাবে বাদ দেওয়া ছাড়া।

— পেড্রোড

Answer 11

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

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

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

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

QUERY পারফরম্যান্স - যদি টেবিলগুলি বিদেশী কীগুলিতে যুক্ত হয় তবে বিদেশী কী কলামগুলি সংশোধিত নয় (যদিও স্বতন্ত্র প্রাথমিক কী সংজ্ঞা অনুসারে সূচিযুক্ত) সে সম্পর্কে সচেতন হন। কোনও বিদেশী কী সূচীকরণের মাধ্যমে, কোনও কী সূচী দিয়ে এবং সূচকের উপরে সারণিতে যোগ দেওয়া ভাল পারফরম্যান্সে সহায়তা করে, এতে বিদেশী কী বাধার সাথে নন-সূচকযুক্ত কীতে যোগ দিয়ে নয়।

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

Comments

ভাল, আমি জানি না কেন ফাঁকা জায়গায় 3 টি ডবল নিউলাইন সন্নিবেশ করানো এবং '67% হোন জোনাথন লেফলার 'হিসাবে দুটি শব্দের সংখ্যা পরিবর্তন করা, তবে আমি মনে করি না যে আমি এটির মতো এত কিছু করেছি। মূল পাঠ্যটি @Jay (ব্যবহারকারী 183837) দ্বারা অবদান ছিল।

— জোনাথন লেফলার

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

— জাসবীর এল

Answer 12

বিদেশী কীগুলি ব্যবহার করার অতিরিক্ত কারণ: - একটি ডেটাবেসের বৃহত্তর পুনরায় ব্যবহারের অনুমতি দেয়

বিদেশী কীগুলি ব্যবহার না করার অতিরিক্ত কারণ: - আপনি পুনরায় ব্যবহার হ্রাস করে কোনও গ্রাহককে আপনার সরঞ্জামটিতে লক-ইন করার চেষ্টা করছেন।

Answer 13

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

এফকেগুলি এড়ানোর জন্য এটি আরও ভাল তবে এর ঝুঁকিটি প্রোগ্রামারদের দ্বারা পরিচালনা করতে হবে।

Comments

আমি মনে করি না যে বড় ব্যাংকগুলিতে উন্নয়নের চর্চাগুলি সোনার মান সেট করে।

— অ্যাডরিয়ান কোস্টার

Answer 14

"একটি রেকর্ড যুক্ত করার আগে, পরীক্ষা করুন যে অন্য কোনও টেবিলের সাথে সম্পর্কিত রেকর্ড বিদ্যমান" ব্যবসায়িক যুক্তি।

ডাটাবেসে আপনি এটি চান না এমন কয়েকটি কারণ এখানে রয়েছে:

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

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

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

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

Answer 15

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

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

Comments

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

— জে গডসে

সামঞ্জস্যপূর্ণ, প্রত্যাশিত অ্যাক্সেসের পাথগুলিতে বিশাল পরিমাণের ডেটা পড়ার সময় একটি ড্যানোরালাইমাইজড ডেটা গুদাম ব্যবহার করতে পারে । অন্যান্য সমস্ত পরিস্থিতিতে, এটি একটি বিপজ্জনক ফাঁস।

— পিটার উইন

Answer 16

ক্লিয়ারি ডাটাবেস এমন বাণিজ্যিক ডাটাবেসের একটি উদাহরণ যার কোনও প্রাথমিক বা বিদেশী কী নেই।

http://www.geekinterview.com/question_details/18869

মজার বিষয় হ'ল, প্রযুক্তিগত ডকুমেন্টেশনগুলি টেবিলগুলি কীভাবে সম্পর্কিত, কী কী কলামগুলি এতে যোগদানের জন্য ব্যবহার করবে ইত্যাদি ব্যাখ্যা করার জন্য যথেষ্ট পরিমাণে যায় etc.

অন্য কথায়, তারা সুস্পষ্ট ঘোষণাপত্র (ডিআরআই) দিয়ে টেবিলগুলিতে যোগ দিতে পারত তবে তারা তা পছন্দ করে নি ।

ফলস্বরূপ, ক্লিয়ারি ডাটাবেসটি অসঙ্গতিতে পূর্ণ এবং এটি আন্ডারফর্ম করে।

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

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

Comments

ব্যর্থ রেফারেন্সিয়াল অখণ্ডতা যাচাই করতে কোডটি অসঙ্গত ডেটা হ্যান্ডেল করার কোডের চেয়ে অনেক ছোট।

— জয় গডসে

@ জায়ে রাজি! ভাববেন না যে আমি এই পদ্ধতির পক্ষে করছি।

— এড গিনিস

Answer 17

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

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

বিদেশী কীগুলি যেমন প্রাথমিক কীগুলির মতো প্রয়োজনীয়। এটি বলার মতো: আমরা যদি প্রাথমিক কীগুলি সরিয়ে ফেলি তবে কী হবে? ঠিক আছে, মোট বিশৃঙ্খলা ঘটতে চলেছে। তাতে কি. আপনি প্রাথমিক বা বিদেশী কী দায়বদ্ধতা প্রোগ্রামিং স্তরে সরিয়ে নিতে পারেন না, এটি অবশ্যই ডেটা স্তরে থাকতে হবে।

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

Answer 18

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

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

আমি বিশ্বাস করি যে ফায়ারগাইন কীগুলি ব্যবহারের সুবিধাগুলি কোনও অনুমানের অসুবিধা ছাড়িয়ে যায়।

Comments

আমি যে কোনওভাবেই খুব কমই মুছতে চাই। শুধু চিহ্নটিতে একটি "দৃশ্যমান / সক্রিয়" বিট থাকে।

— ডানা

"আমি বিশ্বাস করি ফায়ারগাইন কী ব্যবহারের সুবিধাগুলি যে কোনও অসুবিধা ছাড়িয়ে যায়"

— ইয়ান বয়েড

আপনি কখনই কোনও প্রাথমিক কী এর মান পরিবর্তন করবেন না । আপনি মোছার পুরো সারি এবং পুনঃ এটা ভিন্নভাবে। আপনি যদি মনে করেন এটি পরিবর্তন করা দরকার তবে আপনার স্কিমা ত্রুটিযুক্ত।

— ড্যানম্যান

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

— কীআফজেজে

Answer 19

বিদেশী কী সীমাবদ্ধতা যাচাই করতে কিছু সিপিইউ সময় লাগে, তাই কিছু লোকেরা কিছু অতিরিক্ত কর্মক্ষমতা পেতে বিদেশী কী বাদ দেয়।

Comments

সদৃশ এবং অসামঞ্জস্যপূর্ণ ডেটা অপসারণে কতটা সিপিইউ সময় ব্যয় হয়?

— এড গিনিস

হ্যাঁ, এটা সত্য। যে সিস্টেমে আমি কাজ করি তাতে আমাদের ডাটাবেসে একসাথে 10 - 40 জিগ ডেটা inোকাতে হয় এবং এর সাথে এবং ছাড়া এফকে পারফরম্যান্স এটি গ্রহণ করতে পুরো সময়টিতে দৃশ্যমান হয়।

— পল মেন্দোজা

Answer 20

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

Comments

আমি বিশ্বাস করি যে এফকে-র সীমাবদ্ধতা কিছু লোক ব্যবহার করে না (বেশিরভাগ, আমার দৃষ্টিকোণে) ভান করে যে তারা তাদের কর্মক্ষমতা সাশ্রয় যুক্তি দিয়ে তাদের অলসতা রক্ষা করতে পারে under আমি দৃly়ভাবে বিশ্বাস করি যে আমাদের কোম্পানির যে মূর্খতা ব্যয় ঘটে তার সিংহভাগই এফকে সীমাবদ্ধতাগুলি প্রয়োগ না করার কারণে এবং এটি কোনও কোম্পানির মাধ্যমে যে প্রভাব ফেলেছিল তার কারণে ঘটে। অনন্য কীগুলির অভাবটি হ'ল অন্য জিনিস যা আমাকে 2000+ লাইনের সঞ্চিত পদ্ধতিগুলির 12 টি স্তরের নেস্টেড আইএফ এবং এলোমেলো ইনডেন্টিংয়ের সাথে বাদাম চালায় তবে আমি এখন থামব।

— চাদ

Answer 21

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

সম্পাদনা: আমার ধারণা হ'ল তিনি বিদেশী কী বাধাগুলি উল্লেখ করছেন , বিদেশী কীগুলি ধারণা হিসাবে নয়।

Comments

নাঃ। তিনি আসল চাবি পছন্দ করেন না!

— ljs

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

— লর্ডস্করলেট

হ্যাঁ আমি তাঁর কথা শুনে হতবাক হয়ে গেলাম। তিনি অবশ্য অজান্তেই জিভ-ইন-গাল থাকতে পারেন; সম্ভবত তিনি এখানে পোস্ট করবেন এবং কোনও পর্যায়ে স্পষ্ট করবেন :-)

— ljs

Answer 22

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

Answer 23

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

আমি দেখতে পেয়েছি যে আমার সমস্ত প্রকল্পের 99% সালে আমার কাছে ডেটার অখণ্ডতা প্রয়োগের জন্য এফকে থাকতে হবে, তবে, এমন বিরল ঘটনাগুলি রয়েছে যেখানে আমার ক্লায়েন্টরা তাদের পুরানো ডেটা রাখা উচিত, এটি যত খারাপ হোক না কেন ... তবে আমি কোড লেখার জন্য অনেক সময় ব্যয় করি যা যাইহোক যাইহোক কেবলমাত্র বৈধ ডেটা পেতে যায় তাই এটি অর্থহীন হয়ে যায়।

Answer 24

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

Answer 25

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

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

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

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

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

Answer 26

আমি দিমিত্রি এর উত্তর প্রতিধ্বনিত করেছি - খুব ভালভাবে লিখেছি।

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

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

Answer 27

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

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

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

Comments

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

— টিম গৌটিয়ার

Answer 28

আপনি যদি নিখুঁতভাবে নিশ্চিত হন যে ভবিষ্যতে যে কোনও অন্তর্নিহিত ডাটাবেস সিস্টেম পরিবর্তন হবে না, আমি ডেটা অখণ্ডতা নিশ্চিত করতে বিদেশী কী ব্যবহার করব।

তবে বিদেশী কীগুলি ব্যবহার না করার জন্য এখানে আরেকটি খুব ভাল বাস্তব জীবনের কারণ রয়েছে:

আপনি এমন একটি পণ্য বিকাশ করছেন যা বিভিন্ন ডাটাবেস সিস্টেমকে সমর্থন করে।

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

এটি বিভিন্ন সমস্যা হতে পারে:

১) ডাটাবেস কাঠামোটি তৈরি বা আপডেট হয়ে গেলে আপনি ত্রুটিগুলিতে চলে যেতে পারেন। সম্ভবত কেবল নীরব ত্রুটি থাকবে কারণ আপনার বিদেশী কীগুলি কেবল ডাটাবেস সিস্টেম দ্বারা উপেক্ষা করা হয়েছে।

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

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

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

Answer 29

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

Comments

এটি একটি আলোচনার চেয়ে অফ-দ্য-কফ মন্তব্য বেশি ছিল, যদিও সম্ভবত এই বিষয়ে তিনি স্বাধীনভাবে কী ভাবেন সে সম্পর্কে আমার অবিকল গবেষণা করা উচিত! তবে আমি এই বিষয়ে সম্প্রদায়ের মতামত সম্পর্কেও আগ্রহী ছিলাম!

— ljs

Answer 30

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

Comments

আপনি যদি বলার চেষ্টা করছেন তা যদি আমি বুঝতে পারি তবে আমি মনে করি যে আমার উত্তরটি হ'ল যুক্তিযুক্তভাবে অনুসন্ধান সারণিতে রেকর্ডটি মুছতে হবে বা আর প্রাসঙ্গিক historicalতিহাসিক ডেটা সংরক্ষণাগারভুক্ত করা এবং লুকিং রেকর্ডটি সংরক্ষণাগারভুক্ত করা হবে।

— চাদ