কেন অনেক ডিজাইন আরডিবিএমএসে সাধারণীকরণ উপেক্ষা করে?


23

আমি অনেকগুলি ডিজাইন দেখতে পেলাম যে সিদ্ধান্ত গ্রহণের পর্যায়ে সাধারণীকরণ প্রথম বিবেচনা নয়।

অনেক ক্ষেত্রে এই নকশাগুলিতে 30 টিরও বেশি কলাম অন্তর্ভুক্ত ছিল এবং মূল পদ্ধতির "সমস্ত কিছু একই জায়গায় করা" ছিল

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

সম্পাদনা:

অভিজ্ঞ-অভিজ্ঞ বিকাশকারীরা বিপরীতটি বেছে নেওয়ার সময় কী স্থপতি এবং বিশেষজ্ঞরা একটি অস্বীকৃত নকশাকে বেছে নেন? আপনার নকশাটি সাধারণীকরণকে সামনে রেখে শুরু করার বিরুদ্ধে কী যুক্তি রয়েছে?


7
কারণ সাধারণীকৃত ডিবি এমনকি অতি তুচ্ছ প্রশ্নের সাথেও অনেকগুলি যোগদানের প্রয়োজন
রাচেট ফ্রিক

1
যারা যোগদান করবে তাদের এখনও ভিউ দ্বারা লুকিয়ে থাকা প্রয়োজন হবে
ratchet freak

29
অনেক প্রোগ্রামার রিলেশনাল মডেলের বেসিকগুলি জানেন না।
মাইক 30

10
"এটি ব্যথা না হওয়া পর্যন্ত সাধারণকরণ করুন, এটি কাজ না করা পর্যন্ত অস্বীকৃতি জানান"। codinghorror.com/blog/2008/07/… এর কিছু ভাল উত্তর রয়েছে।
ম্যাথু স্টেপলস

3
তারা এটিকে এড়িয়ে যান কারণ তাদের ডিবিএ, বিআই বিশ্লেষক বা সুরক্ষা নিরীক্ষকদের জবাব দিতে হবে না।
অ্যারোনআউট

উত্তর:


19

এই প্রশ্নোত্তর থ্রেড সম্পর্কে আকর্ষণীয় হ'ল আসলে 3 টি প্রশ্ন রয়েছে। প্রত্যেকেই আলাদা আলাদা উত্তর দিয়েছে এবং প্রায় কেউই প্রথমটির উত্তর দেয়নি:

  1. বন্যের কিছু উপাত্ত কেন সাধারণ করা হয় না ?
  2. কেন / কখন একটি সাধারণীকরণ করা ডাটাবেসকে অস্বীকৃত করা উচিত ?
  3. কোন পরিস্থিতিতে প্রথমে স্বাভাবিক হওয়া ক্ষতিকারক বা অপ্রয়োজনীয়?

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

এছাড়াও, এই উত্তরে আমি ধরে নিচ্ছি যে "নরমালাইজেশন" বলতে "বিসিএনএফ, 3 এনএফ, বা কমপক্ষে 2 এনএফ " বোঝায় , যেহেতু ডিজাইনাররা সাধারণত সাধারনতার যে স্তরটি অর্জন করেন। এটি 4NF বা 5NF ডিজাইন দেখতে বিরল; যদিও তারা অবশ্যই অসম্ভব লক্ষ্য নয়, তারা কেবল তাদের প্রতিনিধিত্বের চেয়ে সম্পর্কের শব্দার্থতত্ত্ব নিয়ে নিজেদের চিন্তিত করে , যার জন্য ডোমেন সম্পর্কে যথেষ্ট বেশি জ্ঞান প্রয়োজন।

সুতরাং, এগিয়ে এবং wardর্ধ্বমুখী:

1. বন্যের কিছু উপাত্ত কেন সাধারণ করা হয় না?

এর উত্তর হতে পারে "কারণ তাদের হওয়া উচিত নয়", তবে ব্যাট হাতে ঠিকই ধরে নেওয়া অনুমান করা বেশ প্রসন্ন-দরিদ্র গোয়েন্দা কাজ। আমরা যদি সর্বদা এই ধারণাটি নিয়ে চালিত থাকি যে আমরা যা হ'ব তা হওয়া উচিত, আমরা সমাজ হিসাবে খুব বেশি অগ্রগতি করব না।

