প্রাইমারি কী হিসাবে সর্বদা একক পূর্ণসংখ্যা কলামটি রাখার বিপর্যয় কী হতে পারে?


18

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

তবে জেনেরিক সংগ্রহস্থলের জন্য একটি সাধারণ নকশা তৈরি করতে, সমস্ত জড়িত সারণীগুলির একটি অনন্য পূর্ণসংখ্যা ( Int32সি # তে, intএসকিউএল মধ্যে) অবশ্যই সংজ্ঞায়িত করতে হবে । এখন অবধি, এটি সর্বদা টেবিলের পিকে এবং এছাড়াও ছিলIDENTITY

বিদেশী কীগুলি ভারী ব্যবহৃত হয় এবং তারা এই পূর্ণসংখ্যা কলামগুলি উল্লেখ করে। এগুলি উভয় ধারাবাহিকতার জন্য এবং ওআরএম দ্বারা নেভিগেশনাল সম্পত্তি তৈরির জন্য প্রয়োজনীয়।

অ্যাপ্লিকেশন স্তরটি সাধারণত নিম্নলিখিত ক্রিয়াকলাপগুলি করে:

  • সারণী (*) থেকে প্রাথমিক ডেটা লোড -SELECT * FROM table
  • আপডেট -UPDATE table SET Col1 = Val1 WHERE Id = IdVal
  • মুছুন -DELETE FROM table WHERE Id = IdVal
  • সন্নিবেশ -INSERT INTO table (cols) VALUES (...)

কম ঘন ঘন অপারেশন:

  • বাল্ক সন্নিবেশ - BULK INSERT ... into tableসমস্ত ডেটা লোড (উত্পন্ন সনাক্তকারী পুনরুদ্ধার করতে) অনুসরণ করে (*)
  • বাল্ক মুছুন - এটি একটি সাধারণ মুছে ফেলা অপারেশন, তবে ওআরএমের দৃষ্টিকোণ থেকে "বাল্কি":DELETE FROM table where OtherThanIdCol = SomeValue
  • বাল্ক আপডেট - এটি একটি সাধারণ আপডেট অপারেশন, তবে ওআরএমের দৃষ্টিকোণ থেকে "বাল্কি":UPDATE table SET SomeCol = SomeVal WHERE OtherThanIdCol = OtherValue

* সমস্ত ছোট টেবিল অ্যাপ্লিকেশন পর্যায়ে ক্যাশে করা হয় এবং প্রায় সবগুলি SELECTsডাটাবেসে পৌঁছায় না। একটি সাধারণ প্যাটার্ন হ'ল প্রাথমিক লোড এবং প্রচুর INSERTএস, UPDATEএস এবং DELETEএস।

বর্তমান অ্যাপ্লিকেশন ব্যবহারের ভিত্তিতে, যে কোনও সারণীতে 100 এম রেকর্ডে পৌঁছানোর খুব কম সম্ভাবনা রয়েছে।

প্রশ্ন: ডিবিএর দৃষ্টিকোণ থেকে, এই টেবিল ডিজাইনের সীমাবদ্ধতা রেখে আমি যে উল্লেখযোগ্য সমস্যাগুলি চালাতে পারি?

[Edit]

উত্তরগুলি (দুর্দান্ত প্রতিক্রিয়াটির জন্য ধন্যবাদ) এবং রেফারেন্স করা নিবন্ধগুলি পড়ার পরে আমার মনে হচ্ছে আমাকে আরও বিশদ যুক্ত করতে হবে:

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

  2. "সারি আলাদা আলাদাভাবে চিহ্নিত করার একমাত্র উপায় তাদের হওয়া উচিত নয়" (অ্যারন বারট্র্যান্ড ♦) - এটি খুব ভাল পরামর্শ। আমার সমস্ত টেবিলগুলি ব্যবসায়ের সদৃশ মঞ্জুরিপ্রাপ্ত নয় তা নিশ্চিত করার জন্য একটি অনন্য চুক্তিও সংজ্ঞায়িত করে।

  3. ফ্রন্ট-এন্ড অ্যাপ্লিকেশন চালিত ডিজাইন বনাম ডাটাবেস চালিত ডিজাইন - নকশার পছন্দটি এই কারণগুলির কারণে ঘটে

    1. সত্তা ফ্রেমওয়ার্ক সীমাবদ্ধতা - একাধিক কলাম পিকে অনুমোদিত, তবে তাদের মান আপডেট করা যায় না

    2. কাস্টম সীমাবদ্ধতা - একটি একক পূর্ণসংখ্যা কী থাকা তথ্য স্ট্রাকচার এবং নন- এসকিউএল কোডকে বিস্তৃত করে। উদাহরণস্বরূপ: মানগুলির সমস্ত তালিকার একটি পূর্ণসংখ্যা কী এবং প্রদর্শিত মান রয়েছে। আরও গুরুত্বপূর্ণ, এটি গ্যারান্টি দেয় যে ক্যাশে করার জন্য চিহ্নিত কোনও টেবিল একটি Unique int key -> valueমানচিত্রে রাখতে সক্ষম হবে ।

  4. জটিল নির্বাচন জিজ্ঞাসা - এটি প্রায় কখনও ঘটবে না কারণ সমস্ত ছোট (<20-30K রেকর্ড) সারণী ডেটা অ্যাপ্লিকেশন স্তরে ক্যাশে করা হয়। অ্যাপ্লিকেশন কোড লেখার সময় এটি জীবনকে আরও শক্ত করে তোলে (লিনকুই লিখতে কষ্টকর), তবে ডাটাবেসটি খুব সুন্দর হয়েছে:

    1. তালিকাগুলি দর্শন - SELECTলোডের উপর কোনও প্রশ্ন উত্পন্ন করবে না (সমস্ত কিছু ক্যাশে করা হয়েছে) বা এর মতো দেখতে কোয়েরিগুলি:

      SELECT allcolumns FROM BigTable WHERE filter1 IN (val1, val2) AND filter2 IN (val11, val12)

      অন্যান্য সমস্ত প্রয়োজনীয় মানগুলি ক্যাশে লকআপের (ও (1)) মাধ্যমে আনা হয়েছে, সুতরাং কোনও জটিল কোয়েরি তৈরি করা হবে না।

    2. দর্শনগুলি সম্পাদনা করুন - এ জাতীয় SELECTবিবৃতি উত্পন্ন করবে :

      SELECT allcolumns FROM BigTable WHERE PKId = value1

(সমস্ত ফিল্টার এবং মানগুলি intহ'ল)


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

উত্তর:


19

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

আমি 2010 থেকে ব্লগ পোস্টে প্রতিটি এক টেবিলটিতে অন্ধভাবে তাদের যুক্ত করার বিরুদ্ধে রেল করছি :

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


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

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

13

আমার অভিজ্ঞতা থেকে, প্রতিটি টেবিলের জন্য পৃথক আইডি ব্যবহারের মূল এবং অপ্রতিরোধ্য কারণগুলি হ'ল:

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

তারপরে, ডিবিএর দৃষ্টিকোণ থেকে, যে জিনিসগুলি ডিবিকে ধীর করে দেয় বা স্ফীত করে তোলে তা অবশ্যই প্রতি সারিতে 4 বাইট (বা যাই হোক না কেন) নয়, তবে ভুল বা অনুপস্থিত সূচী, ভুলে যাওয়া সারণী / সূচী পুনর্গঠন, ভুল র‌্যাম / টেবিলস্পেসের সুরক্ষার প্যারামিটারের মতো জিনিস , বাইন্ড ভেরিয়েবলগুলি ব্যবহার করতে অবহেলা করা ইত্যাদি। এগুলি 10, 100, 10000 ... অতিরিক্ত আইডি কলাম না করে ডিবিটিকে ধীর করতে পারে।

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

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


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

হ্যাঁ, এরকম কিছু, @ আইয়ানআরিংরোজ।
AnoE

6

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

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

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


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

2
প্রশ্নটি সম্ভাব্য অসুবিধার জন্য জিজ্ঞাসা করেছিল, তাই আমার উত্তর। আমি অস্বীকার করি না যে সরোগেট কীগুলি যদি বুদ্ধিমানের সাথে ব্যবহৃত হয় তবে তা বোধগম্য হতে পারে। তবে আমি 3,4,5 (বা আরও অনেক) অর্থহীন বিদেশী কী সহ টেবিলগুলি দেখেছি যার ফলস্বরূপ দরকারী ফলাফল পেতে 3,4,5 বা আরও বেশি যোগদান করে। আরও বাস্তববাদী নকশার জন্য কোনও যোগ দেওয়ার প্রয়োজন হতে পারে না।
এনভিজেল

1
আমি নিশ্চিত নই যে এটি এ জাতীয় অনুসন্ধানগুলির বাস্তবায়ন যা এই ধরণের ডিজাইনের সাথে লোকেরা যে প্রাথমিক সমস্যাটি হয় - এটি সেই ক্যোয়ারির লেখা যা তারা প্রায়শই আপত্তি করে।
ডেভিড আল্ড্রিজে

5

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

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

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

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


2
গাইডগুলির সমস্ত কীগুলি পরিবর্তন করার জন্য ভয়ঙ্কর ন্যায়সঙ্গত বলে মনে হচ্ছে। আমি বর্তমানে এমন একটি ডাটাবেস নিয়ে কাজ করছি যা সমস্ত সরোগেট কীগুলির জন্য গাইড ব্যবহার করে .. এটি মজাদার নয়।
অ্যান্ডি

2
নং জিইউইডি ব্যবহার করা মজাদার নয়। আমি তাদের পছন্দ করি না, তবে নির্দিষ্ট ব্যবহারের ক্ষেত্রে আমি তাদের মানকে সম্মান করি।
CaM

2

একপাশে রাখা:

  • ধর্মীয় যুদ্ধসমূহ (গুগল সারোগেট বনাম প্রাকৃতিক কী)
  • আপনার টেবিলগুলিতে কি ক্লাস্টারযুক্ত সূচিগুলি সংজ্ঞায়িত করা হবে তার পৃথক সমস্যা
  • আপনার সমস্ত ডেটা ক্যাশে করার কার্যকারিতা

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


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

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

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

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

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

2

আপনাকে গাইড করতে সহায়তা করার কয়েকটি কারণ রয়েছে,

  1. সংজ্ঞা এবং অনুমান।

    যদি কোনও কাজকে পদার্থবিজ্ঞানের আইন দ্বারা কোনও অনন্য হিসাবে সংজ্ঞায়িত করা হয় তবে আপনি কোনও সারোগেট কী দিয়ে আপনার সময় নষ্ট করছেন।

  2. অনন্যতা.

    ব্যক্তিগত বিচক্ষণতার জন্য, যোগ দেয় এবং উচ্চ-স্তরের ডাটাবেস কার্যকারিতা আপনার প্রয়োজন হয়, (ক) অনন্য কলাম, (খ) কলামের অনন্য সিরিজ

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

  3. বাস্তবায়ন এবং অপ্টিমাইজেশন।

    কোন ইনট একটি ছোট ডেটা ফর্ম হতে পারে যা তুলনা এবং সমতার জন্য দ্রুত। একটি ইউনিকোড স্ট্রিংয়ের সাথে এর সাথে তুলনা করুন যার কোলেশন স্থানীয় (অবস্থান এবং ভাষা) এর উপর নির্ভরশীল হতে পারে। একটি ASCII / UTF8 স্ট্রিংয়ে একটি 4242 সংরক্ষণ করা 4 বাইট tes এটি একটি পূর্ণসংখ্যা হিসাবে সংরক্ষণ করে এটি 2 বাইটে ফিট করে।

সুতরাং যখন ডাউনসাইডে আসে তখন আপনি কয়েকটি কারণ পেয়েছিলেন।

  1. বিভ্রান্তি এবং অস্পষ্টতা।

    1. @ অ্যারন বারট্র্যান্ড ব্লগ এন্ট্রি এটির পক্ষে যথেষ্ট পরিমাণে। নির্দিষ্টকরণ এবং কার্য দ্বারা অর্ডারআইডি রাখা এবং তারপরে ডাটাবেস বাস্তবায়নের মাধ্যমে একটি " অর্ডারআইডি " চাপানো এটি স্ব-দলিল নয় । কখনও কখনও আপনাকে তা স্পষ্ট করতে বা একটি সম্মেলন তৈরি করতে হয় তবে এতে বিভ্রান্তি বাড়তে পারে।
  2. স্পেস।

    পূর্ণসংখ্যা এখনও সারিতে স্থান যুক্ত করে। এবং, আপনি যদি এগুলি ব্যবহার না করেন তবে কোনও উদ্দেশ্য নেই।

  3. ক্লাস্টারিং।

    আপনি কেবল একভাবে আপনার ডেটা অর্ডার করতে পারেন। যদি আপনি একটি সরোগেট কী চাপান যা প্রয়োজন হয় না, আপনি কি সেভাবে বা প্রাকৃতিক কীটির উপায়ে ক্লাস্টার করেন?


সুন্দর এবং সংক্ষিপ্ত উপকারিতা
আলেক্সি

@ অ্যালেক্সি ধন্যবাদ, আপনি যা খুঁজছেন তা যদি এটি পূরণ করে তবে এটি বেছে নেওয়া হিসাবে চিহ্নিত করার বিষয়টি বিবেচনা করুন। বা, স্পষ্টতা জিজ্ঞাসা।
ইভান ক্যারল 21
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.