কোনটি আরও দক্ষ: একাধিক মাইএসকিউএল টেবিল বা একটি বড় টেবিল?

Question

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

• এটি কি কোনও সহায়তা বা বাধা হয়ে দাঁড়াবে?
• কলিং, আপডেট করা বা অনুসন্ধান / চালাকি করার ক্ষেত্রে গতির বিবেচনা?

এখানে আমার টেবিল কাঠামোর কয়েকটি উদাহরণ রয়েছে:

• ব্যবহারকারী - ব্যবহারকারী, ব্যবহারকারী নাম, ইমেল, এনক্রিপ্ট করা পাসওয়ার্ড, নিবন্ধকরণের তারিখ, আইপি
• ব্যবহারকারীর_র বিবরণ - কুকি ডেটা, নাম, ঠিকানা, যোগাযোগের বিশদ, অধিভুক্তি, ডেমোগ্রাফিক ডেটা
• ব্যবহারকারীর_অ্যাক্টিভিটি - অবদান, সর্বশেষ অনলাইন, শেষ দেখার জন্য
• ব্যবহারকারী_সেটেটিং - প্রোফাইল প্রদর্শন সেটিংস
• ব্যবহারকারীর_আপনি - বিজ্ঞাপন টার্গেটেবল ভেরিয়েবল
• ব্যবহারকারী_স্তাদ - অ্যাক্সেসের অধিকার
• ব্যবহারকারীর স্ট্যাটাস - হিট, লম্বা

---

সম্পাদনা: আমি এখনও অবধি সমস্ত উত্তরকে আপলোড করেছি, তাদের সকলেরই এমন উপাদান রয়েছে যা মূলত আমার প্রশ্নের উত্তর দেয় answer

বেশিরভাগ টেবিলের মধ্যে 1: 1 টি সম্পর্ক রয়েছে যা এগুলি অস্বীকার করার মূল কারণ ছিল।

এই ঘরগুলির একটি বড় অংশ শূন্য থাকার সম্ভাবনা থাকলে টেবিলটি 100+ কলাম জুড়ে বিস্তৃত হলে কি সমস্যা দেখা দিতে পারে?

Comments

এই অন্যান্য প্রশ্নটিও সহায়ক হতে পারে

— মোস্তি মোস্তাচো

Answer 1

একাধিক সারণী নিম্নলিখিত উপায় / ক্ষেত্রে সহায়তা করে:

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

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

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

(d) আপনি যখন কোনও একক সত্তার নির্দিষ্ট ডেটা সংগ্রহের জন্য অ্যাপ্লিকেশনগুলি বিকাশ করেন তখন ছোট পাদদেশের ছোট মুদ্রণ আরাম দিতে পারে।

(ঙ) এটি একটি সম্ভাবনা: আপনি একক মান ডেটা হিসাবে যা ভেবেছিলেন তা ভবিষ্যতে সত্যিই একাধিক মান হতে পারে। যেমন ক্রেডিট সীমা এখন পর্যন্ত একক মান ক্ষেত্র। তবে আগামীকাল, আপনি মানগুলি (তারিখ, তারিখ থেকে, creditণের মান) হিসাবে পরিবর্তন করার সিদ্ধান্ত নিতে পারেন। বিভক্ত টেবিলগুলি এখন কার্যকর হতে পারে।

আমার ভোট একাধিক টেবিলের জন্য হবে - ডেটা যথাযথভাবে বিভক্ত হয়ে।

শুভকামনা।

Comments

@ রোহিতখাত্রী: আমার জ্ঞানের সেরা দিক থেকে একাধিক টেবিল থাকা বেশিরভাগ ক্ষেত্রে কর্মক্ষমতা বাড়িয়ে তুলবে।

— হরি হার্কার

@ হারিহর্কার আপনার উত্তরের জন্য ধন্যবাদ, তবে আমি বুঝতে পেরেছি যে এটি আপনার অ্যাক্সেস প্যাটার্নের উপর নির্ভর করে।

— রোহিত খাতরী

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

— লিখন না করে এগুলিকে

Answer 2

সারণীগুলির সংমিশ্রণকে ডেনারমালাইজিং বলা হয়।

এটি JOINরক্ষণাবেক্ষণের নরক তৈরির ব্যয়ে দ্রুত চালাতে কিছু অনুসন্ধান (যা প্রচুর পরিমাণে তৈরি করে) তৈরি করতে সহায়তা করতে পারে (বা নাও) ।