প্রথম স্থানে ডাটাবেসগুলি স্বাভাবিক না হওয়ার আসল কারণগুলি আরও জটিল। এখানে শীর্ষ 5 রয়েছে যা আমি এসেছি:

  • বিকাশকারী যারা পরিকল্পিত এটা জানেন না বা বুঝতে পারে না কিভাবে স্বাভাবিক করবে। এর দৃ evidence় প্রমাণগুলি অন্যান্য অনেকগুলি সাথে খারাপ নকশার পছন্দগুলির মতো আকারে আসে, যেমন সমস্ত কিছুর জন্য ভারচার কলাম ব্যবহার করা বা অর্থহীন টেবিল এবং কলামের নামগুলির স্প্যাগেটি জগাখিচুড়ি থাকা । এবং আমি আপনাকে আশ্বস্ত করি, আমি "বাস্তব" ডাটাবেসগুলি দেখেছি যা টিডিডাব্লুটিএফ নিবন্ধগুলির মতো যতটা খারাপ।

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

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

  • ডাটাবেসটি মূলত স্বাভাবিক ছিল , তবে দীর্ঘ সময় এবং / অথবা একটি বিস্তৃত বিতরণকারী দল নকলের সূক্ষ্ম ফর্মগুলি প্রবর্তন করে এবং সাধারণ ফর্মটি মূলত যা ছিল তার অন্যান্য লঙ্ঘনের সূচনা করে। অন্য কথায়, সাধারণীকরণের ক্ষতি দুর্ঘটনাক্রমে , এবং রিফ্যাক্টরিংয়ে খুব কম সময় ব্যয় করেছিল।

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

২. কেন / কখন একটি সাধারণীকরণ করা ডাটাবেসকে অস্বীকৃতি জানানো উচিত?

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

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

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

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

৩. কোন পরিস্থিতিতে প্রথমদিকে স্বাভাবিক হওয়া ক্ষতিকারক বা অপ্রয়োজনীয়?

বাস্তবে এখানে বেশ কয়েকটি ভাল উদাহরণ রয়েছে:

  • ডাটাবেসটি যদি কেবল রিপোর্টিং / বিশ্লেষণের জন্য ব্যবহৃত হয় । সাধারণত এটি বোঝায় যে ওলটিপি-র জন্য একটি অতিরিক্ত , সাধারণীকৃত ডাটাবেস ব্যবহৃত হচ্ছে যা পর্যায়ক্রমে ইটিএল বা বার্তাপ্রেরণের মাধ্যমে বিশ্লেষণ ডাটাবেসে সিঙ্ক্রোনাইজ করা হয়।

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

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

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

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

এবং খুব শেষ প্রশ্নের উত্তর দিতে:

অভিজ্ঞ-অভিজ্ঞ বিকাশকারীরা বিপরীতটি বেছে নেওয়ার সময় কী স্থপতি এবং বিশেষজ্ঞরা একটি অস্বীকৃত নকশাকে বেছে নেন? আপনার নকশাটি সাধারণীকরণকে সামনে রেখে শুরু করার বিরুদ্ধে কী যুক্তি রয়েছে?

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

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


1
আপনার এটি কোনও ব্লগ নিবন্ধে অনুলিপি করা উচিত ... এটি গোল্ড।
মার্সেল পপেস্কু

15

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

সাধারণকরণ আপনাকে কয়েকটি মূল সুবিধা দেয়:

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

এটি বলেছিল, অস্বীকৃতি জানাতে প্রচুর বৈধ কারণ রয়েছে:

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

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

উপরের মন্তব্যে জেফ অ্যাটউডের নিবন্ধটি কিছু ভাল বিস্তারিত আলোচনা প্রদান করেছে - "সম্ভবত নরমালাইজিং ইজ নরমাল নয়"


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

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

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

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

