ব্যবহারকারী এবং ব্যবহারকারী প্রোফাইলকে বিভিন্ন টেবিলে রাখবেন?

Question

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

Comments

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

@ মিশেলটি ধন্যবাদ! আকর্ষণীয় যে সমস্ত লিঙ্কযুক্ত প্রশ্নে noক্যমত্য নেই।

— অ্যান্ড্রে

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

@ মিশেলটি আমি ধরণের সাধারণ কাঠামো তৈরির কথা ভাবছি যা ব্যবহারকারীর মডেল সরবরাহ করবে।

— অ্যান্ড্রে

পূর্ববর্তী কয়েকটি প্রকল্পে আমি উদ্দেশ্যমূলকভাবে কলামগুলি সরিয়ে নিয়েছি যা ডাটাবেস ফাইলটি ক্ষতিগ্রস্থ বা ক্ষতিগ্রস্থ হলে প্রাথমিক টেবিলটি সুরক্ষার উদ্দেশ্যে তাদের নিজস্ব পৃথক টেবিলগুলিতে খুব ঘন ঘন লিখিত হবে বলে আশা করা হয়েছিল।

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

Answer 1

এটি আপনার প্রকল্পের আকার এবং প্রয়োজনীয়তার উপর নির্ভর করে।

আমি একটি উপায়ে দেখতে পাচ্ছি যার মাধ্যমে ব্যবহারকারীদের সম্পর্কে ডেটা বিভিন্ন উদ্দেশ্যে এবং এইভাবে প্রয়োজনীয়তার সাথে দুটি সেটে বিভক্ত করা যেতে পারে:

• পরিচয়ের ডেটা: ব্যবহারকারীর নাম, পাসওয়ার্ড হ্যাশ, ইমেল ঠিকানা, শেষ লগইন সময় ইত্যাদি
• ব্যবহারকারীর প্রোফাইল ডেটা, যাতে ব্যবহারকারীর পছন্দসমূহ, সর্বশেষ ক্রিয়াকলাপ, স্থিতি আপডেট ইত্যাদি অন্তর্ভুক্ত থাকে

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

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

সুতরাং, সাধারণত তথ্য দুটি ধরণের সিস্টেমে সংরক্ষণ করা হয়:

• পরিচয় ডেটা সাধারণত কোনও ডিরেক্টরি বা আইএএম সমাধানে যায়।
• পছন্দের ডেটা একটি ডাটাবেসে শেষ হবে in

এটি বলার পরে, বাস্তবে, লোকেরা এই বিধিগুলি লঙ্ঘন করবে এবং একটি বা অন্যটি ব্যবহার করবে (যেমন এসপিএএনটি সদস্যতার সরবরাহকারীর পিছনে এসকিউএল সার্ভার)।

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

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

আরও তথ্যের জন্য, পরিচয় ডিরেক্টরি বনাম ডাটাবেসে কয়েকটি অনুসন্ধান সাহায্য করবে।

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

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

Answer 2

একে অপরের সাথে সম্পর্কের সাথে অন্যান্য বৈশিষ্ট্যের জন্য মৌলিক বৈশিষ্ট্যের জন্য কোনও ব্যক্তির টেবিল এবং দ্বিতীয় টেবিল থাকার ক্ষেত্রে কমপক্ষে তিনটি ক্ষেত্রে কাম্য:

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

আমি মনে করি আপনি যে কেসটি প্রকাশ করবেন সেটি দ্বিতীয় মামলার মধ্যে ফিট করে।

Answer 3

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

ব্যবহারকারী শ্রেণি (এবং সংযুক্তির দ্বারা ব্যবহারকারী সারণি) প্রায়শই সারণী হয় যা শত শত বৈশিষ্ট্য / ক্ষেত্র, কয়েক ডজন বা শত শত পদ্ধতি এবং 1000 এরও বেশি লাইনের শ্রেণি সংজ্ঞা (পদ্ধতিগুলির জন্য) দিয়ে classশ্বর শ্রেণিতে পরিণত হয়। আমি এটার সব দেখেছি. একবারের বেশী.

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

Comments

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

— অ্যান্ড্রি