যতটা সম্ভব কম টেবিল সহ একটি ডাটাবেস তৈরি করা দরকার?

Question

আমাদের কি ন্যূনতম সংখ্যক সারণী সহ একটি ডাটাবেস কাঠামো তৈরি করা উচিত?

এটি কি এমনভাবে ডিজাইন করা উচিত যাতে সবকিছু এক জায়গায় থাকে বা আরও টেবিল রাখা ভাল?

এটি যাইহোক কিছু প্রভাবিত করবে?

আমি এই প্রশ্নটি করছি কারণ আমার এক বন্ধু মিডিয়া উইকিতে কিছু ডাটাবেস কাঠামো পরিবর্তন করেছে mod শেষ পর্যন্ত, তিনি 20 টি টেবিলের পরিবর্তে কেবলমাত্র 8 টি ব্যবহার করছিলেন এবং এটি করতে 8 মাস সময় লেগেছিল (এটি তার কলেজের অ্যাসাইনমেন্ট ছিল)।

সম্পাদনা

আমি উত্তরটি এইভাবে শেষ করছি: কেসটি ব্যতিক্রমী না হওয়া পর্যন্ত টেবিলগুলির আকারের কোনও গুরুত্ব নেই; এই ক্ষেত্রে ডেনোরালাইজেশন সাহায্য করতে পারে।

উত্তরের জন্য প্রত্যেককে ধন্যবাদ।

Comments

ন্যূনতম সংখ্যক সারণী সহজ, কেবলমাত্র পুরোটিকে মাস্টার_ টেবিলটিতে সারণীকরণ করুন (টেবিলের নাম, কল_নাম, কল_ টাইপ, সারি_আইডি, মান)।

— ইনকা

কি? আমি এটি পাচ্ছি না

— শাহির

যেহেতু একটি ডাটাবেসের প্রতিটি ক্ষেত্র সারণির নাম, কলামের নাম, প্রাথমিক কী এবং মান সংমিশ্রণ দ্বারা সংজ্ঞায়িত করা হয়, আপনি সর্বদা একক টেবিলের মধ্যে নামারমাইজ করে টেবিলের সংখ্যা হ্রাস করতে পারেন যা কেবল এটি সংরক্ষণ করে। খুব দরকারী নয়, তবে সম্পূর্ণ সম্ভব।

— ইনকা

আমি ভাল করে জানার জন্য জিজ্ঞাসা করছিলাম, এবং যদি বিদ্যমানটির চেয়ে কিছু কার্যকর হয় তবে কেন এটি পরিবর্তন করবেন? মানে কি এতে কোনও উন্নতি হবে? উদাহরণস্বরূপ কর্মক্ষমতা?

— শাহির

@ হামজা: এটি উন্নত পারফরম্যান্স সরবরাহ করতে পারে । এটি সত্যিকারের নির্দিষ্ট পরিস্থিতিতে নির্ভর করে। ওখানে নেই প্রায় এখানে যথেষ্ট তথ্য আমাদের একটি কংক্রিট উত্তর দিতে জন্য।

— হতাশ

Answer 1

টেবিল সংখ্যা IGNORE । নকশাটি সঠিক হওয়ার বিষয়ে আরও চিন্তা করুন । যদি আপনার প্রধান উদ্বেগটি টেবিলের পরিমাণ হয় তবে আপনার সম্ভবত ডাটাবেস সিস্টেম ডিজাইন করা উচিত নয়।

যদি আপনার বন্ধুর জন্য কেবল 8 টি টেবিলের প্রয়োজন হয় এবং সিস্টেমটি এটির সাথে ভাল কাজ করে তবে 8টি সঠিক সংখ্যা এবং বাকি 12 টি তিনি যা করছেন তার জন্য প্রয়োজনীয় নাও হতে পারে।

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

Comments

+1:If your major concern is quantity of tables, you should probably not be designing database systems.

— জোয়েল ইথারটন

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

— অ্যারোনআউট

+1, যদিও আমি মনে করি না যে আমরা তাঁর ক্ষেত্রে সঠিক সংখ্যাটি 8 বলে যথেষ্ট বলছি, কারণ আমরা স্কিমার তুলনা করতে পারি না (মূলত বর্তমানে অ্যাপ্লিকেশনটির চেয়ে উচ্চতর লেনদেনের আয়তনের চেয়ে ভাল হতে পারে) উদাহরণ)

