بيلنس لکڻ ۽ پڙهڻ هڪ ڊيٽابيس ۾

پوئين ۾ مضمون مون هڪ ڊيٽابيس جي تصور ۽ عمل کي بيان ڪيو آهي جيڪو فنڪشن جي بنياد تي ٺاهيو ويو آهي، جدولن ۽ فيلڊن جي بجاءِ جيئن تعلقي ڊيٽابيس ۾. هن ڪيترائي مثال مهيا ڪيا آهن جيڪي هن طريقي جي فائدن کي ظاهر ڪن ٿا ڪلاسيڪل هڪ تي. ڪيترن ئي انهن کي ڪافي قائل نه مليو.

هن آرٽيڪل ۾، مان ڏيکاريندس ته هي تصور توهان کي جلدي ۽ آساني سان ڊيٽابيس ۾ لکڻ ۽ پڙهڻ کي توازن ڪرڻ جي اجازت ڏئي ٿو بغير آپريٽنگ منطق ۾ ڪنهن به تبديلي جي. ساڳي ڪارڪردگي کي جديد تجارتي ڊي بي ايم ايس ۾ لاڳو ڪرڻ جي ڪوشش ڪئي وئي آهي (خاص طور تي، Oracle ۽ 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);


ڪنهن به DBMS ۾ هن سوال تي عمل ڪرڻ جي پيچيدگي جي برابر هوندي O (ملازمن جو تعداد)ڇاڪاڻ ته هن حساب ڪتاب لاءِ ملازمن جي پوري ٽيبل کي اسڪين ڪرڻ ۽ پوءِ انهن کي ڊپارٽمينٽ طرفان گروپ ڪرڻ جي ضرورت آهي. اتي به ڪجھ ننڍا آھن (اسان يقين رکون ٿا ته ڊپارٽمنٽ کان وڌيڪ ملازم آھن) چونڊيل منصوبي تي منحصر آھي O (ملازمن جو لاگ نمبر) يا اي (ڊپارٽمنٽ جو تعداد) گروپنگ وغيره لاءِ.

اهو واضح آهي ته مختلف ڊي بي ايم ايسز ۾ عمل جي اوور هيڊ مختلف ٿي سگهي ٿي، پر پيچيدگي ڪنهن به طريقي سان تبديل نه ٿيندي.

تجويز ڪيل عمل ۾، فنڪشنل DBMS ھڪڙو ذيلي سوال ٺاھيندو جيڪو ڊپارٽمينٽ لاءِ گھربل قدرن جو حساب ڪندو، ۽ پوءِ نالو حاصل ڪرڻ لاءِ ڊپارٽمينٽ ٽيبل سان شامل ٿيو. جڏهن ته، هر فنڪشن لاء، جڏهن اعلان ڪيو وڃي، اهو ممڪن آهي ته هڪ خاص مادي مارڪر مقرر ڪيو وڃي. سسٽم خودڪار طريقي سان هر اهڙي فنڪشن لاء هڪ لاڳاپيل فيلڊ ٺاهيندو. جڏهن هڪ فنڪشن جي قيمت کي تبديل ڪندي، فيلڊ جي قيمت پڻ ساڳئي ٽرانزيڪشن ۾ تبديل ٿيندي. جڏهن هن فنڪشن تائين رسائي، اڳ-ڳڻپيويل فيلڊ تائين رسائي ڪئي ويندي.

خاص طور تي، جيڪڏھن توھان سيٽ ڪريو MATERIALIZED افعال لاءِ ملازمن جي ڳڻپ и پگهار جي رقم، پوءِ ٽيبل تي ٻه شعبا شامل ڪيا ويندا شعبن جي فهرست سان، جيڪي ملازمن جو تعداد ۽ انهن جي ڪل تنخواه کي محفوظ ڪندا. جڏهن به ملازمن، انهن جي تنخواه يا ڊپارٽمينٽ جي وابستگي ۾ تبديلي ايندي، سسٽم پاڻمرادو انهن شعبن جي قدرن کي تبديل ڪندو. مٿي ڏنل سوال انهن شعبن تائين سڌو سنئون ۽ ان تي عمل ڪيو ويندو اي (ڊپارٽمنٽ جو تعداد).

