কোনও বস্তুর নিজের আইডি জানা উচিত?

Question

obj.idমোটামুটি সাধারণ বলে মনে হয় এবং এটি কোনও জিনিস নিজের সম্পর্কে জানতে পারে এমন কিছু সীমার মধ্যে পড়ে বলে মনে হয়। আমি নিজেকে জিজ্ঞাসা করি যে কেন আমার বস্তুর নিজস্ব আইডি জানা উচিত?

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

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

কোনও বস্তুর নিজের আইডিটি জানা উচিত? কেন অথবা কেন নয়?

আপডেট : শর্তাদি

1. আইডি: একটি বস্তুর শনাক্তকারী বৈশিষ্ট্য। ডাটাবেসের শর্তে একটি সরোগেট কী কোনও প্রাকৃতিক কী নয়।
2. অবজেক্ট: একটি সত্তা, বা অন্যথায় সিস্টেমের মধ্যে স্বতন্ত্ররূপে সনাক্তযোগ্য বস্তু।

Comments

বিমূর্ত থাকার জন্য, যদি তথ্য সংরক্ষণ করার কোনও কারণ না থাকে তবে এটি সংরক্ষণ করবেন না। এটি কেবল মাথাব্যথা তৈরি করে।

আপনি যদি কোনও অবজেক্টের অনন্য কী জানেন না তবে আপনি কীভাবে কোনও ডাটাবেজে ডেটা আপডেট করবেন বা ব্যবহারকারীকে কোনও তালিকা থেকে কোনও ঘটনা নির্বাচন করতে দেবেন?

— NoChance

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

— xenoterracide

আপনি যদি অবজেক্টের সাথে সঞ্চিত আইডি ব্যবহার না করেন এবং কখনই এটির উদ্দেশ্য বা ব্যবহার করতে চান না, তবে এর স্পষ্ট প্রয়োজন নেই।

— গ্র্যান্ডমাস্টারবি

@ গ্র্যান্ডমাস্টারবি অবশ্যই আপনি আইডিটি ব্যবহার করেন, প্রশ্নটি হ'ল আপনি আইডিটি মেমরিটিতে বস্তুর সাথে সঞ্চয় করেন এবং কেন।

— xenoterracide

Answer 1

সংক্ষিপ্ত উত্তর: যদি বিষয়টি উল্লেখ করা হয় তবে অবজেক্টের মধ্যে অবজেক্ট আইডেন্টিফায়ারটি অন্তর্ভুক্ত করা আবশ্যক।

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

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

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

Comments

কেন সেগুলি কেবল সংগ্রহের পরিবর্তে অবজেক্টে অন্তর্ভুক্ত করা উচিত (সংগ্রহটি কোনও ধরণের অভিধান হিসাবে ধরে নেওয়া)?

— xenoterracide

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

— EL Yusubov

অবশ্যই, আমার প্রশ্নটি কেন সেই বিষয়টিকে নিজেই সেই শনাক্তকারী সম্পর্কে সচেতন হওয়া দরকার of

— xenoterracide

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

— xenoterracide

Answer 2

আমার উত্তরটিকে আপনার প্রশ্নের মতো বিমূর্ত হিসাবে রেখে যাওয়ার প্রয়াসে, আমি মনে করি আপনি নিজের প্রশ্নের উত্তর দিয়েছেন।

কোনও বস্তুর প্রয়োজন হলে তার নিজস্ব আইডি জানা উচিত।

কোনও জিনিসের প্রয়োজন না থাকলে তার আইডি (বা এটির একটিও রয়েছে) জানা উচিত নয়।

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

Comments

এটির আইডি সম্পর্কে সচেতন হওয়া কোন ক্ষেত্রে সুবিধাজনক? আমি এটি ভাবছিলাম এবং ভেবেছিলাম যে তাদের বেশিরভাগই কেবল কোড করা হয়েছিল তার উপর ভিত্তি করেই হতে পারে, সম্ভবত লুপের জন্য obj.idসংগ্রহটি নিজেই রেন্ডারিংয়ের বিপরীতে রেন্ডার করত used

— xenoterracide

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

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

— xenoterracide

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

Answer 3

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

উদাহরণস্বরূপ, আপনি যদি দুটি পদ্ধতি সহ একটি API তৈরি করে থাকেন:

• http://api.example.com/products/

  পণ্যের আইডির তালিকা লোড করে।

• http://api.example.com/product/452/

  452 আইডি পণ্য লোড করে।

তারপরে আপনার দ্বিতীয় অনুরোধের জেএসওএন প্রতিক্রিয়াতে আইডি 452 পুনরায় পাঠাতে হবে না। এপিআই এর ব্যবহারকারী ইতিমধ্যে আইডি জানেন।

Answer 4

আমি মনে করি এটি বিষয়গত এবং আপনার নকশার উপর নির্ভর করে।

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

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

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

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

সমস্ত সাধারণ আইডি হ'ল সিস্টেমে সারোগেট কীগুলি রয়েছে এবং মেমরি রেফারেন্সে প্রতিস্থাপন করা যেতে পারে, কেবল আইডি এর সন্ধান করা এবং রেকর্ডগুলি সহজতর করার জন্য containing

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

সফ্টওয়্যারটিতে যদি আপনাকে অবজেক্টটিকে একটি তালিকা হিসাবে প্রতিনিধিত্ব করতে বা এটি অবিরত রাখতে হয় তবে আপনি কেবল সংগ্রহস্থল / সংগ্রহ অবজেক্ট বা এর সাথে যুক্ত অন্য কোনও অবজেক্ট থেকে এটি করতে পারেন। ডেটা ম্যাপারে যাওয়ার সময় (এটি পৃথক হলে), আপনি কেবল পাস করতে পারেন .update( id, obj )।

দাবি অস্বীকার : আমি এখনও এমন একটি সিস্টেম তৈরির চেষ্টা করিনি যা সত্তার মধ্যে আইডি ধারণ করে না এবং এভাবে নিজেকে ভুল প্রমাণ করতে পারে।

Answer 5

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

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

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

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

Answer 6

আপনি ঠিক বলেছেন, আইডিটি অবজেক্টে সংরক্ষণ করার দরকার নেই, যতক্ষণ না আপনার এটি কেবল আপনার সংগ্রহস্থল প্রসঙ্গে জেনে রাখা দরকার।

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

এই পরিস্থিতিতে আপনার কাছে দুটি বিকল্প রয়েছে:

• সংগ্রহস্থল প্রসঙ্গ এবং আইডি প্রয়োজন যেখানে ফাংশন মধ্যে পুরো ফাংশন একটি নতুন ফাংশন আর্গুমেন্ট 'আইডি' প্রবর্তন

• আইডিটি অবজেক্টে অন্তর্ভুক্ত করুন

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

এজন্য আমি যখন এটি করি তখনই করি।