প্রাথমিক কীগুলি আপনার ব্যবসায়ের ডোমেনের অংশ নয় এই বিষয়টি সম্বোধন করে

Question

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

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

1. স্পষ্টতই, ডেটা ট্রান্সফার অবজেক্টস (ডিটিও) যেগুলি কেবলমাত্র ডোমেন মডেলের সংমিশ্রণ থেকে প্রাপ্ত তা প্রাথমিক কীগুলি থাকতে পারে না
2. ইনকামিং ডিটিও'র প্রাথমিক কী থাকবে না

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

অন্য কোনও উপায়ে বলা যাক, ডোমেন মডেলগুলিতে পিকে অপসারণের পরে নির্দিষ্ট কোন বিষয় চিহ্নিতকরণের সাথে সম্পর্কিত নীচের সমাধানগুলির মধ্যে কোনটি সঠিক?

1. অন্যান্য বৈশিষ্ট্য দ্বারা আপনার মোকাবেলা করতে প্রয়োজনীয় জিনিসগুলি সনাক্ত করতে সক্ষম হচ্ছেন
2. ডিটিওতে প্রাথমিক কী ফিরে পাওয়া; অর্থাত্, অধ্যবসায় থেকে ডোমেনে ম্যাপিং করার সময় পিকে অপসারণ করা, তারপরে ডোমেন থেকে ডিটিওতে ম্যাপিংয়ের সময় পিকে পুনরায় সমন্বয় করুন?

সম্পাদনা: এই কংক্রিট তৈরি করা যাক।

বলুন আমার ডোমেন মডেল VoIPProviderযা মত ক্ষেত্রগুলি অন্তর্ভুক্ত Name, Description, URL, রেফারেন্স চাই সেইসাথে ProviderType, PhysicalAddressএবং Transactions।

এখন আসুন আমি বলি যে আমি একটি ওয়েব পরিষেবা তৈরি করতে চাই যা সুবিধাপ্রাপ্ত ব্যবহারকারীদেরকে পরিচালনা করতে দেয় VoIPProvider।

সম্ভবত কোনও ব্যবহারকারী-বান্ধব আইডি এই ক্ষেত্রে অকেজো; সর্বোপরি, ভিওআইপি সরবরাহকারীরা হ'ল সংস্থাগুলি যাদের নাম কম্পিউটার বোধে স্বতন্ত্র এবং ব্যবসায়িক কারণে মানবিক অর্থেও যথেষ্ট স্বতন্ত্র to সুতরাং এটি বলা যথেষ্ট যে একটি অনন্য VoIPProviderদ্বারা সম্পূর্ণরূপে নির্ধারিত (Name, URL)। সুতরাং এখন বলি আমার এমন একটি পদ্ধতি প্রয়োজন PUT api/providers/voipযাতে সুবিধাভোগী ব্যবহারকারীরা VoIPসরবরাহকারীদের আপডেট করতে পারেন । তারা একটি প্রেরণ করে VoIPProviderDTO, এতে VoIPProviderসম্ভাব্য কিছু সমতলকরণ সহ অনেকগুলি কিন্তু সমস্ত ক্ষেত্র অন্তর্ভুক্ত নয় । যাইহোক, আমি তাদের মন পড়তে পারি না এবং তাদের এখনও আমাদের জানাতে হবে যে আমরা কোন সরবরাহকারীর কথা বলছি।

দেখে মনে হচ্ছে আমার কাছে 2 টি (সম্ভবত 3) বিকল্প রয়েছে:

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

Comments

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

— তুলিনাস কর্ডোভা

@ ইউজার 18১5৫২ ওআরএম নির্বিশেষে, আপনি সত্যই নিম্ন-স্তরের হলেও, আপনার এখনও ডাটাবেস স্তর বাস্তবায়নের জন্য একটি প্রাথমিক কী প্রয়োজন। সুতরাং আমি সম্মত হই যে সেরোগেট পিকে আপনাকে একটি নির্দিষ্ট অধ্যবসায়িক ব্যবস্থার দ্বারা ব্যবহৃত প্রকৃত পিকে তুলনায় সুবিধা দেয়, তবে যদি সেই পিকে সত্যিকার অর্থে কোনও ব্যবসায়ের অবজেক্টকে অর্থবহ উপস্থাপন করে তবে তা অবশ্যই অনন্য এবং তাই কমপক্ষে একটি অনন্য ব্যবসা-সম্পর্কিত সম্পত্তি নির্ধারণ করে এটা, না?