پابنديون ڇا آهن؟ صرف هڪ شيءِ: اهڙي فنڪشن ۾ ان پٽ ويلز جو هڪ محدود تعداد هجڻ ضروري آهي جنهن لاءِ ان جي قدر بيان ڪئي وئي آهي. ٻي صورت ۾، اهو ناممڪن ٿي ويندو ته هڪ ٽيبل ٺاهيو جيڪو ان جي سڀني قدرن کي محفوظ ڪري، ڇاڪاڻ ته اتي قطارن جي لامحدود تعداد سان ٽيبل نه ٿي سگهي.

مثال طور

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;


سسٽم پاڻ کي ٽائيپ ڪنجين سان ھڪڙي ٽيبل ٺاھيندو ڪسٽمر, پراڊڪٽ и انٽرويو، ان ۾ ٻه شعبا شامل ڪندو ۽ انھن ۾ فيلڊ ويلز کي اپڊيٽ ڪندو ڪنھن به تبديلي سان. جڏهن انهن ڪمن کي وڌيڪ ڪالون ڪيون وينديون آهن، انهن کي حساب نه ڪيو ويندو، بلڪه انهن جي قيمتن کي لاڳاپيل فيلڊ مان پڙهيو ويندو.

هن ميکانيزم کي استعمال ڪندي، توهان ڪري سگهو ٿا، مثال طور، سوالن ۾ recursions (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;


کان وٺي فنڪشن لاء والدين آهي 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;


جڏهن هڪ فنڪشن سڏڻ تاريخ آرڊر لائن لاءِ، فيلڊ جنهن لاءِ هڪ انڊيڪس موجود آهي ٽيبل مان آرڊر لائينن سان پڙهيو ويندو. جڏهن آرڊر جي تاريخ تبديل ٿيندي، سسٽم پاڻمرادو پاڻمرادو لڪير ۾ غير معمولي تاريخ کي ٻيهر ڳڻپ ڪندو.

فائدن

هي سڄو ميکانيزم ڇا لاءِ آهي؟ کلاسک DBMSs ۾، سوالن کي ٻيهر لکڻ جي بغير، هڪ ڊولپر يا DBA صرف انڊيڪس تبديل ڪري سگهي ٿو، انگ اکر جو تعين ڪري سگهي ٿو ۽ سوال جي رٿابندي ڪندڙ کي ٻڌائي سگهي ٿو ته انهن کي ڪيئن عمل ڪجي (۽ HINTs صرف تجارتي DBMSs ۾ موجود آهن). اهي ڪيترو به ڪوشش ڪن، اهي مضمون ۾ پهريون سوال مڪمل نه ڪري سگهندا اي (ڊپارٽمنٽ جو تعداد) بغير سوالن کي تبديل ڪرڻ يا ٽارگيٽ شامل ڪرڻ کان سواء. تجويز ڪيل اسڪيم ۾، ترقي جي مرحلي تي توهان کي سوچڻ جي ضرورت ناهي ته ڊيٽا اسٽوريج جي جوڙجڪ ۽ ڪهڙي مجموعي کي استعمال ڪرڻ لاء. هي سڀ آساني سان اڏامي تي تبديل ڪري سگهجي ٿو، سڌو آپريشن ۾.

عملي طور تي اهو هن وانگر ڏسڻ ۾ اچي ٿو. ڪجهه ماڻهو منطق کي سڌو سنئون هٿ تي ڪم جي بنياد تي ٺاهيندا آهن. اھي نه سمجھندا آھن الگورتھم ۽ انھن جي پيچيدگي، نڪي عمل جي منصوبا، نڪي شامل ٿيڻ جا قسم، ۽ نڪي ڪو ٻيو ٽيڪنيڪل جزو. اهي ماڻهو ڊولپرز کان وڌيڪ ڪاروباري تجزيه نگار آهن. پوء، اهو سڀ ڪجهه جاچ يا آپريشن ۾ وڃي ٿو. ڊگھي هلندڙ سوالن جي لاگنگ کي فعال ڪري ٿو. جڏهن هڪ ڊگهو سوال معلوم ٿئي ٿو، پوء ٻيا ماڻهو (وڌيڪ ٽيڪنيڪل - بنيادي طور تي DBA) ڪجهه وچولي فنڪشن تي مواد کي فعال ڪرڻ جو فيصلو ڪن ٿا. اهو ٿورڙي رڪارڊنگ کي سست ڪري ٿو (ڇاڪاڻ ته ان کي ٽرانزيڪشن ۾ اضافي فيلڊ کي اپڊيٽ ڪرڻ جي ضرورت آهي). بهرحال، نه رڳو اهو سوال خاص طور تي تيز ڪيو ويو آهي، پر ٻيا سڀئي جيڪي هن فنڪشن کي استعمال ڪن ٿا. ساڳي ئي وقت، فيصلو ڪرڻ جو ڪهڙو ڪم مادي ڪرڻ لاء نسبتا آسان آهي. ٻه مکيه پيٽرولر: ممڪن ان پٽ جي قيمتن جو تعداد (اها آهي ڪيترا رڪارڊ لاڳاپيل جدول ۾ هوندا)، ۽ ڪيترا ڀيرا اهو ٻين ڪمن ۾ استعمال ٿيندو آهي.

اينالاگ

جديد تجارتي ڊي بي ايم ايس ۾ ساڳيون ميڪانيزم آهن: فاسٽ ريفريش (Oracle) ۽ INDEXED VIEW (Microsoft SQL Server). PostgreSQL ۾، مواد جو ڏيک هڪ ٽرانزيڪشن ۾ اپڊيٽ نه ٿي ڪري سگھجي، پر صرف درخواست تي (۽ جيتوڻيڪ تمام سخت پابنديون سان)، تنهنڪري اسان ان تي غور نه ڪندا آهيون. پر انهن وٽ ڪيترائي مسئلا آهن جيڪي خاص طور تي انهن جي استعمال کي محدود ڪن ٿا.

پهرين، توهان صرف مواد کي فعال ڪري سگهو ٿا جيڪڏهن توهان اڳ ۾ ئي هڪ باقاعده VIEW ٺاهي ڇڏيو آهي. ٻي صورت ۾، توهان کي هن مواد کي استعمال ڪرڻ لاء نئين ٺاهيل منظر تائين رسائي حاصل ڪرڻ لاء باقي درخواستن کي ٻيهر لکڻو پوندو. يا سڀڪنھن شيء کي ڇڏي ڏيو جيئن اھو آھي، پر اھو گھٽ ۾ گھٽ غير اثرائتو ٿيندو جيڪڏھن ڪجھ اڳ ۾ ئي اڳ ۾ حساب ٿيل ڊيٽا آھي، پر ڪيترائي سوال هميشه ان کي استعمال نٿا ڪن، پر ان کي ٻيهر ڳڻپيو.

ٻيو، انهن وٽ وڏي تعداد ۾ پابنديون آهن:

Oracle

5.3.8.4 فاسٽ ريفريش تي عام پابنديون

مادي ٿيل نظر جي وضاحت ڪندڙ سوال هن ريت محدود آهي:

• مادي ٿيل ڏيک ۾ لازمي طور تي غير ورجائيندڙ اظهار جي حوالن تي مشتمل نه هجڻ گهرجي جهڙوڪ SYSDATE ۽ ROWNUM.
• مادي ٿيل ڏيک ۾ حوالو نه هجڻ گهرجي RAW or LONG RAW ڊيٽا جا قسم.
• اهو شامل نه ٿو ڪري سگھجي a SELECT فهرست ذيلي سوال.
• ان ۾ تجزياتي افعال شامل نه ٿي سگھي (مثال طور، RANK) ۾ SELECT شق.
• اهو هڪ ٽيبل جو حوالو نٿو ڏئي سگهي جنهن تي هڪ XMLIndex انڊيڪس جي وضاحت ڪئي وئي آهي.
• اهو شامل نه ٿو ڪري سگھجي a MODEL شق.
• اهو شامل نه ٿو ڪري سگھجي a HAVING ذيلي سوال سان شق.
• اهو nested سوالن تي مشتمل نه ٿو ٿي سگھي ANY, ALL، يا NOT EXISTS.
• اهو شامل نه ٿو ڪري سگھجي a [START WITH …] CONNECT BY شق.
• اهو مختلف سائيٽن تي ڪيترن ئي تفصيلي جدولن تي مشتمل نه ٿي سگھي.
• ON COMMIT مادي نظرين ۾ ريموٽ تفصيلي ٽيبل نه هوندا.
• Nested materialized views ۾ هڪ جوڙ يا مجموعي هجڻ لازمي آهي.
• A GROUP BY شق هڪ انڊيڪس-منظم ٿيل ٽيبل مان چونڊي نه ٿي سگهي.

5.3.8.5 فاسٽ ريفريش تي پابنديون صرف شامل ٿيڻ سان گڏ مادي ٿيل نظارن تي

وضاحتي سوالن لاءِ مادي نظرين لاءِ صرف شامل ٿيڻ سان ۽ ڪو به مجموعو فاسٽ ريفريش تي هيٺيون پابنديون نه آهن:

• سڀ پابنديون "فاسٽ ريفريش تي عام پابنديون".
• اهي نه ٿا ڪري سگهن GROUP BY شقون يا مجموعا.
• ۾ سڀني ٽيبلن جون قطارون FROM فهرست ۾ ظاهر ٿيڻ گهرجي SELECT سوال جي فهرست.
• ۾ موجود سڀني بنيادي جدولن لاءِ rowids سان گڏ مواد جي ڏيک جا لاگ موجود هجڻ گهرجن 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) موجود هجڻ ضروري آهي. Oracle سفارش ڪري ٿو SUM(expr) بيان ڪيو وڃي.
• If VARIANCE(expr) or STDDEV(exprبيان ڪيو ويو آهي، COUNT(expr) ۽ SUM(expr) بيان ڪيو وڃي. Oracle سفارش ڪري ٿو SUM(expr *expr) بيان ڪيو وڃي.
• هن SELECT وضاحتي سوال ۾ ڪالم ڪيترن ئي بنيادي جدولن جي ڪالمن سان گڏ پيچيده اظهار نه ٿي سگھي. ھن لاء ھڪڙو ممڪن حل آھي ھڪڙو نسٽڊ مادي ٿيل نظارو استعمال ڪرڻ.
• هن SELECT فهرست سڀني تي مشتمل هجڻ گهرجي GROUP BY ڪالمن.
• مادي ٿيل ڏيک هڪ يا وڌيڪ ريموٽ ٽيبل تي ٻڌل ناهي.
• جيڪڏهن توهان هڪ استعمال ڪريو ٿا CHAR فلٽر ڪالمن ۾ ڊيٽا جو قسم هڪ مادي ٿيل ڏيک لاگ لاگ ۾، ماسٽر سائيٽ جي ڪردارن جو سيٽ ۽ مادي ٿيل ڏيک ساڳيو هجڻ گهرجي.
• جيڪڏهن مادي ڏسڻ ۾ هيٺ ڏنل مان هڪ آهي، پوء تيز ريفريش صرف روايتي DML داخل ڪرڻ ۽ سڌو لوڊ ڪرڻ تي سپورٽ ڪئي وئي آهي.
  • سان گڏ مادي نظريا MIN or MAX مجموعو
  • مادي نظريا جيڪي آهن SUM(expr) پر نه COUNT(expr)
  • بغير مواد جي نظارن COUNT(*)

  اهڙي مادي نظر کي صرف داخل ڪرڻ واري مادي نظر کي سڏيو ويندو آهي.

• هڪ مادي نظر سان MAX or MIN ڊليٽ يا مخلوط ڊي ايم ايل بيانن کان پوء جلدي ريفريش ٿي سگھي ٿو جيڪڏھن اھو نه آھي WHERE شق.
  وڌ ۾ وڌ / منٽ فاسٽ ريفريش ڪرڻ کان پوءِ حذف ڪرڻ يا ملايو DML وٽ ساڳيو رويو نه آهي جيئن صرف داخل ٿيل ڪيس. اهو حذف ڪري ٿو ۽ متاثر ٿيل گروپن لاءِ وڌ کان وڌ / منٽ جي قيمتن کي ٻيهر ترتيب ڏئي ٿو. توهان کي ان جي ڪارڪردگي جي اثر کان واقف ٿيڻ جي ضرورت آهي.
• ۾ نامزد نظارن يا ذيلي سوالن سان گڏ مادي نظريا FROM شق کي فوري طور تي تازو ڪري سگھجي ٿو بشرطيڪ نظرن کي مڪمل طور تي ملائي سگھجي. معلومات لاءِ ڪهڙا نظارا ملندا، ڏسو Oracle Database SQL Language Reference.
• جيڪڏهن ڪو به ٻاهران شامل نه آهي، توهان کي شايد صوابديدي چونڊون هجن ۽ ۾ شامل ٿين WHERE شق.
• ٻاهرئين جوڙ سان گڏ مادي ٿيل مجموعي نظارا روايتي DML ۽ سڌو لوڊ ڪرڻ کان پوءِ تيزي سان ريفريش هوندا آهن، بشرطيڪ صرف ٻاهرين ٽيبل کي تبديل ڪيو ويو هجي. ان سان گڏ، اندروني شامل ٿيڻ واري ٽيبل جي شامل ڪالمن تي منفرد رڪاوٽون موجود هجڻ گهرجن. جيڪڏهن ٻاهريون ڳنڍيون آهن، ته سڀئي ڳنڍيون ضرور ڳنڍيل هجن ANDs ۽ برابري استعمال ڪرڻ گهرجي (=) آپريٽر.
• سان گڏ مادي خيالن لاء CUBE, ROLLUP, گروپن جي سيٽ، يا انهن جي ڪنٽينشن، هيٺيون پابنديون لاڳو ٿين ٿيون:
  • هن SELECT فهرست ۾ شامل ٿيڻ گهرجي گروپنگ فرق ڪندڙ جيڪو يا ته ٿي سگهي ٿو a 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) جيئن هيٺ ڏنل مثال ۾:

  CREATE VIEW view_with_unionall AS (Create C.rowid crid, c.cust_id, 2 umarker from customers c WHERE c.cust_last_name = 'Smith' UNION ALL SELECT c.rowid crid, c.cust_id, 3 umarker from customers c.where c_last_name. 'جونز')؛ مواد ٺاهي ڏسو unionall_inside_view_mv ريفريش فاسٽ آن ڊيمانڊ جيئن چونڊيو * FROM view_with_unionall؛
  

  نوٽ ڪريو ته نظارو view_with_unionall فاسٽ ريفريش جي ضرورتن کي پورو ڪري ٿو.