— অ্যাডাম রবিনসন

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

— হতাশ

@ টম অ্যান্ডারসন - তারপরে আপনার এখনও ডাটাবেস সিস্টেম ডিজাইন করা উচিত নয়।

— জোয়েল ইথারটন

Answer 2

একটি ডাটাবেসে যেমন প্রয়োজন তেমন টেবিল থাকা উচিত। কম নয়, আর নেই।

Comments

english.stackexchange.com/questions/495/less-vs-fewer এটিকে আলোচনায় রূপান্তর না করা, তবে এখানে ইংরেজি ভাষার এসই থেকে "কম" বনাম "কম" বিতর্কের উত্স সহ একটি আকর্ষণীয় আলোচনা এখানে দেওয়া হয়েছে SE , যেহেতু এটি আপনাকে ছেলেরা মনে করে;)

— কোরি

Answer 3

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

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

Comments

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

— maple_shaft

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

— মাইকেল কে

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

— maple_shaft

স্টার স্কিমার

— ম্যাপেল_শ্যাফ্ট

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

— এইচএলজিইএম

Answer 4

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

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

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

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

Comments

গুগল বিগ টেবিল ডিজাইন করেছে এবং ইচ্ছাকৃতভাবে যোগদানগুলি বাদ দেয় কারণ এটি সমান্তরাল নয়।

— মিথ্যা রায়ান

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

— এইচএলজিইএম

আপনার জন্য +1, @HLGEM, উত্তর এবং মন্তব্য উভয়ের জন্য; এটি অনেকগুলি বিকাশকারীকে দেখে লজ্জাজনক যে ডকুমেন্ট ডাটাবেস ব্যান্ডওয়াগনে ঝাঁপিয়ে পড়ে কারণ তারা মনে করে "যোগ দেয়" ধীর ", কেবল যেতে এবং 20 বছর আগে সম্পর্কযুক্ত ডাটাবেসগুলির দ্বারা সমাধান করা রিলেশনাল সমস্যাগুলি সমাধান করার চেষ্টা করার জন্য।

— অ্যাডাম রবিনসন

Answer 5

যেহেতু একটি ডাটাবেসের প্রতিটি ক্ষেত্র সারণির নাম, কলামের নাম, প্রাথমিক কী এবং মান সংমিশ্রণ দ্বারা সংজ্ঞায়িত করা হয়, আপনি সর্বদা একক টেবিলের মধ্যে নামারমাইজ করে টেবিলের সংখ্যা হ্রাস করতে পারেন যা কেবল এটি সংরক্ষণ করে। খুব দরকারী নয়, তবে সম্পূর্ণ সম্ভব।

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

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

Comments

ধন্যবাদ, এটি একটি অনেক স্পষ্ট এখন !, এবং আমি আছে নিয়মমাফিককরণ সম্পর্কে BTW পড়া, আমি এটা এমনকি এটি cakePHP ডাটাবেস, যা অন্য এবং কিছুটা ভিন্ন পদ্ধতি উৎসাহিত করে না।

— শাহির

Answer 6

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

Answer 7

ন্যূনতম সংখ্যক টেবিল থাকা আমাকে খুব অদ্ভুত লক্ষ্য হিসাবে আঘাত করে।

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

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

অবশ্যই এটি ধীর পারফরম্যান্সের দিকেও ডেকে আনতে পারে (ধরে নিই ডেনোরমাইলেসড ডাটাবেসটি ভালভাবে ডিজাইন করা হয়েছিল)।

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

Answer 8

সংখ্যাটি গুরুত্বপূর্ণ নয়। ডিজাইন হয়। কিছু সিস্টেম দেখুন। ম্যাজেন্টো, পিএইচপিবিবি ইত্যাদি তাদের সিস্টেমে কয়েক ডজন টেবিল রয়েছে এবং ঠিকঠাক কাজ করে।

Answer 9

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

Answer 10