— tacos_tacos_tacos

সারোগেটের সমস্ত সুবিধা হ'ল কম্পিউটার সম্পর্কিত এবং কোনও মানব-সম্পর্কিত।

— তুলিনাস কর্ডোভা

@ ব্যবহারকারী 61852: আমি 100% সম্মত (আমি কি কিছু আলাদা লিখেছি?) যোগাযোগের মাধ্যমের জন্য একটি "ব্যবসায়িক কী" ব্যবহার করুন। যেকোন ব্যবসায়ের জন্যও অনন্য বাধা যুক্ত করুন। তবে আপনার ডাটাবেস রেফারেন্সগুলি বাস্তবায়িত করতে ব্যবসায়ের কীগুলি ব্যবহার এড়িয়ে চলুন।

— ডক ব্রাউন 15

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

— PSr

Answer 1

এভাবেই আমরা কীভাবে সমাধান করব (১৫ বছরেরও বেশি সময় থেকে, এমনকি "ডোমেন চালিত ডিজাইন" শব্দটিও উদ্ভাবিত হয়নি):

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

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

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

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

Comments

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

— টাকোস_টাকোস_টাকোস

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

— ডক ব্রাউন

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

— ডক ব্রাউন

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

— কেসি

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

— ডক ব্রাউন

Answer 2

কিছু অনন্য সূচক দ্বারা আপনাকে অনেকগুলি বিষয় চিহ্নিত করতে সক্ষম হতে হবে, এবং প্রাথমিক কী কী তা নয় (বা কমপক্ষে বোঝায় যে একটি উপস্থিত রয়েছে)।

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

Comments

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

— tacos_tacos_tacos

সুস্পষ্ট v অন্তর্নিহিত প্রশ্ন একই পার্থক্য নয়? আপনার কাছে এমন একটি পিকে থাকতে পারে যা একাধিক কলাম ছড়িয়ে দেয়, ঠিক অনন্য সূচকের মতো। আমি দেখছি না যে আপনার উদ্দেশ্যে তাদের মধ্যে কোনও পার্থক্য রয়েছে।

— gbjbaanb

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

— tacos_tacos_tacos

আপনি এটি overth سوچ করছি। একটি অনন্য সূচক ডিবি স্কিমার যেমন একটি পিকে হিসাবে ঠিক তেমনি একটি নিদর্শন। এটিকে এভাবে ভাবুন - একটি পিকে হ'ল প্রথম (বা প্রাথমিক) অনন্য সূচক। এটি 'বিশেষ' কারণ আপনার সাধারণত 1 টি সূচক প্রয়োজন।

— gbjbaanb

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

— tacos_tacos_tacos

Answer 3

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

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

Comments

ওয়েল, বার্তা একটি চরম উদাহরণ, কিন্তু তারপর এমনকি আমরা জানতে চাই MessageSender, MessageRecipient, TimeSent- যে অনন্য হওয়া উচিত।

— tacos_tacos_tacos

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

— ক্যাফগিকে

Answer 4

আমরা অ-ব্যবসায় সম্পর্কিত পিকে ব্যবহার করার কারণটি হ'ল ব্যবহারকারী কী চান তা নির্ধারণের জন্য আমাদের সিস্টেমে একটি সহজ এবং ধারাবাহিক পদ্ধতি রয়েছে তা নিশ্চিত করা।