• هر سوال بلاڪ ۾ UNION ALL سوال کي لازمي طور تي مجموعن سان گڏ تيز ريفريشبل مادي ٿيل ڏيک جي ضرورتن کي پورو ڪرڻ گهرجي يا جوائن سان گڏ تيز ريفريشبل مادي ڏيک.

  مناسب مادي ٿيل ڏيک لاگز لازمي طور تي جدولن تي ٺاهيا وڃن جيئن گهربل قسم جي تيز ريفريشبل مادي ڏسڻ لاءِ.
  نوٽ ڪريو ته Oracle Database پڻ اجازت ڏئي ٿو خاص صورت ۾ ھڪڙي جدول جي مادي ٿيل ڏيک سان گڏ صرف مهيا ڪيل ROWID ڪالم ۾ شامل ڪيو ويو آهي SELECT فهرست ۽ مادي ڏسڻ واري لاگ ۾. اهو ڏسڻ جي وضاحت واري سوال ۾ ڏيکاريل آهي view_with_unionall.

• هن SELECT هر سوال جي فهرست ۾ شامل ٿيڻ گهرجي a UNION ALL مارڪر، ۽ UNION ALL ڪالمن ۾ هر هڪ ۾ هڪ الڳ مستقل عددي يا اسٽرنگ ويل هجڻ لازمي آهي UNION ALL شاخ. ان کان علاوه، مارڪر ڪالمن کي ساڳئي ترتيب واري پوزيشن ۾ ظاهر ٿيڻ گهرجي SELECT هر سوال جي بلاڪ جي فهرست. ڏسو ”يونين سڀ مارڪر ۽ سوال ٻيهر لکندا» جي حوالي سان وڌيڪ معلومات لاء UNION ALL نشان ھڻڻ وارا.
• ڪجھ خاصيتون جيئن ته ٻاهرين شامل ٿيڻ، صرف داخل ڪرڻ لاء مجموعي طور تي مواد ڏسڻ جي سوالن ۽ ريموٽ جدولن سان گڏ مادي ٿيل ڏسڻ لاء سپورٽ نه آهن. UNION ALL. نوٽ، بهرحال، نقل ۾ استعمال ٿيل مادي نظريا، جن ۾ شامل يا مجموعا شامل نه آهن، تيزي سان ريفريش ٿي سگھن ٿيون جڏهن UNION ALL يا ريموٽ ٽيبل استعمال ٿيل آهن.
• مطابقت جي شروعات جي ماپ کي لازمي طور تي 9.2.0 يا وڌيڪ تي مقرر ڪيو وڃي ته جيئن هڪ تيز ريفريشبل مادي وارو نظارو ٺاهيو وڃي UNION ALL.