MySQLকেবলমাত্র JOINপদ্ধতি ব্যবহার করতে সক্ষম NESTED LOOPS।

এর অর্থ হ'ল ড্রাইভিং টেবিলের প্রতিটি রেকর্ডের জন্য MySQLচালিত টেবিলের সাথে একটি লুপে একটি মিলের রেকর্ড সনাক্ত করা হয়।

একটি রেকর্ড সনাক্ত করা বেশ ব্যয়বহুল ক্রিয়াকলাপ যা খাঁটি রেকর্ড স্ক্যানিংয়ের জন্য কয়েক ডজন সময় নিতে পারে।

আপনার সমস্ত রেকর্ডকে একটি টেবিলের মধ্যে স্থানান্তর করা আপনাকে এই ক্রিয়াকলাপ থেকে মুক্তি পেতে সহায়তা করবে, তবে টেবিলটি নিজেই আরও বড় হয় এবং টেবিল স্ক্যানটি আরও বেশি সময় নেয়।

আপনার যদি অন্য টেবিলগুলিতে প্রচুর রেকর্ড থাকে, তবে টেবিল স্ক্যানটি বাড়ানো রেকর্ডগুলি যথাক্রমে স্ক্যান হওয়ার অতিরিক্ত ওজনের সুবিধাগুলি পেতে পারে।

অন্যদিকে রক্ষণাবেক্ষণ নরকের নিশ্চয়তা রয়েছে।

Comments

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

— রুডি গার্সিয়া

Answer 3

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

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

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

Comments

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

— রুডি গার্সিয়া

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

— টুলমেকারস্টিভ

Answer 4

এই সমস্ত টেবিলের কি কোনও 1-to-1সম্পর্ক আছে? উদাহরণস্বরূপ, প্রতিটি ব্যবহারকারীর সারিতে কেবল একটিরই সারি থাকবে user_statsনাকি user_levels? যদি তা হয় তবে এগুলি এক টেবিলের সাথে সংযুক্ত করে নেওয়া বোধগম্য হতে পারে। সম্পর্কটি যদি না হয় 1 to 1 তবে এগুলি সম্ভবত একত্রিত করার (অর্থাত্বিক) বোঝা যাবেনা।

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

ইটা:

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

আপনি যদি ডেটা ব্যবহার করার উপায়টি লক্ষ্য করেন তবে আমার ধারণাটি হ'ল আপনি দেখতে পাবেন যে আপনার প্রশ্নগুলির 80% এর মতো কিছু এই ডেটাতে 20% ব্যবহার করে যা বাকি ৮০% ডেটা কেবল মাঝে মধ্যেই ব্যবহৃত হয়। 20% প্রায়শই একটি টেবিলের মধ্যে ব্যবহার করে এমন একত্রিত করুন এবং 80% যা আপনি প্রায়শই পৃথক টেবিলগুলিতে ব্যবহার করেন না তা ছেড়ে যান এবং আপনার সম্ভবত একটি ভাল আপস হবে।

Comments

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

— পিটার ক্রেগ

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

— রিচার্ড এল

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

— জ্যাক ম্যাকোম্বার

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

— টুলমেকারস্টেভ

@ টলমেকারস্টেভ ভাল চিন্তা +1

— জ্যাক ম্যাকমবার

Answer 5

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

সম্পাদনা: আপনি আমার প্রশ্ন আপডেট করার সাথে সাথে আমি আমার উত্তর আপডেট করেছি ... আমি আমার প্রাথমিক উত্তরটির সাথে এখন থেকে আরও একমত ...

এই কোষগুলির একটি বড় অংশ খালি থাকতে পারে

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

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

Comments

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

— টুলমেকারস্টেভ

Answer 6

প্রত্যেকের কাছে থাকা মৌলিক ব্যবহারকারীর তথ্য সহ ওয়ার্ডপ্রেস একই ব্যবহারকারীর ব্যবহারকারীর টেবিলটি ব্যবহার করবেন না এবং তারপরে একটি "ইউজার_মেটা" টেবিল যুক্ত করুন যা মূলত ব্যবহারকারী আইডির সাথে সম্পর্কিত কোনও কী, মান জুটি হতে পারে। সুতরাং যদি আপনার ব্যবহারকারীর জন্য সমস্ত মেটা তথ্য সন্ধান করার প্রয়োজন হয় তবে আপনি এটি আপনার প্রশ্নের সাথে যুক্ত করতে পারেন। লগ ইন করার মতো জিনিসের জন্য প্রয়োজন না থাকলে আপনাকে অতিরিক্ত জিজ্ঞাসা যুক্ত করতে হবে না this এই পদ্ধতির সুবিধাটি আপনার ব্যবহারকারীর জন্য তাদের টুইটার হ্যান্ডেল বা প্রতিটি স্বার্থের আগ্রহ সংরক্ষণ করার মতো নতুন বৈশিষ্ট্য যুক্ত করতে আপনার টেবিলটিকে উন্মুক্ত রাখবে। আপনাকে সম্পর্কিত আইডির একটি গোলকধাঁধাও মোকাবেলা করতে হবে না কারণ আপনার কাছে একটি টেবিল রয়েছে যা সমস্ত মেটাডেটা নিয়ম করে এবং আপনি এটি 50 এর পরিবর্তে কেবল একটি সংখ্যায় সীমাবদ্ধ রাখবেন।

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

