ব্যালেন্সিং ডাটাবেসে লেখা এবং পড়া

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

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

বিবরণ

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

একটি কার্যকরী ডাটাবেসে এটি দেখতে এইরকম হবে:

CLASS Department ‘Отдел’;
name ‘Наименование’ = DATA STRING[100] (Department);

CLASS Employee ‘Сотрудник’;
department ‘Отдел’ = DATA Department (Employee);
salary ‘Зарплата’ =  DATA NUMERIC[10,2] (Employee);

countEmployees ‘Кол-во сотрудников’ (Department d) = 
    GROUP SUM 1 IF department(Employee e) = d;
salarySum ‘Суммарная зарплата’ (Department d) = 
    GROUP SUM salary(Employee e) IF department(e) = d;

SELECT name(Department d), countEmployees(d), salarySum(d);


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

এটা স্পষ্ট যে বিভিন্ন ডিবিএমএসে এক্সিকিউশন ওভারহেড ভিন্ন হতে পারে, কিন্তু জটিলতা কোনোভাবেই পরিবর্তন হবে না।

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

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

বিধিনিষেধ কি? শুধুমাত্র একটি জিনিস: এই ধরনের ফাংশনে অবশ্যই একটি সীমিত সংখ্যক ইনপুট মান থাকতে হবে যার জন্য এর মান সংজ্ঞায়িত করা হয়েছে। অন্যথায়, একটি টেবিল তৈরি করা অসম্ভব হবে যা এর সমস্ত মান সঞ্চয় করে, যেহেতু অসীম সংখ্যক সারি সহ একটি টেবিল থাকতে পারে না।

উদাহরণ:

employeesCount ‘Количество сотрудников с зарплатой > N’ (Department d, NUMERIC[10,2] N) = 
    GROUP SUM salary(Employee e) IF department(e) = d AND salary(e) > N;


এই ফাংশনটি N-এর অসীম সংখ্যক মানের জন্য সংজ্ঞায়িত করা হয়েছে (উদাহরণস্বরূপ, যেকোনো ঋণাত্মক মান উপযুক্ত)। অতএব, আপনি এটিতে ম্যাটেরিয়ালাইজড রাখতে পারবেন না। সুতরাং এটি একটি যৌক্তিক সীমাবদ্ধতা, একটি প্রযুক্তিগত নয় (অর্থাৎ আমরা এটি বাস্তবায়ন করতে পারিনি বলে নয়)। অন্যথায়, কোন সীমাবদ্ধতা আছে. আপনি গ্রুপিং, বাছাই, AND এবং OR, PARTITION, recursion ইত্যাদি ব্যবহার করতে পারেন।

উদাহরণস্বরূপ, পূর্ববর্তী নিবন্ধের 2.2 সমস্যাটিতে, আপনি উভয় ফাংশনে ম্যাটেরিয়ালাইজড রাখতে পারেন:

bought 'Купил' (Customer c, Product p, INTEGER y) = 
    GROUP SUM sum(Detail d) IF 
        customer(order(d)) = c AND 
        product(d) = p AND 
        extractYear(date(order(d))) = y MATERIALIZED;
rating 'Рейтинг' (Customer c, Product p, INTEGER y) = 
    PARTITION SUM 1 ORDER DESC bought(c, p, y), p BY c, y MATERIALIZED;
SELECT contactName(Customer c), name(Product p) WHERE rating(c, p, 1997) < 3;


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

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

parent = DATA Group (Group);


একটি কার্যকরী ডাটাবেসে, পুনরাবৃত্তি যুক্তি নিম্নরূপ নির্দিষ্ট করা যেতে পারে:

level (Group child, Group parent) = RECURSION 1l IF child IS Group AND parent == child
                                                             STEP 2l IF parent == parent($parent);
isParent (Group child, Group parent) = TRUE IF level(child, parent) MATERIALIZED;


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

childrenCount (Group g) = GROUP SUM 1 IF isParent(Group child, g);


SQL ক্যোয়ারীতে কোন CTE থাকবে না। পরিবর্তে একটি সাধারণ GROUP BY থাকবে।

এই প্রক্রিয়াটি ব্যবহার করে, প্রয়োজনে আপনি সহজেই ডাটাবেসটিকে অস্বাভাবিক করতে পারেন:

CLASS Order 'Заказ';
date 'Дата' = DATA DATE (Order);