مان Oracle جي مداحن کي ناراض ڪرڻ نه ٿو چاهيان، پر انهن جي پابندين جي فهرست کي جانچڻ سان، اهو لڳي ٿو ته اهو ميڪانيزم عام صورت ۾ نه، ڪنهن قسم جي نموني استعمال ڪندي لکيو ويو آهي، پر هزارين هندستانين طرفان، جتي هر ڪنهن کي موقعو ڏنو ويو هو. پنهنجي پنهنجي شاخ لکو، ۽ انهن مان هر هڪ اهو ڪيو جيڪو هو ڪري سگهيو. حقيقي منطق لاءِ هن ميکانيزم کي استعمال ڪرڻ هڪ minefield ذريعي هلڻ وانگر آهي. توهان ڪنهن به وقت غير واضح پابندين مان هڪ کي مارڻ سان هڪ ماين حاصل ڪري سگهو ٿا. اهو ڪيئن ڪم ڪري ٿو اهو پڻ هڪ الڳ سوال آهي، پر اهو هن مضمون جي دائري کان ٻاهر آهي.

Microsoft SQL سرور

اضافي گهربل

SET اختيارن ۽ تعيناتي فنڪشن جي ضرورتن کان علاوه، هيٺين گهرجن کي پورو ڪيو وڃي:

• استعمال ڪندڙ جيڪو عمل ڪري ٿو CREATE INDEX ڏسڻ جو مالڪ هجڻ گهرجي.
• جڏهن توهان انڊيڪس ٺاهيو ٿا، ته IGNORE_DUP_KEY اختيار کي بند ڪرڻ گهرجي (ڊفالٽ سيٽنگ).
• جدولن کي ٻن حصن جي نالن سان حوالي ڪيو وڃي، اسڪيما.ٽيبل جو نالو نظر جي تعريف ۾.
• ڏسڻ ۾ حوالو ڏنو ويو استعمال ڪندڙ جي بيان ڪيل افعال کي استعمال ڪندي ٺاهيو وڃي WITH SCHEMABINDING اختيار.
• ڏسڻ ۾ حوالو ڏنو ويو ڪو به صارف جي بيان ڪيل افعال ٻن حصن جي نالن سان حوالو ڏنو وڃي، ..
• صارف جي بيان ڪيل فنڪشن جي ڊيٽا جي رسائي ملڪيت هجڻ گهرجي NO SQL, ۽ خارجي پهچ ملڪيت هجڻ ضروري آهي NO.
• عام ٻولي رن ٽائم (CLR) افعال ڏسڻ جي چونڊ لسٽ ۾ ظاهر ٿي سگھن ٿا، پر ڪلستر ٿيل انڊيڪس ڪي جي تعريف جو حصو نه ٿي سگھي. CLR فنڪشن ڏسڻ جي WHERE شق ۾ يا ڏسڻ ۾ شامل ٿيڻ واري آپريشن جي ON شق ۾ ظاهر نه ٿي سگھي.
• CLR افعال ۽ طريقن جي CLR استعمال ڪندڙ جي بيان ڪيل قسمن کي ڏسڻ جي تعريف ۾ استعمال ڪيو وڃي ٿو ملڪيت مقرر ڪيل طور تي ھيٺ ڏنل جدول ۾ ڏيکاريل آھي.

  مال
  نوٽ

  مقرر = سچ
  واضح طور تي اعلان ڪيو وڃي Microsoft .NET فريم ورڪ جي هڪ خاصيت جي طور تي.

  درست = سچ
  .NET فريم ورڪ جي طريقي جي خاصيت جي طور تي واضح طور تي اعلان ڪيو وڃي.

  ڊيٽا جي رسائي = ڪو SQL
  DataAccess انتساب DataAccessKind.None ۽ SystemDataAccess انتساب کي SystemDataAccessKind.None کي سيٽ ڪرڻ سان طئي ڪيو ويو آهي.

  خارجي پهچ = نه
  هي ملڪيت 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 فنڪشن جيڪو nullable اظهار جو حوالو ڏئي ٿو
  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 موجود آهي، VIEW جي تعريف ۾ شامل هجڻ ضروري آهي COUNT_BIG(*) ۽ شامل نه هجڻ گهرجي HAVING. اهي GROUP BY پابنديون صرف انڊيڪس ٿيل ڏسڻ جي تعريف تي لاڳو ٿين ٿيون. هڪ سوال ان جي عمل جي منصوبي ۾ هڪ انڊيڪس ٿيل ڏيک استعمال ڪري سگهي ٿو جيتوڻيڪ اهو انهن کي پورو نٿو ڪري GROUP BY پابنديون.