Comments

ওয়ার্ডপ্রেস wp_usermetaটেবিল জ্যামিতিকভাবে বৃদ্ধি পায়। প্রতিটি ব্যবহারকারীর wp_usermetaটেবিলের সাথে এক্স সারি যুক্ত হয়, আমরা প্রতিটি ব্যবহারকারীর মেটা তথ্যের জন্য এক সারি রাখতে পারি। আপনি যদি প্রতিটি ব্যবহারকারীর জন্য 8 টি কাস্টম ক্ষেত্র রাখেন, তার অর্থ wp_usermeta users * 8সারি দীর্ঘ হবে। এটি পারফরম্যান্সের সমস্যার কারণ হয়ে

— উঠছে

আমি যদি দেখতে পেতাম যে আপনার যদি কয়েক হাজার ব্যবহারকারী থাকে তবে এটি কীভাবে পারফরম্যান্স সমস্যার কারণ হতে পারে। মূলত ডাটাবেসটির জন্য ব্যবহারকারীদের মেটা টেবিলের মধ্যে 10000 * 8 টি প্রবেশাধিকার সন্ধান করতে হবে যা আপনার সন্ধান করছে find তবে আপনি যদি প্রয়োজন হয় কেবল মেটা ডেটা জিজ্ঞাসা করেন তবে আমি মনে করি আপনার কর্মক্ষমতা আরও ভাল হবে। আপনি যখন প্রয়োজন বোধ না করেও যদি সর্বদা মেটা ডেটা জিজ্ঞাসা করেন তবে আপনার সমস্যা হতে পারে। আপনার যদি সর্বদা মেটা ডেটার প্রয়োজন হয় তবে টেবিলগুলি বিভক্ত করা সর্বোত্তম পন্থা নয়।

— রুডি গার্সিয়া

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

— তৃতীয়

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

— রুডি গার্সিয়া

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

— রুডি গার্সিয়া

Answer 7

আমি মনে করি এটি এই "পরিস্থিতি নির্ভর" পরিস্থিতিগুলির মধ্যে একটি। একাধিক সারণী থাকা পরিষ্কার এবং সম্ভবত তাত্ত্বিকভাবে আরও ভাল। আপনি যখন কোনও একক ব্যবহারকারীর সম্পর্কে তথ্য পেতে আপনাকে 6-7 টেবিলগুলিতে যোগদান করতে পারেন তখন আপনি সেই পদ্ধতির পুনর্বিবেচনা শুরু করতে পারেন।

Answer 8

আমি বলব এটি অন্যান্য টেবিলগুলি আসলে কী বোঝায় তার উপর নির্ভর করে। কোনও ব্যবহারকারীর_র বিবরণগুলিতে আরও 1 জন / ব্যবহারকারী এবং আরও অনেকগুলি থাকে সাধারণকরণের ক্ষেত্রে কোন স্তরের আপনার প্রয়োজনের জন্য সবচেয়ে উপযুক্ত উপযুক্ত তা আপনার দাবির উপর নির্ভর করে।

আপনার যদি ভাল সূচকযুক্ত একটি টেবিল থাকে যা সম্ভবত দ্রুততর হবে। তবে অন্যদিকে বজায় রাখা সম্ভবত আরও কঠিন।

আমার কাছে দেখে মনে হচ্ছে আপনি ব্যবহারকারীর সাথে 1 থেকে 1 টি সম্পর্ক হওয়ায় আপনি ব্যবহারকারী_ বিবরণগুলি এড়িয়ে যেতে পারেন। তবে বাকী ব্যবহারকারীরা কি প্রতি ব্যবহারকারীকে অনেকগুলি সারি ব্যবহার করতে পারেন?