CLASS OrderDetail 'Строка заказа';
order 'Заказ' = DATA Order (OrderDetail);
date 'Дата' (OrderDetail d) = date(order(d)) MATERIALIZED INDEXED;


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

উপকারিতা

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

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

সহধর্মীদের

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

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

দ্বিতীয়ত, তাদের প্রচুর সীমাবদ্ধতা রয়েছে:

আকাশবাণী

5.3.8.4 দ্রুত রিফ্রেশের উপর সাধারণ বিধিনিষেধ

বস্তুগত দৃষ্টিভঙ্গির সংজ্ঞায়িত প্রশ্নটি নিম্নরূপ সীমাবদ্ধ:

• বস্তুগত দৃষ্টিভঙ্গিতে অ-পুনরাবৃত্ত অভিব্যক্তির উল্লেখ থাকতে হবে না SYSDATE এবং ROWNUM.
• বস্তুগত দৃষ্টিভঙ্গিতে রেফারেন্স থাকা উচিত নয় RAW or LONG RAW তথ্যের ধরণ.
• এটি একটি ধারণ করতে পারে না SELECT তালিকা সাবকোয়েরি।
• এটিতে বিশ্লেষণাত্মক ফাংশন থাকতে পারে না (উদাহরণস্বরূপ, RANK) মধ্যে SELECT দফা।
• এটি একটি টেবিল উল্লেখ করতে পারে না যার উপর একটি XMLIndex সূচক সংজ্ঞায়িত করা হয়।
• এটি একটি ধারণ করতে পারে না MODEL দফা।
• এটি একটি ধারণ করতে পারে না HAVING একটি subquery সহ ধারা।
• এটিতে নেস্টেড প্রশ্ন থাকতে পারে না ANY, ALL, বা NOT EXISTS.
• এটি একটি ধারণ করতে পারে না [START WITH …] CONNECT BY দফা।
• এটি বিভিন্ন সাইটে একাধিক বিস্তারিত টেবিল ধারণ করতে পারে না।
• ON COMMIT বস্তুগত দৃশ্যে দূরবর্তী বিস্তারিত টেবিল থাকতে পারে না।
• নেস্টেড বস্তুগত দৃষ্টিভঙ্গির একটি যোগ বা সমষ্টি থাকতে হবে।
• বস্তুগত যোগদানের দৃশ্য এবং a এর সাথে বস্তুগত সমষ্টিগত দৃষ্টিভঙ্গি GROUP BY সূচী-সংগঠিত টেবিল থেকে ধারা নির্বাচন করা যাবে না।

5.3.8.5 শুধুমাত্র যোগদানের সাথে উপাদানযুক্ত দৃশ্যগুলিতে দ্রুত রিফ্রেশের উপর বিধিনিষেধ

শুধুমাত্র যোগদানের সাথে বস্তুগত দৃষ্টিভঙ্গির জন্য প্রশ্ন সংজ্ঞায়িত করা এবং কোনো সমষ্টির দ্রুত রিফ্রেশের উপর নিম্নলিখিত বিধিনিষেধ নেই:

• "এর থেকে সমস্ত বিধিনিষেধদ্রুত রিফ্রেশের উপর সাধারণ বিধিনিষেধ"।
• তারা থাকতে পারে না GROUP BY ধারা বা সমষ্টি।
• সমস্ত টেবিলের রউইড FROM তালিকায় উপস্থিত হওয়া আবশ্যক SELECT প্রশ্নের তালিকা।
• সমস্ত বেস টেবিলের জন্য রউইড সহ উপাদানযুক্ত ভিউ লগগুলি অবশ্যই উপস্থিত থাকতে হবে৷ FROM প্রশ্নের তালিকা।
• আপনি সহজ যোগদান সহ একাধিক টেবিল থেকে একটি দ্রুত রিফ্রেশযোগ্য বস্তুগত দৃশ্য তৈরি করতে পারবেন না যাতে একটি অবজেক্ট টাইপ কলাম অন্তর্ভুক্ত থাকে SELECT বিবৃতি।

এছাড়াও, আপনার বেছে নেওয়া রিফ্রেশ পদ্ধতিটি সর্বোত্তমভাবে কার্যকর হবে না যদি:

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

5.3.8.6 এগ্রিগেট সহ উপাদানযুক্ত দৃশ্যগুলিতে দ্রুত রিফ্রেশের উপর বিধিনিষেধ