• جيڪڏهن ڏسڻ جي تعريف ۾ الف شامل آهي 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 فنڪشن جيڪو nullable اظهار جو حوالو ڏئي ٿو
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

OUTER Joins, UNION, ORDER BY ۽ ٻيا منع ٿيل آھن. اهو بيان ڪرڻ آسان ٿي سگهي ٿو ته ڇا استعمال ڪري سگهجي ٿو بلڪه ڇا استعمال نه ٿي سگهي. فهرست شايد تمام ننڍو هوندو.

اختصار ڪرڻ لاءِ: هر هڪ ۾ پابندين جو هڪ وڏو سيٽ (اچو ته تجارتي نوٽ ڪريو) DBMS بمقابله ڪو به نه (هڪ منطقي جي استثنا سان، ٽيڪنيڪل نه) LGPL ٽيڪنالاجي ۾. بهرحال، اهو ياد رکڻ گهرجي ته هن ميکانيزم تي عمل ڪرڻ لاڳاپو منطق ۾ بيان ڪيل فنڪشنل منطق جي ڀيٽ ۾ ڪجهه وڌيڪ ڏکيو آهي.

عمل

اهو ڪيئن ڪم ڪري ٿو؟ PostgreSQL هڪ "مجازي مشين" طور استعمال ڪيو ويندو آهي. اندر ھڪڙو پيچيده الگورتھم آھي جيڪو سوالن کي ٺاھي ٿو. هتي ذريعو. ۽ اتي نه آهي صرف heuristics جو هڪ وڏو سيٽ ifs جي هڪ گروپ سان. تنهن ڪري، جيڪڏهن توهان وٽ پڙهڻ لاء ڪجهه مهينا آهن، توهان فن تعمير کي سمجهڻ جي ڪوشش ڪري سگهو ٿا.

