এটি কোনও ডিবি স্কিমা গঠনের একটি হাস্যকর উপায়, বা আমি কোনও কিছু পুরোপুরি অনুপস্থিত?


61

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

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

ব্যবহারকারী সারণী:

UserID (primary Key, indexed, no dupes)
FirstName
LastName
Department

অনুরোধ সারণী

RequestID (primary Key, indexed, no dupes)
<...> various data fields containing request details
UserID -- foreign key associated with User table

সরল, তাই না?

পরামর্শদাতা এটির মতো নকশা করেছেন (নমুনা ডেটা সহ):

UsersTable

UserID  FirstName   LastName
234     John        Doe
516     Jane        Doe
123     Foo         Bar

DepartmentsTable

DepartmentID   Name
1              Sales
2              HR
3              IT

UserDepartmentTable

UserDepartmentID   UserID   Department
1                  234      2
2                  516      2
3                  123      1

RequestTable

RequestID   UserID   <...>
1           516      blah
2           516      blah
3           234      blah

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

এই সমস্ত টেবিলের রেফারেন্সটি অতিক্রম করার জন্য তাঁর কাছে প্রচুর পরিমাণে সঞ্চিত প্রক্রিয়া রয়েছে।

একটি ছোট থেকে মাঝারি আকারের এসকিউএল ডিবি এর জন্য এই বৈধ নকশাটি কি?

মন্তব্য / উত্তরের জন্য ধন্যবাদ ...


12
ওহ ছেলে, যদি এটি আপনাকে ডব্লিউটিএফ বলতে বাধ্য করে, তবে আপনি সম্ভবত 200+ কলাম সহ সারণী এবং 1000 লাইনের বেশি দীর্ঘ সংগ্রহের পদ্ধতি দেখতে পাবেন না have
কাজ

42
বিব্রত বোধ করার পরে মোছা না করার জন্য +1। এটি ছেড়ে দেওয়ার জন্য ধন্যবাদ যাতে অন্যরা শিখতে পারে।
ওয়েইন কোর্টস

2
@ জোব - আসলে, আমি তা করি নি - আমি বাণিজ্যের দ্বারা ডিবিএ নই (এখনই বেশ স্পষ্টভাবে! LOL), সুতরাং আমার এসকিউএল ডাব্লুটিএফের প্রান্তিকতা মোটামুটি কম। যদিও, আমার পরামর্শদাতার ডিজাইনের বিন্দুটি পুরোপুরি অনুপস্থিত হওয়ায় আমাকে আমার নিজস্ব দক্ষতা ডাব্লুটিএফ'ই করা হয়েছে। এমন কোনও দিন আছে যেখানে আপনি কেবল বোবা অনুভব করেন ?
জিম

9
@ জিম: অভিনন্দন, আপনি একটি বোবা দিনকে আলোকিত দিনে পরিণত করেছেন।
ওয়েইন কোর্টস

3
অভিশপ্ত যারা উচ্চ বেতনভোগী পরামর্শদাতাদের!
ডেভিডস

উত্তর:


73

আমার নিখুঁত জ্ঞান করে তোলে। এটি কেবলমাত্র খুব স্বাভাবিক করা হয়েছে, যা আপনাকে প্রচুর পরিমাণে নমনীয়তা দেয় যা আপনার অন্যথায় না হয়। ডি-নরমালাইজড ডেটা হ'ল বাটের ব্যথা।


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

দশ মিনিটের নিয়ম অনুসারে ডিজাইন করতে শিখুন: "এখন যা সত্য রয়েছে তা সম্ভবত দশ মিনিটের মধ্যেই হবে না।" আপনার নকশা পরিবর্তন মোকাবেলা করতে পারে তা নিশ্চিত করুন।
blrfl

1
এই স্কিমাটির আসলে সুবিধা রয়েছে যে যখন কোনও কর্মী isোকানো হয় তখন তাদের বিভাগের অস্তিত্ব থাকতে হয়।
সাইমন রিখটার

@ সিমোন রিখটার: এটি সত্য নয়। কর্মচারী বিদ্যমান কোনও বিভাগ ছাড়াও তৈরি করা যেতে পারে, এবং বিপরীতও।
ড্যানিয়েল ডিনিজ

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

48

আমি মনে করি না যে কোনও ডাব্লুটিএফ প্ররোচিত হয়েছে বা লোকটি কোনও পাগল প্রতিভাধরনের নকশা করছে - এটি বেশ স্ট্যান্ডার্ড ডাটাবেস নরমালাইজেশন।

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

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

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

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

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

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


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

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

@ পিএসএস আমার মনে হয় একটি টাইপো আছে: "বিভাগগুলি প্রতি মাত্র একজন ব্যবহারকারী আছে এমন" প্রশ্নগুলি কি "হওয়া উচিত নয় যে ব্যবহারকারীরা কেবলমাত্র একটি বিচ্যুতির মধ্যে রয়েছে?"
বিআইআইবি