সমষ্টি বা যোগদানের সাথে বস্তুগত দৃষ্টিভঙ্গির জন্য সংজ্ঞায়িত প্রশ্নগুলির দ্রুত রিফ্রেশের উপর নিম্নলিখিত সীমাবদ্ধতা রয়েছে:

• "এর থেকে সমস্ত বিধিনিষেধদ্রুত রিফ্রেশের উপর সাধারণ বিধিনিষেধ"।

উভয়ের জন্য দ্রুত রিফ্রেশ সমর্থিত ON COMMIT এবং ON DEMAND বস্তুগত মতামত, তবে নিম্নলিখিত বিধিনিষেধ প্রযোজ্য:

• বস্তুগত দৃশ্যের সমস্ত টেবিলে অবশ্যই বস্তুগত ভিউ লগ থাকতে হবে এবং বস্তুগত ভিউ লগগুলি অবশ্যই:
  • বস্তুগত দৃশ্যে উল্লেখ করা টেবিল থেকে সমস্ত কলাম রয়েছে।
  • দিয়ে উল্লেখ করুন ROWID এবং INCLUDING NEW VALUES.
  • উল্লেখ SEQUENCE ধারা যদি টেবিলে সন্নিবেশ/ডাইরেক্ট-লোড, মুছে ফেলা এবং আপডেটের মিশ্রণের আশা করা হয়।

• কেবল SUM, COUNT, AVG, STDDEV, VARIANCE, MIN এবং MAX দ্রুত রিফ্রেশ জন্য সমর্থিত.
• COUNT(*) নির্দিষ্ট করা আবশ্যক।
• সমষ্টিগত ফাংশন শুধুমাত্র অভিব্যক্তির বাইরের অংশ হিসাবে ঘটতে হবে। অর্থাৎ সমষ্টি যেমন AVG(AVG(x)) or AVG(x)+ AVG(x) অনুমতি দেওয়া হয় না.
• প্রতিটি সমষ্টির জন্য যেমন AVG(expr), অনুরূপ COUNT(expr) উপস্থিত থাকতে হবে। ওরাকল যে সুপারিশ SUM(expr) নির্দিষ্ট করা।
• If VARIANCE(expr) or STDDEV(expr) উল্লিখিত আছে, COUNT(expr) এবং SUM(expr) নির্দিষ্ট করা আবশ্যক। ওরাকল যে সুপারিশ SUM(expr *expr) নির্দিষ্ট করা।
• সার্জারির SELECT সংজ্ঞায়িত কোয়েরির কলাম একাধিক বেস টেবিলের কলাম সহ একটি জটিল অভিব্যক্তি হতে পারে না। এটির একটি সম্ভাব্য সমাধান হল একটি নেস্টেড বস্তুগত দৃশ্য ব্যবহার করা।
• সার্জারির SELECT তালিকায় সব থাকতে হবে GROUP BY কলাম.
• বস্তুগত দৃশ্য এক বা একাধিক দূরবর্তী টেবিলের উপর ভিত্তি করে নয়।
• আপনি যদি একটি ব্যবহার CHAR ম্যাটেরিয়ালাইজড ভিউ লগের ফিল্টার কলামে ডেটা টাইপ, মাস্টার সাইটের ক্যারেক্টার সেট এবং ম্যাটেরিয়ালাইজড ভিউ অবশ্যই একই হতে হবে।
• যদি বস্তুগত দৃশ্যে নিম্নলিখিতগুলির মধ্যে একটি থাকে, তবে দ্রুত রিফ্রেশ শুধুমাত্র প্রচলিত DML সন্নিবেশ এবং সরাসরি লোডগুলিতে সমর্থিত।
  • সঙ্গে বস্তুগত মতামত MIN or MAX সমষ্টি
  • বস্তুগত মতামত যা আছে SUM(expr) কিন্তু না COUNT(expr)
  • ছাড়া বস্তুগত দৃশ্য COUNT(*)

  এই ধরনের একটি বস্তুগত দৃশ্য একটি সন্নিবেশ শুধুমাত্র বস্তুগত দৃশ্য বলা হয়.