ڇا اهو اثرائتو ڪم ڪري ٿو؟ ڪافي اثرائتو. بدقسمتي سان، اهو ثابت ڪرڻ ڏکيو آهي. مان صرف ايترو چئي سگهان ٿو ته جيڪڏهن توهان هزارين سوالن تي غور ڪريو جيڪي وڏين ايپليڪيشنن ۾ موجود آهن، پوءِ سراسري طور تي اهي هڪ سٺي ڊولپر کان وڌيڪ ڪارائتو آهن. هڪ بهترين SQL پروگرامر ڪنهن به سوال کي وڌيڪ موثر انداز ۾ لکي سگهي ٿو، پر هڪ هزار سوالن سان، هن کي صرف اهو ڪرڻ لاءِ ترغيب يا وقت نه هوندو. صرف هڪ شيء جيڪا مان هاڻي اثرائتو ثبوت طور بيان ڪري سگهان ٿو اهو آهي ته ڪيترائي منصوبا ڪم ڪري رهيا آهن پليٽ فارم تي ٺهيل هن DBMS تي. ERP سسٽم, جن ۾ هزارين مختلف MATERIALIZED افعال آهن، هزارين صارفين ۽ ٽيرا بائيٽ ڊيٽابيس سان گڏ سوين لکن رڪارڊن سان گڏ هڪ باقاعده ٻه پروسيسر سرور تي هلندڙ. بهرحال، ڪو به ڊائون لوڊ ڪندي تاثير کي جانچي / رد ڪري سگهي ٿو پليٽ فارم ۽ PostgreSQL، چالو ڪرڻ SQL سوالن کي لاگ ان ڪرڻ ۽ اتي منطق ۽ ڊيٽا کي تبديل ڪرڻ جي ڪوشش ڪئي.

هيٺ ڏنل مضمونن ۾، مان پڻ ڳالهائيندس ته توهان ڪمن تي پابنديون ڪيئن سيٽ ڪري سگهو ٿا، تبديلي سيشن سان ڪم، ۽ گهڻو ڪجهه.

جو ذريعو: www.habr.com