মাইএসকিউএল: একাধিক টেবিল বা অনেকগুলি কলাম সহ একটি টেবিল?

Question

সুতরাং এটি একটি নকশা প্রশ্ন আরও।

আমার একটি প্রাথমিক কী আছে (ব্যবহারকারীর আইডি বলুন) এবং সেই ব্যবহারকারীর সাথে আমার প্রচুর পরিমাণে তথ্য যুক্ত রয়েছে।

তথ্য অনুসারে আমার কি একাধিক টেবিলগুলি বিভাগে বিভক্ত করা উচিত, বা অনেক কলাম সহ আমার কেবল একটি টেবিল থাকা উচিত?

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

সম্প্রতি কেউ আমাকে বলেছিল যে সেভাবে না করাই ভাল এবং প্রচুর কলাম সহ একটি টেবিল থাকা ভাল। জিনিসটি হ'ল, এই সমস্ত কলামগুলির একই প্রাথমিক কী রয়েছে।

আমি ডেটাবেস ডিজাইনে বেশ নতুন তাই কোন পদ্ধতির ভাল এবং কোনটি ভাল?

এটি করার প্রচলিত উপায় কী?

Comments

: স্পষ্টতার জন্য, আমাদের শোধন যদি আমি ভুল, কিন্তু আমি মনে করি "একাধিক টেবিল" লিঙ্কটি / মিশুক টেবিল হিসাবে বোঝা যাবে en.wikipedia.org/wiki/Associative_entity

— cellepo

বিশ্লেষণমূলক উদ্দেশ্যে বা অপারেশনাল / লেনদেনের প্রক্রিয়াজাতকরণের জন্য এই ডাটাবেসটির প্রয়োজন?

— আলেকজান্ডার রাদেভ

Answer 1

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

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

আপনি ডেটাবেস নরমালাইজেশনে উইকিপিডিয়া নিবন্ধটি আকর্ষণীয় খুঁজে পেতে পারেন , কারণ এটি গভীরভাবে এর কারণগুলি নিয়ে আলোচনা করে:

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

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

Comments

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

— জাভেয়ের_এক্স

@ জাভিয়ার_এক্স - হ্যাঁ, যদি ব্যবহারকারীর প্রতি মাত্র একটি কলাম থাকে তবে কেবলমাত্র একটি বিশাল ব্যবহারকারীর টেবিলের সাথে কাজ করা আরও সহজ হবে (এবং ডিবি ইঞ্জিনের অনুকূলকরণের পক্ষে আরও অনেক সহজ)।

— ব্রেন্ডন লং

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

— উইকিটি

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

— ব্রেন্ডন লং

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

— এমভি

Answer 2

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

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

Comments

আহ বিভিন্ন কণ্ঠ! যা সর্বদা দুর্দান্ত। আপনার তথ্যের জন্য ধন্যবাদ! আমি আমার টেবিলগুলি তৈরি করার সময় আমি সে সম্পর্কে সচেতন তা নিশ্চিত করব ... তবে আমি জানতাম না যে মূলত এ জাতীয় নিম্ন স্তরের স্টাফগুলি সম্পর্কে আমার সচেতন হতে হবে।

— জাভিয়ের_এক্স

Answer 3

আমি একটি ভাল উদাহরণ আছে। নিম্নলিখিত সংস্থাগুলির সাথে অতিরিক্ত সাধারণকরণের ডাটাবেস:

people -> rel_p2staff -> staff

এবং

people -> rel_p2prosp -> prospects

যেখানে মানুষের নাম এবং ব্যক্তির বিশদ রয়েছে, কর্মীদের কেবল কর্মীদের রেকর্ড বিশদ রয়েছে, সম্ভাবনার কেবল সম্ভাবনার বিশদ রয়েছে এবং রিল টেবিলগুলি কর্মীদের এবং সম্ভাবনার সাথে সংযুক্ত ব্যক্তিদের বিদেশী কীগুলির সাথে সম্পর্কের সারণী।

এই ধরণের ডিজাইন পুরো ডাটাবেসের জন্য বহন করে।

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

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

সমাধানটি হ'ল people -> staffএবং এর সাথে প্রত্যক্ষ সম্পর্ক থাকবেpeople -> prospect

Comments

পুনর্নির্মাণটি কীভাবে গেল তা জানতে আগ্রহী হবেন? আপনি একক টেবিল উত্তরাধিকার যেখানে আপনি ছিল অনুরূপ কিছু নকশা শেষ হয়নি একটি typeএকটি হচ্ছে staffবা prospect?

— কোড্রামামা

সরাসরি সম্পর্কের লোকদের সাথে চলে গিয়েছিল -> কর্মী এবং লোকেরা -> প্রত্যাশী, একটি কবজ কাজ করে, সহজেই ব্যবহার করা যায়, দ্রুত জিজ্ঞাসা করার জন্য কাজ করে।

— ভ্লাদ

Answer 4

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

সুতরাং আপনি যদি এই পরিস্থিতিতে থাকেন তবে আপনাকে অবিচ্ছিন্নভাবে একটি বৃহত টেবিলের মধ্যে অনেকগুলি কলাম এবং বিভাজন নিয়ে সিদ্ধান্ত নিতে হবে না, তবে এটি কমাতে আপনি কলামগুলি JSON অবজেক্টগুলিতে একীভূত করতে পারেন যেমন ঠিকানাটির পরিবর্তে 5 টি কলাম রয়েছে, এটি কেবল এক হও. আপনি সেই বস্তুটিতেও প্রশ্ন করতে পারেন।

Comments

জিজ্ঞাসা করার সময় জেসন অবজেক্টটি ব্যবহার করার সময় তিনি কী সম্পাদন করবেন?

— দাগলটি

@ ডাগাল্টি আমি যে অ্যাপ্লিকেশনগুলিতে এটি ব্যবহার করেছি তার জন্য পারফরম্যান্স ঠিক আছে। আমি এটিতে আমার নিজস্ব বেঞ্চমার্কিং করিনি, তবে এটি আপনার কাজে লাগতে পারে: arangodb.com/2018/02/…

— ম

Answer 5

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

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

কনস ডিজাইন শক্ত, প্রশ্নগুলি আরও জটিল হয়ে ওঠে

তবে, এমন অনেকগুলি ক্ষেত্রে রয়েছে যেখানে একটি বড় ফ্ল্যাট টেবিল উপযুক্ত হবে তাই আপনাকে সিদ্ধান্ত নিতে আপনার পরিস্থিতিটি দেখতে হবে।

Comments

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

— জাভেয়ের_এক্স

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

— ব্রায়ান

Answer 6

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

Comments

"আপনার কাছে একটি বিশাল রেকর্ড থাকলে একটি বিশাল টেবিল ব্যবহার করুন .." তবে ফেসবুক, গুগল একক টেবিলে ব্যবহারকারীর ডেটা সংরক্ষণ করে না, তারা এগুলিকে অনেকগুলি টেবিল হিসাবে আলাদা করেছে।

— ইয়ামি অডিমেল

Answer 7

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

Comments

তথ্যের জন্য ধন্যবাদ, তবে দুঃখিত আমি আপনার উত্তরটি বেশ বুঝতে পারছি না ... আপনি যে দুটি স্কিমার কথা আগে উল্লেখ করেছেন আমি তার উপর একটি অনুসন্ধান করব ...

— জাভেয়ের_এক্স

Answer 8

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