ডাটাবেস ডিজাইন: নতুন কলাম বনাম নতুন কলাম

Question

(স্ট্যাকওভারফ্লো থেকে এটি পুনরায় পোস্ট করার পরামর্শ দেওয়া হয়েছিল)

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

অন্য কথায়, যেহেতু এই নতুন ডেটা উপাদানগুলির জন্য প্রচুর অব্যবহৃত কলাম থাকবে, তাই মনে হচ্ছে এটি কোনও নতুন টেবিলের জন্য আরও উপযুক্ত হবে?

প্রথম টেবিলটি পৃষ্ঠা দর্শনগুলির রেকর্ড (বর্তমানে 2 মিলিয়ন রেকর্ড)

- আইডি
- আইপি ঠিকানা
- বার দেখা হয়েছে
- তৈরি টাইমস্ট্যাম্প
- তারিখ

প্রতিটি আইপি ঠিকানার জন্য, প্রতিদিন একটি রেকর্ড তৈরি করা হয় - এবং একটানা পেজভিউগুলি প্রতিদিনের দর্শন বারের সাথে যুক্ত করা হয়

অতিরিক্ত ক্ষেত্রগুলি মূল উত্স ট্র্যাকিংয়ের জন্য হবে (যেমন গুগল অ্যানালিটিক্স উত্স / মাঝারি / প্রচার)

প্রতিটি ভিজিটের কাছে সেই তথ্য থাকবে না। আমি ধরে নিব যে প্রায় 10% সারিতে ডেটা থাকবে (কারণ এটি কেবল প্রথম দর্শনে সাধারণত দায়ী করা হয়)

ডেটাগুলির প্রধান ব্যবহার হ'ল লোকগুলি কোথা থেকে এসেছিল এমন বৈশিষ্ট্যযুক্ত করা। এটি আরও ঘন ঘন ব্যবহৃত হতে পারে (যা পরে একক টেবিলের কাছে নিজেকে ধার দেয়)

প্রতিক্রিয়াটির প্রশংসা করুন - প্রয়োজন হলে আরও যোগ করতে পারেন

Answer 1

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

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

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

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

Comments

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

— jmoreno 21

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

— সিজিএমকেভার

Answer 2

ব্যক্তিগতভাবে আমি বিদ্যমান সারণীতে কলাম যুক্ত করার দিকে ঝুঁকছি। নতুন টেবিলটি সত্যিই আপনাকে কিছু কিনে না:

• আপনি প্রকৃতপক্ষে খুব বেশি স্থান সঞ্চয় করেন না কারণ মূল টেবিলের নুল মানগুলি কোনও স্থান নেয় না এবং নতুন সারণিতে এমন এক ধরণের সনাক্তকারী প্রয়োজন যা কোনওভাবেই কোনও সঞ্চয়কে অফসেট করে ts
• আপনার প্রশ্নগুলি আরও জটিল where newcolumn is not nullহয়ে ওঠে ... পরিণত হয়left outer join

একক সারণীতে এটির অর্থ হ'ল আপনার সারির আকারটি একেক পৃষ্ঠায় পরিবর্তিত হতে পারে - তবে এটি আপনার বিদ্যমান পৃষ্ঠাগুলির বেশিরভাগকে প্রভাবিত করবে না, বিশেষত যদি আপনার ক্লাস্টারড সূচকটি একঘেয়েভাবে বর্ধমান কলামে থাকে (পরিচয় বা তারিখ / সময়))

Comments

যেহেতু টেবিলটি বর্তমানে প্রশস্ত নয় (আপনার বর্ণনার ভিত্তিতে) এবং এই ডেটাটি খুব বেশি প্রশস্ত করে না, তাই আমি সম্মত হব।

— এইচএলজিইএম

Answer 3

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

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

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