@ বিআইআইবি - আপনি ঠিক বলেছেন, আমি যা বলতে চাইছিলাম সেটাই তাই।
PSr

14

যদি প্রয়োজন হয় ব্যবহারকারী প্রতি একাধিক বিভাগ থাকে, এই নকশাটি বোঝা যায়। এটি সম্পর্কে একমাত্র গ্রিপ হ'ল UserDepartmentTableএকটি সরোগেট কী থাকা দরকার UserDepartmentIDযা প্রয়োজন হয় না (কেবল UserIdএবং DepartmentIdএকটি সম্মিলিত প্রাথমিক কী তৈরি করুন)।

যদি কোনও ব্যবহারকারী কেবল কখনও একটি বিভাগের অন্তর্ভুক্ত থাকে তবে আপনার নকশাটি বোধগম্য হয় (যদিও বিভাগীয় অনুসন্ধানের টেবিলটি এখনও একটি ভাল জিনিস হবে)।


18
... যতক্ষণ না প্রতি ব্যবহারকারী একাধিক বিভাগ সম্ভব।
blrfl

1
হুবহু, @ ব্লগার আজকের আর কখনও ঘটবে না তা হ'ল আগামীকাল সিইও-হচ্ছেন-অ্যানিউরিজম-কারণ-এটি-তা-তা করে না।
অ্যাডাম ক্রসল্যান্ড

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

8
YAGNI - ডাটাবেসগুলি রিফ্যাক্টর করা যেতে পারে।
জেফো

2
@ ওহেড, অ্যান্টিটি ফ্রেমওয়ার্কের মতো কিছু ওআরএম ম্যাপারগুলি সম্মিলিত প্রাথমিক কী রয়েছে এমন টেবিলগুলির সাথে ভাল কাজ করে না।
maple_shaft

5

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

0-ব্যবহারকারী এবং কর্মচারীর মধ্যে পার্থক্য কী?

1-একজন কর্মচারী = ব্যবহারকারী ধরে নেওয়া, যদি কোনও কর্মী বিভাগ পরিবর্তন করেন?

2-একদল কর্মচারী 1 টি অনুরোধ করতে পারেন?

3-কোন কর্মচারী একাধিক বিভাগের হতে পারে? সিইও সম্পর্কে কি

4-এমন কোনও কর্মচারীর কি সাবসেট রয়েছে যাতে অনুরোধ করার অনুমতি দেওয়া হয়?

5-কোনও কর্মচারী রেকর্ড মুছে ফেলা হলে (যদি কখনও থাকে) অনুরোধটির কী হয়?

6-আপনি একটি অনুরোধ মুছতে পারেন? অনুরোধটি খণ্ডিত হয়ে গেলে কী ঘটে (আপনি আরআই দ্বারা কর্মচারী রেকর্ডটি মুছবেন না তা নিশ্চিত করুন)

7-কর্মচারী কি একাধিকবার "একই" অনুরোধ করতে পারবেন ("একই" সংজ্ঞা দিন)

8-কর্মচারীরা যখন সংস্থাটি ছেড়ে যায় তখন তাদের অনুরোধগুলি কীভাবে পরিচালনা করবেন (তাদের অনুরোধগুলি বাতিল করুন বা অনুরোধগুলি মুছবেন?)

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


+1 এগুলি দুর্দান্ত প্রশ্ন যা এই ধরণের স্কিমা ডিজাইনের আগে স্পষ্ট করা দরকার। আমি আপনার যুক্তি প্রবাহ পছন্দ।

@ সার্ফার ৫১13: আমি আপনার সুন্দর মন্তব্যের প্রশংসা করি।
NoChance

1

আপনার অত্যন্ত বেতনের পরামর্শদাতা ফ্যাশনে যোগদানের টেবিল ব্যবহারের কিছু সম্ভাব্য সুবিধাগুলি সম্পর্কে স্পষ্টভাবে কথা বলার জন্য আমি কয়েকটি দফা ফর্ম নোট যুক্ত করতে চাই।

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

বলা হচ্ছে, আপনার অতি-বেতনের পরামর্শদাতা যা করেছেন তা না করার বিভিন্ন কারণ রয়েছে।

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

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

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

0

প্রয়োজনীয় তথ্যের সম্পূর্ণ কাঠামো ছাড়া আমি বলতে পারি না এটি ভয়ানক বা না। তবে কমপক্ষে দেখানো পিসটি "ডাব্লুটিএফ" ডিজাইনের নয়। এটি কেবল 3-তম ডেটা-কাঠামোর সাধারণ ফর্ম হিসাবে মনে হয় (ভাল, আমরা তাত্ত্বিকভাবে 4-আরডি এবং 5 তমও রয়েছি)

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

নরমালাইজেশন হ'ল বিভিন্ন কারণে ভাল ডিবি-বিকাশকারী / ডিজাইনারের নিয়ম, * ডি * নরমালাইজেশন প্রায়শই গতি-জয়ের জন্য বিকাশের মাঝখানে ব্যবহৃত হয়

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.