আমি দেখতে পেয়েছি আপনি একটি মন্তব্যে জবাব দিয়েছেন: মেসেজসেন্ডার, বার্তাপ্রেরণকারী, টাইমসেন্ট (একটি বার্তার জন্য)। আপনি এখনও অস্পষ্টতা রাখতে পারেন (উদাহরণস্বরূপ, সিস্টেমের দ্বারা উত্পন্ন বার্তাগুলি এমন কিছু ঘটে যা প্রায়শই ঘটে থাকে)। এবং আপনি কীভাবে এখানে মেসেজসেন্ডার এবং বার্তাপ্রাপ্তিকে বৈধতা দিতে যাচ্ছেন? ধরুন আপনি তাদের ফার্স্টনাম, লাস্টনেম, ডেটঅফবার্থ ব্যবহার করে বৈধ করেছেন, আপনি শেষ পর্যন্ত এমন পরিস্থিতিতে চলে যাবেন যেখানে ঠিক একই নামের সাথে একই দিনে আপনার 2 জন জন্মেছে। আপনি কোনও অবস্থাতেই ছুটে যাবেন যেখানে আপনার একটি বার্তা রয়েছে তা উল্লেখ করার দরকার নেই tacostacostacos-America-1980-Doc Brown-France-1965-23/5/2014-11:43:54.003UTC+200। এটি একটি নামের দৈত্য, এবং এখনও আপনার কোনও গ্যারান্টি নেই আপনার কাছে কেবল এই 1 টি থাকবে।

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

আপনার আইডিটি আপনার ব্যবহারকারীর কাছে দেখানোর দরকার নেই। আপনি এটি ইউআরএল মাধ্যমে লুকিয়ে রাখতে পারেন (প্রয়োজনে সরল দৃষ্টিতে)।

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

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

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

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

Answer 5

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

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

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

আপনার ভিওআইপি উদাহরণে ফিরে যান, বলুন যে কোনও ভিওআইপি সরবরাহকারী (ভিওআইপিপ্রাইডারআইডি) বা (নাম, ইউআরএল) বা (জিইউইডি) দ্বারা নির্ধারিত হতে পারে। যখন কোনও বাহ্যিক সিস্টেমে ভিওআইপি সরবরাহকারীর আপডেট করার দরকার হয়, তখন এটি কেবল একটি পিইউটি / সরবরাহকারী / বাই-আইডি / 1234 বা পাস করতে পারে PUT /provider/foo-voip/bar-domain.comবা PUT /3F2504E0-4F89-41D3-9A0C-0305E82C3301আপনার সিস্টেম বুঝতে পারে যে বহিরাগত সিস্টেম ভিওআইপিপ্রাইডার আপডেট করতে চায়। এই ইউআরআইগুলি আপনার সিস্টেম দ্বারা উত্পাদিত হয় এবং কেবলমাত্র আপনার সিস্টেমে বুঝতে হবে যে সেগুলি একই জিনিস means বাহ্যিক ব্যবস্থার কেবল ইউআরআইতে যা আছে তা মূলত একটি হিসাবে বিবেচনা করা উচিত PUT <whatever>।

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

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

Answer 6

আমি এই বুনো ভুল এবং নির্ভুল বিবৃতি লক্ষ্য করতে যাচ্ছি:

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

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

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

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

রেফারেন্সের জন্য, আমি পছন্দ করি কীভাবে জাঙ্গো এটি পরিচালনা করে:

class VoipProvider(models.Model):
    name=fields.TextField()
    address=fields.TextField()

class Customer(models.Model):
    name=fields.TextField()
    address=fields.TextField()
    voipProvider=fields.ForeignKeyField(VoipProvider)

এইভাবে, কোনও গ্রাহকের সরবরাহকারীর বিবরণ ব্যবহার করে কোড অ্যাক্সেস করতে পারে:

myCustomer.voipProvider.name #returns the name of the customers VOIP Provider.

প্রাথমিক / বিদেশী কীগুলি দৃশ্যমান না থাকলেও সেগুলি রয়েছে এবং আইটেমগুলি অ্যাক্সেস করতে ব্যবহার করা যেতে পারে তবে এগুলি বিমূর্ত করা হয়।

Comments

আপনি একেবারে সঠিক, তবে আমি অনুমান করি যে আমার অর্থ হ'ল "কিছু ডোমেইনে, সম্ভবত মূল্যবোধগুলির একটি প্রাকৃতিক টুপল থাকে যা সর্বদা অনন্য" যদি তারা পরিবর্তন হয় তবে তারা এখনও অনন্য, তারা এখনও একটি একক রেকর্ড সনাক্ত করে।

— tacos_tacos_tacos

Answer 7

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

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

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

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