দ্রুত প্রশ্নের জন্য কলাম অনুলিপি?

30

শিরোনাম খুব বেশি বোঝায় না, তবে আমি এই সমস্যার জন্য আরও ভাল শিরোনাম ভাবতে পারি না।

আমি নিম্নলিখিত টেবিল আছে

প্রকল্প

আইডি
নাম

গ্রাহকরা

আইডি
id_project
নাম

পেমেন্টস্

আইডি
id_customer
তারিখ
সমষ্টি

যখন কোনও ব্যবহারকারী সিস্টেমে প্রবেশ করে তখন তার একটি নির্দিষ্ট প্রকল্পে অ্যাক্সেস থাকবে। এখন, আমি এই প্রকল্পের জন্য সমস্ত অর্থ প্রদানের তালিকা তৈরি করতে চাই এবং এটি বেশ সহজ হওয়া উচিত:

SELECT FROM payments where id_customer in (SELECT id from customers where id_project = 5)

আমার প্রশ্নটি হল: যদি এইভাবে অর্থ প্রদানের টেবিলটিতে আইডি_প্রজেক্টটি কলাম যুক্ত করা ভাল না হয় তবে ক্যোয়ারীগুলি আরও সহজ এবং দ্রুত হবে।

database-design normalization

— গ্যাব্রিয়েল সলোমন
সূত্র

1

সুতরাং ক্যোয়ারী আধুনিক আরডিবিএমএসের সমস্যা নয় (বা আরও ভাল, যোগ যোগ করুন)।

— গারিক

4

সম্মতি দিন, বনাম যোগে সাব-সাবলেট করার জন্য একটি ক্যোয়ারী পরিকল্পনা পান এবং কোনটি আরও ভাল তা দেখুন

— গাইউস

1

আমি মনে করি এটা তাই বা যেহেতু @igor ব্যবহার সম্পর্কে উল্লেখ JOIN পোস্ট, খুঁজছেন মূল্য হয়

— CoderHawk

52

মনে হচ্ছে আপনি জিজ্ঞাসা করছেন কিনা ডেনারমালাইজেশনটি বোঝা যায় ।

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

উত্তরটি সর্বদা "এটি নির্ভর করে" তাই আমার থাম্বের নিয়মটি এখানে:

যদি ...

তথ্যের পরিমাণ বড় নয়
আপনি ইতিমধ্যে একটি টন যোগদান করে না
এবং / অথবা ডাটাবেস কর্মক্ষমতা বর্তমানে কোনও বাধা নয়

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

আমি কেবল তখনই অস্বীকার করব যখন ...

ডেটা পরিমাণ খুব বড়
যোগদানগুলি ব্যয়বহুল এবং এমনকি তুচ্ছ প্রশ্নগুলি ফিরে পেতে আপনাকে তাদের অনেক কিছু করতে হবে
ডাটাবেস কর্মক্ষমতা হ'ল একটি বাধা এবং / অথবা আপনি যত দ্রুত সম্ভব যেতে চান go

আধুনিক হার্ডওয়্যারে যোগ দেয় খুব দ্রুত, তবে তারা কখনই মুক্ত হয় না ।

— জেফ আতউড
সূত্র

9

আপনি কোয়েরিটি আবার লিখতে ভাল হবে:

SELECT payments.*
FROM   customers
JOIN   payments 
ON     payments.id_customer = customers.id
WHERE  customers.id_project = 5

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

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

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

customer     project      payment
--------     --------     -------
                          pa_id
             pr_id    <-- payment
cu_id    <-- customer

বা যদি কম স্বাভাবিক করা হয় (যদিও আমি সন্দেহ করি যে এটি প্রয়োজনীয় হবে):

customer     project      payment
--------     --------     --------
                          pa_id
             pr_id    <-- payment
cu_id    <-- customer 
           `------------- customer

অবশ্যই এখনও দুটি গ্রাহকের সাথে একটি যৌথ প্রকল্পের সম্ভাবনাটি ছাড় দেয় ...

— ডেভিড স্পিললেট
সূত্র

3

পারফরম্যান্সের প্রথম নিয়ম: উত্পাদনে কখনই ব্যবহার করবেন না!

— ব্রায়ান বলসুন-স্ট্যান্টন

@ ব্রায়ান: খুব বৈধ পয়েন্ট। এবং পাশাপাশি নির্বাচিত ধারাগুলিতে * এড়ানো সম্ভাব্য পারফরম্যান্সের প্রভাবগুলি এমএসএসকিউএল-এ ভিউ-অন-ভিউতে কলাম ক্রম করতে সমস্যাগুলি এড়ায় যদি sys.d depends DROP VIEW+ এর CREATE VIEWপরিবর্তে + ব্যবহারের কারণে খুনের বাইরে চলে যায় ALTER VIEW।

— ডেভিড স্পিলিট

সহজ লেখার জন্য ব্রায়ান আমি * রেখেছি।

— গ্যাব্রিয়েল সলোমন

প্রকল্পটি ডোমেনের সাথে স্বতন্ত্র অ্যাপ্লিকেশন হিসাবে আরও বেশি চিন্তিত এবং এটি বিভিন্ন গ্রাহকের অন্তর্ভুক্ত যাতে গ্রাহক বিভিন্ন প্রকল্পে একই অ্যাকাউন্ট রাখতে না পারে

— গ্যাব্রিয়েল সলোমন

4

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

— ক্রিস্টোফ প্রিটনার
সূত্র