1
এবং # 2 যুক্তিসঙ্গত বলে মনে হচ্ছে তবে বাস্তবে বিশ্বাসযোগ্যতার উপর চাপ পড়ে - আমার 10+ বছরে এমন এক নজির দেখে মনে থাকতে পারে না যেখানে অ্যাপ্লিকেশন দ্বারা সীমাবদ্ধতাগুলি আসলে পুরোপুরি প্রয়োগ করা হয়েছিল। আবার অনেক সময়, ডেভেলপারদের পারেন তথ্য অখণ্ডতা থেকে ভুল সমার্থক ব্যবসার নীতি বা সত্য যে ORMs তাত্ত্বিক ব্যবহার করতে পারেন একটি অজুহাত হিসাবে রিলেশনাল সীমাবদ্ধতার জোরদার সব সময়ে যে কোন স্থানে এটা করতে না। হতে পারে আমি কেবল কট্টর হই, তবে আমার সমস্ত কেরিয়ারের অভিজ্ঞতা আমাকে শিখিয়েছে যে "অ্যাপ্লিকেশন ডেটার অখণ্ডতা প্রয়োগ করবে" এর মতো বিবৃতিগুলি প্রচুর লাল পতাকা রয়েছে।
অ্যারোনআউট

11
  1. প্রচুর বিকাশকারীরা সাধারণীকরণ, বা ডেটা মডেলিং বা ডাটাবেস সম্পর্কে জানেন না বা যত্ন করেন না।
  2. কিছু কাজের ক্ষেত্রে এটি গুরুত্বপূর্ণ নয়।
  3. কখনও কখনও ডি-নরমালাইজ করার সত্যিই ভাল কারণ থাকে, যেমন কোনও নির্দিষ্ট কাজের চাপকে ভালভাবে সম্পাদন করা।
  4. ১৯৯০ ও ২০০০ এর দশকের তুলনায় রিলেশনাল ডেটাবেস ধারণাগুলি ফ্যাশনে সম্প্রতি কম। বিকাশকারীরা ফ্যাশন দ্বারা প্রভাবিত হতে থাকে, এমনকি তারা খুব যুক্তিযুক্ত বলে দাবি করে। স্বাদ নিয়ে বিতর্ক করার কোনও মানে নেই।

সাধারণীকরণ হ'ল Norতিহাসিকভাবেও, ধর্মীয় যুক্তির নিকটবর্তী অঞ্চল, তাই আমি আরও কিছু বলতে দ্বিধা বোধ করি।


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

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

@ জোশপ - ধন্যবাদ, চমৎকার সারসংক্ষেপ পয়েন্ট # 3 হ'ল আমি ব্যক্তিগতভাবে আরও আগ্রহী other অন্য কারণগুলি কেন সাধারণীকরণের প্রয়োজনীয়তা "বীট" করে do
ইয়োসি দাহারী

@ জিমিশেল্টার আমি সম্মত ফ্যাশন একপাশে, সম্পর্কের সবসময় সেরা পছন্দ হয় না।
জোশপ

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

9

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

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

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

ডাটাবেস ডিজাইনের ত্রুটিগুলি এড়ানো শক্ত না হয় যদি না আপনি সেগুলি সন্ধান করেন বা পরীক্ষার সময় আপনি সেগুলির মুখোমুখি হন না। ডাটাবেস ডিজাইনের মানের কোনও মান না থাকার ফলে ত্রুটিগুলি আরও বেশি ঘটে happen

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


আপনি কি ডাটাবেস ডিজাইনের মান (কেবলমাত্র স্কিমা নয়, পদ্ধতিগুলি) নথি / নিবন্ধগুলিও প্রস্তাব করতে পারেন?
তিলক

"একটি একক টেবিলে অনেকগুলি কলাম থাকা সাধারণীকরণের বিরুদ্ধে যায় না" - সুরক্ষা Mআমাদের উদ্দেশ্য ছিল # দন্তরীতির। যে প্রশ্নে আমি # কলামগুলি কেবল সরলতার জন্য উল্লেখ করেছি, আমার ধারণাটি ছিল পাঠক পারস্পরিক সম্পর্ক বুঝতে পারবেন এবং তার অর্থ আমি কী বোঝাতে চাইছি
ইয়োসি দাহারী

@ তিলাক, আমি নিশ্চিত নই যে এর থেকে সেরা দিকনির্দেশনা পাওয়ার জন্য কোনও নির্দিষ্ট রেফারেন্স রয়েছে কিনা তবে আপনি ডাটা মডেলিং এবং ডাটাবেস ডিজাইন সাহিত্য থেকে আপনার তালিকা সংগ্রহ করতে পারেন। এটি যদি আপনার প্রশ্নের উত্তর না দেয় তবে দুঃখিত। আমি মনে করি এটি কোনও বইয়ের জন্য ভাল বিষয় হতে পারে।
NoChance
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.