• সঙ্গে একটি বস্তুগত দৃশ্য MAX or MIN ডিলিট বা মিশ্রিত ডিএমএল স্টেটমেন্টের পরে দ্রুত রিফ্রেশ করা যায় যদি এটি না থাকে WHERE দফা।
  ডিলিট বা মিশ্রিত ডিএমএল পরে সর্বাধিক/মিনিট দ্রুত রিফ্রেশ শুধুমাত্র সন্নিবেশ ক্ষেত্রের মত একই আচরণ নেই। এটি প্রভাবিত গোষ্ঠীর জন্য সর্বোচ্চ/মিনিট মান মুছে ফেলে এবং পুনরায় গণনা করে। আপনাকে এর কর্মক্ষমতা প্রভাব সম্পর্কে সচেতন হতে হবে।
• তে নামযুক্ত ভিউ বা সাবকোয়েরি সহ বস্তুগত দৃষ্টিভঙ্গি FROM ধারাটি দ্রুত রিফ্রেশ করা যেতে পারে যদি দৃশ্যগুলি সম্পূর্ণরূপে একত্রিত করা যায়। কোন ভিউ একত্রিত হবে তার তথ্যের জন্য, দেখুন ওরাকল ডাটাবেস SQL ভাষা রেফারেন্স.
• যদি কোন বহিরাগত যোগদান না থাকে, তাহলে আপনি নির্বিচারে নির্বাচন করতে পারেন এবং যোগদান করতে পারেন WHERE দফা।
• বাহ্যিক যোগদানের সাথে বস্তুগত সমষ্টিগত দৃশ্যগুলি প্রচলিত DML এবং সরাসরি লোডের পরে দ্রুত রিফ্রেশযোগ্য, শুধুমাত্র বাইরের টেবিলটি পরিবর্তন করা হয়েছে। এছাড়াও, অভ্যন্তরীণ যোগদান টেবিলের যোগদানের কলামগুলিতে অনন্য সীমাবদ্ধতা থাকতে হবে। যদি বাইরের যোগসূত্র থাকে, তাহলে সমস্ত যোগ অবশ্যই দ্বারা সংযুক্ত হতে হবে ANDs এবং সমতা ব্যবহার করতে হবে (=) অপারেটর.
• সঙ্গে বস্তুগত মতামত জন্য CUBE, ROLLUP, গ্রুপিং সেট, বা তাদের সংযোজন, নিম্নলিখিত বিধিনিষেধ প্রযোজ্য:
  • সার্জারির SELECT তালিকায় গ্রুপিং ডিস্টিংগুইশার থাকা উচিত যা হয় একটি হতে পারে GROUPING_ID সকলের উপর ফাংশন GROUP BY অভিব্যক্তি বা GROUPING প্রতিটি জন্য একটি ফাংশন GROUP BY অভিব্যক্তি উদাহরণস্বরূপ, যদি GROUP BY বস্তুগত দৃষ্টিভঙ্গির ধারা হল "GROUP BY CUBE(a, b)", এরপর SELECT তালিকায় যেকোনো একটি থাকতে হবেGROUPING_ID(a, b)"বা"GROUPING(a) AND GROUPING(b)» বস্তুগত দৃষ্টিভঙ্গি দ্রুত রিফ্রেশযোগ্য হওয়ার জন্য।
  • GROUP BY কোনো ডুপ্লিকেট গ্রুপিং এর ফলে হবে না. উদাহরণ স্বরূপ, "GROUP BY a, ROLLUP(a, b)"দ্রুত রিফ্রেশযোগ্য নয় কারণ এর ফলে ডুপ্লিকেট গ্রুপিং হয়"(a), (a, b), AND (a)"।

5.3.8.7 UNION ALL এর সাথে বস্তুগত দৃষ্টিভঙ্গিতে দ্রুত রিফ্রেশের উপর বিধিনিষেধ

সঙ্গে বস্তুগত মতামত UNION ALL সেট অপারেটর সমর্থন REFRESH FAST নিম্নলিখিত শর্তগুলি সন্তুষ্ট হলে বিকল্প:

• সংজ্ঞায়িত ক্যোয়ারী থাকতে হবে UNION ALL শীর্ষ স্তরে অপারেটর।

  সার্জারির UNION ALL অপারেটর একটি সাবকোয়েরির ভিতরে এম্বেড করা যাবে না, একটি ব্যতিক্রম সহ: The UNION ALL একটি subquery মধ্যে হতে পারে FROM ধারা প্রদত্ত সংজ্ঞায়িত প্রশ্নটি ফর্মের SELECT * FROM (এর সাথে দেখুন বা সাবকোয়েরি করুন UNION ALL) নিম্নলিখিত উদাহরণ হিসাবে:

  ভিউ ভিউ তৈরি করুন_সহ_ইউনিয়নঅল AS
  (সিলেক্ট করুন c.rowid crid, c.cust_id, 2 umarker
   গ্রাহকদের কাছ থেকে c কোথায় c.cust_last_name = 'Smith'
   ইউনিয়ন সব
   সিলেক্ট করুন c.rowid crid, c.cust_id, 3 umarker
   গ্রাহকদের কাছ থেকে c কোথায় c.cust_last_name = 'জোনস');
  
  উপাদানযুক্ত ভিউ unionall_inside_view_mv তৈরি করুন
  চাহিদা অনুযায়ী দ্রুত রিফ্রেশ করুন
  নির্বাচন করুন * FROM view_with_unionall;
  

  উল্লেখ্য যে ভিউ view_with_unionall দ্রুত রিফ্রেশ জন্য প্রয়োজনীয়তা সন্তুষ্ট.

• প্রতিটি প্রশ্ন ব্লক UNION ALL ক্যোয়ারী অবশ্যই সমষ্টি সহ একটি দ্রুত রিফ্রেশযোগ্য বস্তুগত দৃশ্য বা যোগদানের সাথে একটি দ্রুত রিফ্রেশযোগ্য বস্তুগত দৃশ্যের প্রয়োজনীয়তা পূরণ করতে হবে।

  সংশ্লিষ্ট ধরনের দ্রুত রিফ্রেশেবল ম্যাটেরিয়ালাইজড ভিউয়ের জন্য প্রয়োজনীয় ম্যাটেরিয়ালাইজড ভিউ লগগুলি টেবিলে তৈরি করতে হবে।
  উল্লেখ্য যে ওরাকল ডাটাবেস শুধুমাত্র যোগদান সহ একটি একক টেবিল বাস্তবায়িত দৃশ্যের বিশেষ ক্ষেত্রে অনুমতি দেয় ROWID কলাম অন্তর্ভুক্ত করা হয়েছে SELECT তালিকা এবং বস্তুগত ভিউ লগ ইন. এটি দৃশ্যের সংজ্ঞায়িত ক্যোয়ারীতে দেখানো হয়েছে view_with_unionall.

• সার্জারির SELECT প্রতিটি প্রশ্নের তালিকা একটি অন্তর্ভুক্ত করা আবশ্যক UNION ALL চিহ্নিতকারী, এবং UNION ALL কলামের প্রতিটিতে একটি স্বতন্ত্র ধ্রুবক সংখ্যা বা স্ট্রিং মান থাকতে হবে UNION ALL শাখা আরও, মার্কার কলামটি অবশ্যই একই অর্ডিন্যাল অবস্থানে উপস্থিত হবে SELECT প্রতিটি ক্যোয়ারী ব্লকের তালিকা। দেখা "UNION সমস্ত মার্কার এবং প্রশ্ন পুনর্লিখন» সংক্রান্ত আরও তথ্যের জন্য UNION ALL চিহ্নিতকারী
• কিছু বৈশিষ্ট্য যেমন বাইরের যোগদান, সন্নিবেশ-শুধুমাত্র সামগ্রিক বস্তুগত দৃষ্টিভঙ্গি প্রশ্ন এবং দূরবর্তী টেবিলগুলি বাস্তবায়িত দর্শনের জন্য সমর্থিত নয় UNION ALL. উল্লেখ্য, যাইহোক, প্রতিলিপিতে ব্যবহৃত বস্তুগত দৃষ্টিভঙ্গি, যাতে যোগ বা সমষ্টি থাকে না, দ্রুত রিফ্রেশ করা যায় যখন UNION ALL বা দূরবর্তী টেবিল ব্যবহার করা হয়.
• এর সাথে একটি দ্রুত রিফ্রেশযোগ্য বস্তুগত দৃশ্য তৈরি করতে সামঞ্জস্য শুরু করার পরামিতি অবশ্যই 9.2.0 বা উচ্চতর সেট করতে হবে UNION ALL.

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

মাইক্রোসফট SQL সার্ভার

অতিরিক্ত আবশ্যক

