ডেটাবেস সাধারণকরণ বনাম স্কিমা স্বচ্ছতা পছন্দ করছেন?

Question

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

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

বিমূর্ততাটি পরিষ্কার করার জন্য, পৃথক ব্যবহারকারী ডেটার তিনটি গ্রুপ বিবেচনা করুন: অধ্যাপক, প্রশাসন, শিক্ষার্থীরা (না, এটি কোনও হোমওয়ার্কের কাজ নয় Prom প্রতিশ্রুতি!)

ম্যাপিং ঘ

(অধ্যাপক_আইডি, প্রশাসক_আইডি এবং ছাত্র_আইডি হ'ল তাদের নিজ নিজ সারণীর বিদেশী কী)

| mailing_id (KEY) | professor_id | admin_id | student_id | 
-------------------------------------------------------
| 1001             |     NULL     |    87    |  NULL      |
| 1002             |     123      |   NULL   |  NULL      |
| 1003             |     NULL     |   NULL   |  123       |

এই পদ্ধতির পক্ষে +/- এই ধারণাটি খুব ভারী মনে হচ্ছে:

• প্রতি সারিতে দুটি "নষ্ট" ক্ষেত্র
• লঙ্ঘন 2NF
• অসঙ্গতিগুলি সন্নিবেশ করা / আপডেট করা ক্ষতিগ্রস্থ (কেবলমাত্র 0-1 ক্ষেত্র সেট ন্যূনাল, যেমন একটি সারি)

উপকারগুলি তাদের নিজস্ব যোগ্যতা ছাড়া নয়, যদিও:

• ম্যাপিংটি একক অনুসন্ধানের সাথে সম্পন্ন করা যায়
• মেলিং_আইড থেকে কোনও প্রদত্ত ব্যবহারকারীর জন্য সহজেই "উত্স" ডেটা নির্ধারণ করুন

সত্য বলা উচিত, আমার অন্ত্রে, আমি এই ধারণা মোটেও পছন্দ করি না।

ম্যাপিং 2

(ধরুন এমএসজি_ * সংজ্ঞায়িত ধ্রুবক, এনামের ধরণ বা অন্য কোনও উপযুক্ত শনাক্তকারী)

| mailing_id (KEY)  | user_type (UNIQUE1) | internal_id (UNIQUE2)| 
------------------------------------------------------------------
| 1001              | MSG_ADMIN          | 87                    |
| 1002              | MSG_PROF           | 123                   |
| 1003              | MSG_STUDENT        | 123                   |

এই সেটআপটি এবং {ব্যবহারকারীর_প্রকার, অভ্যন্তরীণ_আইডি} বিষয়গুলির একটি অনন্য সমন্বিত সূচক দিয়ে 3NF রক্ষণাবেক্ষণ করা হয়, এবং অ্যাপ্লিকেশন কোডটি I / U ব্যতিক্রমগুলি পরীক্ষা করতে হয় না।

ডাউনসাইডে, ব্যবহারকারীর উত্স সারণীগুলি নির্ধারণে স্বচ্ছতার কিছুটা ক্ষতি আছে যা ডিবি এর বাইরে পরিচালনা করতে হয়, মূলত ব্যবহারকারীর_তাই মানগুলির টেবিলে মান প্রয়োগের স্তরের ম্যাপিংয়ের পরিমাণ হিসাবে। এই মুহুর্তে, আমি (বরং দৃ rather়ভাবে) এই ২ য় ম্যাপিংয়ের দিকে ঝুঁকছি, যেহেতু ডাউনসাইডটি সামান্য।

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

Comments

আপনি মার্টিন ফাউলারের মতামতগুলি ভূমিকা সম্পর্কে আকর্ষণীয় পঠন করতে পারেন।

— মার্জন ভেনেমা

এটি ছিল সত্যই আকর্ষণীয়। দুঃখজনকভাবে আমার নির্দিষ্ট সমস্যাটির জন্য খুব বেশি অন্তর্দৃষ্টি নয়

— জেমিনিডমিনো

আপনি এমন অধ্যাপক পেতে যাচ্ছেন যারা প্রশাসক হয়ে ওঠেন এবং প্রশাসনে চাকরি পাওয়া শিক্ষার্থীরা বা এমনকি 10 বছর পরে অনুষদ হিসাবে ফিরে আসেন। আপনি সম্ভবত ইতিমধ্যে তাদের আছে। আপনি কি তাদের আলাদা রাখতে যাচ্ছেন বা একত্রিত করার চেষ্টা করছেন?

— এলিন

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

— জেমিনিডমিনো

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

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

Answer 1

আপনার দ্বিতীয় ধারণাটি সঠিক। এই পদ্ধতির সাহায্যে আপনার তিনটি সংঘর্ষমূলক কী স্পেস একীভূত করার জন্য আপনাকে যে সমস্ত ম্যাপিং করতে হবে তা সমস্ত করতে দেয়।

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

আপনার কাছে ইতিমধ্যে আপনার চেয়ে বেশি কোড রয়েছে, সুতরাং আপনার সংহত কী তালিকাকে সামঞ্জস্য রাখতে একেবারে প্রয়োজনের চেয়ে বেশি কোড যুক্ত করবেন না। আপনার ডাটাবেস ইঞ্জিনটি এটি করার জন্য নির্মিত হয়েছিল do

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

আপনার সাব-অ্যাপ্লিকেশনগুলিতে যে ম্যাপিংটি ব্যবহার করা দরকার সে কোডটি USER_TYPEপ্রতিটি উপ-অ্যাপ্লিকেশনটিকে এমন একটি ভিউ প্রদানের মাধ্যমে সহজেই অজানা হতে পারে যা ম্যাপিংগুলিকে একটি অ্যাপ্লিকেশন-নির্দিষ্ট ব্যবহারকারী প্রকারে ফিল্টার করে।

Answer 2

অভিজ্ঞতা থেকে আমার সুপারিশ হ'ল কমনীয়তা বা 'সেরা অনুশীলন' এর চেয়ে ধারাবাহিকতা বেছে নেওয়া। এটি বিদ্যমান নকশার সাথে মেলে এবং তিনটি মেলিং টেবিল (প্রতিটি ভূমিকার জন্য একটি) একটি সাধারণ mailing_id, user_idক্ষেত্র কাঠামোর সাথে যেতে।

এটি অবিচল কিন্তু এর কয়েকটি সুবিধা রয়েছে ...

1. এই কাঠামোটি চারণভূমিতে রাখার আগেই এই স্কিমায় কাজ করবে এমন যে কেউ এর জন্য বিদ্যমান কাঠামোর সাথে মিল পাওয়া সহজ।
2. আপনার কোনও নষ্ট ক্ষেত্র নেই এবং আপনি ডিবিকে এমন জিনিসগুলির সাথে মেলে না যা জিজ্ঞাসা করছেন না that
3. কারণ প্রতিটি টেবিল কেবল অন্য একে অপরের সাথে থাকবে এবং এমন একটি দৃষ্টিভঙ্গি তুলনামূলক সহজ হবে যা আপনার রুটিনগুলি ব্যবহারের জন্য সমস্ত ডেটা যুক্ত করে।

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

Comments

এই পদ্ধতির সাথে সমস্যাটি হ'ল ডেটাবেস মেলিং আইডিতে স্বতন্ত্রতা প্রয়োগ করতে পারে না, যা ম্যাপিংয়ের প্রাথমিক লক্ষ্য প্রথম স্থানে: অন্যথায়, "ব্যবহারকারীর" সূচক সহ প্রতিটি টেবিলের থেকে পৃথক আইডি ক্ষেত্রগুলি যুক্ত করা যেতে পারে otherwise কোন পরিবর্তন ছাড়াই সম্পন্ন।

— জেমিনিডমিনো

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

— জেমস স্টেল

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

— মিথুনোডমিনো