আপনি যদি টেবিল তৈরির কাজটি হ্রাস করার চেষ্টা করে একটি ডেটাবেস ডিজাইন করেন, তবে শীঘ্রই আপনি হঠাৎ অসুবিধা দেখতে পাবেন এবং আপনার উপায়গুলিতে ভুল হয়ে যাবেন।

ডাটাবেস ডিজাইন তৈরি করার সময় সারণী গণনা আপনার মনের সামনে থাকা উচিত নয়। যুক্তিযুক্তভাবে এবং আপেক্ষিকভাবে যেখানে যেতে হবে সেখানে এমন জিনিস রাখুন।

Answer 11

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

আমি বিশদে যেতে চাই না, তবে আমি মনে করি যে টেবিলের সংখ্যা কার্য সম্পাদনকে প্রভাবিত করতে পারে এমন আসল ঘটনা হ'ল ক্যাসান্দ্রা, মঙ্গো এবং গুগল বিগ টেবিল (সিক!) এর মতো নুএসকিউএল ডাটাবেসগুলি উদ্ভাবন করার কারণ, এবং সে কারণেই তারা ডেটা-সাধারণকরণকে উত্সাহ দেয় (এবং ফলস্বরূপ বিপুল সংখ্যক সারণী / সংগ্রহ ইত্যাদি এড়ানো)।

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

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

Answer 12

চাচা বব যুক্তি দিতেন যে আরও সহজ সরল।

Http://c2.com/cgi/wiki?FearOfAddingTables দেখুন

"একটি ভাল নকশা সাধারণত সারণী যুক্ত করে সরলীকৃত হয়"

আমি বিশ্বাস করি যে প্রায় সমস্ত সত্তা অনেকগুলি থেকে বহু, যার জন্য আরও সারণী প্রয়োজন।

এতে মহাদেশের কোড সহ একটি দেশ টেবিল তৈরি করুন। ওহ, আপনি পারবেন না কারণ এখানে 8 টি ট্রান্সকন্টিনেন্টাল দেশ রয়েছে। মুদ্রার সাথে একই। পানামা দুটি ব্যবহার করে।

Answer 13

তারপরে উত্তর হ্যাঁ।

"ন্যূনতম" সারণীর সংখ্যার আসল অর্থ কী তা নির্ভর করুন।

উদাহরণস্বরূপ (একটি বিরোধী উদাহরণ)।

আমার যদি পরের বস্তু থাকে

1. ব্যবহারকারীদের
2. গ্রাহকদের

এবং উভয়ই একই রাজ্যগুলি (ক্ষেত্রগুলি) ভাগ করে নেয় এবং তখন কোনও সুরক্ষা নিষেধাজ্ঞা থাকে না, এটি কোনও একক টেবিল করতে আরও উপযুক্ত

1. table_persons

বরং দুটি আলাদা টেবিল

1. table_users
2. table_customers

কনসটি টেবিল_পারসনের তুলনায় আমাদের একটি নতুন ক্ষেত্র যুক্ত করতে হবে (টাইপ_মোক্তা)।

অন্যান্য ভুল (ভুলটি যদি এটি করার প্রয়োজন হয় না) হ'ল একটি টেবিলকে "বিভক্ত" করা, পড়ুন: একটি টেবিলকে দুটি করে আলাদা করুন।

1. table_persons

দুটি টেবিলের মধ্যে

1. table_info_persons
2. table_extra_info_persons

কারণ আপনি কিছু প্রশ্নের জন্য দুটি টেবিলের সাথে যোগ দিতে বাধ্য করছেন এবং এটি খারাপ।

Comments

আরে আপনার উত্তরটি খুব বর্ণনামূলক এবং সহায়ক, ধন্যবাদ

— শাহির

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

-1: ব্যবহারকারী এবং গ্রাহকদের বিভিন্ন ক্ষেত্র রয়েছে; যদি এই মুহুর্তে না হয় তবে ভবিষ্যতে তাদের কোনও মুহুর্তে উপস্থিত হবে। সুতরাং তারা পৃথক টেবিল প্রাপ্য।

— সুজোরড

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

— অ্যাডাম রবিনসন

"ডাটাবেসগুলি সারি এবং সম্পর্ক, বস্তু নয়" এর জন্য +1, আমি এটিকে আমার ফেভ কোটে যুক্ত করব!

— শাহির