SET বিকল্প এবং নির্ধারক ফাংশন প্রয়োজনীয়তা ছাড়াও, নিম্নলিখিত প্রয়োজনীয়তা পূরণ করা আবশ্যক:

• ব্যবহারকারী যে চালান CREATE INDEX দৃশ্যের মালিক হতে হবে।
• আপনি যখন সূচক তৈরি করেন, তখন IGNORE_DUP_KEY বিকল্পটি বন্ধ (ডিফল্ট সেটিং) সেট করা আবশ্যক।
• টেবিল দুটি অংশের নাম দ্বারা উল্লেখ করা আবশ্যক, পরিকল্পনা.টেবিলের নাম ভিউ সংজ্ঞায়।
• ভিউতে উল্লেখ করা ব্যবহারকারী-সংজ্ঞায়িত ফাংশন ব্যবহার করে তৈরি করতে হবে WITH SCHEMABINDING বিকল্প।
• ভিউতে উল্লেখ করা যেকোনো ব্যবহারকারী-সংজ্ঞায়িত ফাংশন অবশ্যই দুই-অংশের নাম দ্বারা উল্লেখ করা উচিত, ..
• একটি ব্যবহারকারী-সংজ্ঞায়িত ফাংশনের ডেটা অ্যাক্সেস বৈশিষ্ট্য হতে হবে NO SQL, এবং বহিরাগত অ্যাক্সেস সম্পত্তি হতে হবে NO.
• কমন ল্যাঙ্গুয়েজ রানটাইম (CLR) ফাংশন ভিউয়ের সিলেক্ট লিস্টে উপস্থিত হতে পারে, কিন্তু ক্লাস্টারড ইনডেক্স কী-এর সংজ্ঞার অংশ হতে পারে না। CLR ফাংশন দৃশ্যের WHERE ক্লজে বা ভিউতে যোগদান অপারেশনের অন ক্লজে উপস্থিত হতে পারে না।
• ভিউ সংজ্ঞায় ব্যবহৃত CLR ব্যবহারকারী-সংজ্ঞায়িত প্রকারের CLR ফাংশন এবং পদ্ধতিগুলির বৈশিষ্ট্যগুলি অবশ্যই নিম্নলিখিত টেবিলে দেখানো হয়েছে।

  সম্পত্তি
  বিঃদ্রঃ

  ডিটারমিনিস্টিক = সত্য
  Microsoft .NET ফ্রেমওয়ার্ক পদ্ধতির একটি বৈশিষ্ট্য হিসাবে স্পষ্টভাবে ঘোষণা করা আবশ্যক।

  যথার্থ = সত্য
  .NET ফ্রেমওয়ার্ক পদ্ধতির একটি বৈশিষ্ট্য হিসাবে স্পষ্টভাবে ঘোষণা করা আবশ্যক।

  ডেটা অ্যাক্সেস = কোন SQL নেই
  DataAccessKind.None-এ DataAccess অ্যাট্রিবিউট এবং SystemDataAccessKind.None-এ SystemDataAccess অ্যাট্রিবিউট সেট করে নির্ধারণ করা হয়।

  বহিরাগত অ্যাক্সেস = না
  CLR রুটিনের জন্য এই প্রপার্টিটি NO তে ডিফল্ট।

• ব্যবহার করে ভিউ তৈরি করতে হবে WITH SCHEMABINDING বিকল্প।
• ভিউটি শুধুমাত্র বেস টেবিল উল্লেখ করতে হবে যা ভিউ হিসাবে একই ডাটাবেসে আছে। ভিউ অন্য মতামত উল্লেখ করতে পারে না.
• ভিউ সংজ্ঞায় SELECT স্টেটমেন্টে নিম্নলিখিত Transact-SQL উপাদানগুলি থাকা উচিত নয়:

  COUNT
  ROWSET ফাংশন (OPENDATASOURCE, OPENQUERY, OPENROWSET, এবং OPENXML)
  OUTER যোগ দেয়(LEFT, RIGHT, বা FULL)

  প্রাপ্ত টেবিল (নির্দিষ্ট দ্বারা সংজ্ঞায়িত a SELECT বিবৃতি মধ্যে FROM ধারা)
  স্ব-যোগদান
  ব্যবহার করে কলাম নির্দিষ্ট করা SELECT * or SELECT <table_name>.*

  DISTINCT
STDEV, STDEVP, VAR, VARP, বা AVG
  কমন টেবিল এক্সপ্রেশন (CTE)

  ভাসা1, পাঠ, ntext, ভাবমূর্তি, এক্সএমএল, বা ফাইলস্ট্রিম কলাম
  সাবকোয়ারি
  OVER ধারা, যা র‌্যাঙ্কিং বা সমষ্টিগত উইন্ডো ফাংশন অন্তর্ভুক্ত করে

  পূর্ণ-পাঠ্য পূর্বাভাস (CONTAINS, FREETEXT)
  SUM ফাংশন যা একটি বাতিলযোগ্য অভিব্যক্তি উল্লেখ করে
  ORDER BY

  CLR ব্যবহারকারী-সংজ্ঞায়িত সমষ্টিগত ফাংশন
  TOP
CUBE, ROLLUP, বা GROUPING SETS অপারেটরদের

  MIN, MAX
UNION, EXCEPT, বা INTERSECT অপারেটরদের
  TABLESAMPLE

  টেবিল ভেরিয়েবল
  OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

  স্পার্স কলাম সেট
  ইনলাইন (TVF) বা মাল্টি-স্টেটমেন্ট টেবিল-ভ্যালুড ফাংশন (MSTVF)
  OFFSET

  CHECKSUM_AGG

  1 ইনডেক্স করা ভিউ থাকতে পারে ভাসা কলাম; যাইহোক, এই ধরনের কলামগুলি ক্লাস্টার ইনডেক্স কী-তে অন্তর্ভুক্ত করা যাবে না।

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

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

ভিউটি শুধুমাত্র বেস টেবিল উল্লেখ করতে হবে যা ভিউ হিসাবে একই ডাটাবেসে আছে। ভিউ অন্য মতামত উল্লেখ করতে পারে না.

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

ভিউ সংজ্ঞায় SELECT স্টেটমেন্টে নিম্নলিখিত Transact-SQL উপাদানগুলি থাকা উচিত নয়:

COUNT
ROWSET ফাংশন (OPENDATASOURCE, OPENQUERY, OPENROWSET, এবং OPENXML)
OUTER যোগ দেয়(LEFT, RIGHT, বা FULL)

প্রাপ্ত টেবিল (নির্দিষ্ট দ্বারা সংজ্ঞায়িত a SELECT বিবৃতি মধ্যে FROM ধারা)
স্ব-যোগদান
ব্যবহার করে কলাম নির্দিষ্ট করা SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARP, বা AVG
কমন টেবিল এক্সপ্রেশন (CTE)

ভাসা1, পাঠ, ntext, ভাবমূর্তি, এক্সএমএল, বা ফাইলস্ট্রিম কলাম
সাবকোয়ারি
OVER ধারা, যা র‌্যাঙ্কিং বা সমষ্টিগত উইন্ডো ফাংশন অন্তর্ভুক্ত করে

পূর্ণ-পাঠ্য পূর্বাভাস (CONTAINS, FREETEXT)
SUM ফাংশন যা একটি বাতিলযোগ্য অভিব্যক্তি উল্লেখ করে
ORDER BY

CLR ব্যবহারকারী-সংজ্ঞায়িত সমষ্টিগত ফাংশন
TOP
CUBE, ROLLUP, বা GROUPING SETS অপারেটরদের

MIN, MAX
UNION, EXCEPT, বা INTERSECT অপারেটরদের
TABLESAMPLE

টেবিল ভেরিয়েবল
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

স্পার্স কলাম সেট
ইনলাইন (TVF) বা মাল্টি-স্টেটমেন্ট টেবিল-ভ্যালুড ফাংশন (MSTVF)
OFFSET

CHECKSUM_AGG

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

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

বাস্তবায়ন

কিভাবে এটা কাজ করে? PostgreSQL একটি "ভার্চুয়াল মেশিন" হিসাবে ব্যবহৃত হয়। ভিতরে একটি জটিল অ্যালগরিদম রয়েছে যা প্রশ্ন তৈরি করে। এখানে উৎস. এবং ইফের গুচ্ছ সহ হিউরিস্টিকসের একটি বড় সেট নেই। সুতরাং, আপনার যদি পড়াশোনা করার জন্য মাস দুয়েক থাকে তবে আপনি স্থাপত্য বোঝার চেষ্টা করতে পারেন।

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

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

উত্স: www.habr.com