بیلنسنگ ڈیٹا بیس میں لکھتا اور پڑھتا ہے۔

پچھلے میں آرٹیکل میں نے متعلقہ ڈیٹا بیس کی طرح ٹیبلز اور فیلڈز کے بجائے فنکشنز کی بنیاد پر بنائے گئے ڈیٹا بیس کے تصور اور نفاذ کو بیان کیا۔ اس نے بہت سی مثالیں فراہم کی ہیں جو کلاسیکی کے مقابلے میں اس نقطہ نظر کے فوائد کو ظاہر کرتی ہیں۔ بہت سے لوگوں نے انہیں کافی قائل نہیں پایا۔

اس آرٹیکل میں، میں یہ بتاؤں گا کہ یہ تصور آپ کو آپریٹنگ منطق میں بغیر کسی تبدیلی کے ڈیٹا بیس میں لکھنے اور پڑھنے کو تیزی سے اور آسانی سے بیلنس کرنے کی اجازت دیتا ہے۔ اسی طرح کی فعالیت کو جدید تجارتی 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 (محکموں کی تعداد) گروپ بندی وغیرہ کے لیے۔

یہ واضح ہے کہ مختلف DBMSs میں عملدرآمد اوور ہیڈ مختلف ہو سکتا ہے، لیکن پیچیدگی کسی بھی طرح تبدیل نہیں ہوگی۔

مجوزہ نفاذ میں، فنکشنل DBMS ایک ذیلی سوال تیار کرے گا جو ڈیپارٹمنٹ کے لیے مطلوبہ اقدار کا حساب لگائے گا، اور پھر نام حاصل کرنے کے لیے ڈیپارٹمنٹ ٹیبل کے ساتھ جوائن کرے گا۔ تاہم، ہر فنکشن کے لیے، اعلان کرتے وقت، یہ ممکن ہے کہ ایک خاص مادی مارکر مقرر کیا جائے۔ سسٹم خود بخود اس طرح کے ہر فنکشن کے لیے ایک متعلقہ فیلڈ بنائے گا۔ کسی فنکشن کی ویلیو کو تبدیل کرتے وقت، فیلڈ کی ویلیو بھی اسی لین دین میں بدل جائے گی۔ اس فنکشن تک رسائی حاصل کرتے وقت، پہلے سے حساب شدہ فیلڈ تک رسائی حاصل کی جائے گی۔

خاص طور پر، اگر آپ فنکشنز کے لیے میٹریلائزڈ سیٹ کرتے ہیں۔ ملازمین کی تعداد и تنخواہ کی رقم، پھر محکموں کی فہرست کے ساتھ ٹیبل میں دو فیلڈز شامل کیے جائیں گے، جو ملازمین کی تعداد اور ان کی کل تنخواہ کو محفوظ کریں گے۔ جب بھی ملازمین، ان کی تنخواہوں یا محکمانہ وابستگیوں میں کوئی تبدیلی آئے گی، نظام خود بخود ان شعبوں کی اقدار کو تبدیل کر دے گا۔ مندرجہ بالا استفسار ان فیلڈز تک براہ راست رسائی حاصل کرے گا اور اس پر عمل درآمد کیا جائے گا۔ 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 میں، آپ دونوں فنکشنز پر MATERIALIZED ڈال سکتے ہیں:

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 نہیں ہوگا۔ اس کے بجائے ایک سادہ گروپ BY ہوگا۔

اس طریقہ کار کو استعمال کرتے ہوئے، اگر ضروری ہو تو آپ آسانی سے ڈیٹا بیس کو غیر معمولی بنا سکتے ہیں:

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

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


کسی فنکشن کو کال کرتے وقت تاریخ آرڈر لائن کے لیے، جس فیلڈ کے لیے ایک انڈیکس ہے اسے ٹیبل سے آرڈر لائنوں کے ساتھ پڑھا جائے گا۔ جب آرڈر کی تاریخ بدل جاتی ہے، تو سسٹم خود بخود لائن میں غیر معمولی تاریخ کا دوبارہ حساب لگائے گا۔

فوائد

یہ سارا میکنزم کس لیے ہے؟ کلاسک DBMSs میں، سوالات کو دوبارہ لکھے بغیر، ایک ڈویلپر یا DBA صرف اشاریہ جات کو تبدیل کر سکتا ہے، اعداد و شمار کا تعین کر سکتا ہے اور استفسار کے منصوبہ ساز کو بتا سکتا ہے کہ انہیں کیسے عمل میں لانا ہے (اور اشارے صرف تجارتی DBMSs میں دستیاب ہیں)۔ اس سے کوئی فرق نہیں پڑتا ہے کہ وہ کتنی ہی کوشش کریں، وہ مضمون میں پہلا سوال مکمل نہیں کر پائیں گے۔ O (محکموں کی تعداد) سوالات کو تبدیل کیے بغیر یا محرکات شامل کیے بغیر۔ مجوزہ اسکیم میں، ترقی کے مرحلے پر آپ کو ڈیٹا اسٹوریج کے ڈھانچے کے بارے میں سوچنے کی ضرورت نہیں ہے اور کون سے مجموعوں کو استعمال کرنا ہے۔ یہ سب آسانی سے مکھی پر، براہ راست آپریشن میں تبدیل کیا جا سکتا ہے.

عملی طور پر ایسا لگتا ہے۔ کچھ لوگ براہ راست ہاتھ میں کام کی بنیاد پر منطق تیار کرتے ہیں۔ وہ الگورتھم اور ان کی پیچیدگی کو نہیں سمجھتے ہیں، نہ ہی عملدرآمد کے منصوبے، نہ ہی جوائن کی اقسام، اور نہ ہی کوئی اور تکنیکی جز۔ یہ لوگ ڈویلپرز سے زیادہ کاروباری تجزیہ کار ہیں۔ پھر، یہ سب ٹیسٹنگ یا آپریشن میں جاتا ہے۔ طویل عرصے سے چلنے والے سوالات کی لاگنگ کو فعال کرتا ہے۔ جب ایک طویل استفسار کا پتہ چلتا ہے، تو دوسرے لوگ (زیادہ تکنیکی - بنیادی طور پر DBA) کچھ انٹرمیڈیٹ فنکشن پر میٹریلائزڈ کو فعال کرنے کا فیصلہ کرتے ہیں۔ یہ ریکارڈنگ کو تھوڑا سا سست کر دیتا ہے (چونکہ اسے لین دین میں ایک اضافی فیلڈ کو اپ ڈیٹ کرنے کی ضرورت ہوتی ہے)۔ تاہم، نہ صرف اس استفسار کو نمایاں طور پر تیز کیا گیا ہے، بلکہ اس فنکشن کو استعمال کرنے والے دیگر تمام افراد بھی۔ ایک ہی وقت میں، یہ فیصلہ کرنا کہ کس فنکشن کو عملی شکل دینا ہے نسبتاً آسان ہے۔ دو اہم پیرامیٹرز: ممکنہ ان پٹ ویلیو کی تعداد (یہ ہے کہ متعلقہ ٹیبل میں کتنے ریکارڈ ہوں گے)، اور یہ دوسرے فنکشنز میں کتنی بار استعمال ہوتا ہے۔

ینالاگ

جدید تجارتی DBMSs میں ایک جیسے میکانزم ہیں: فاسٹ ریفریش (اوریکل) اور انڈیکسڈ ویو (مائیکروسافٹ ایس کیو ایل سرور) کے ساتھ میٹریلائزڈ ویو۔ PostgreSQL میں، مادی نظریہ کو لین دین میں اپ ڈیٹ نہیں کیا جا سکتا، لیکن صرف درخواست پر (اور انتہائی سخت پابندیوں کے ساتھ بھی)، اس لیے ہم اس پر غور نہیں کرتے۔ لیکن ان کے کئی مسائل ہیں جو ان کے استعمال کو نمایاں طور پر محدود کرتے ہیں۔

سب سے پہلے، اگر آپ نے پہلے سے ہی ایک باقاعدہ VIEW بنا لیا ہے تو آپ مادیت کو فعال کر سکتے ہیں۔ بصورت دیگر، آپ کو اس مادیت کو استعمال کرنے کے لیے نئے بنائے گئے منظر تک رسائی کے لیے بقیہ درخواستوں کو دوبارہ لکھنا پڑے گا۔ یا ہر چیز کو ویسا ہی چھوڑ دیں، لیکن یہ کم از کم غیر موثر ہو جائے گا اگر پہلے سے کچھ پہلے سے حساب شدہ ڈیٹا موجود ہو، لیکن بہت سے سوالات ہمیشہ اسے استعمال نہیں کرتے ہیں، لیکن اس کا دوبارہ حساب لگاتے ہیں۔

دوم، ان پر بہت زیادہ پابندیاں ہیں:

اوریکل

5.3.8.4 فاسٹ ریفریش پر عمومی پابندیاں

مادی نظریہ کی وضاحتی استفسار اس طرح محدود ہے:

• مادی نظریہ میں غیر دہرائے جانے والے تاثرات جیسے حوالہ جات پر مشتمل نہیں ہونا چاہیے۔ SYSDATE اور ROWNUM.
• مادی نظر میں حوالہ جات پر مشتمل نہیں ہونا چاہیے۔ RAW or LONG RAW ڈیٹا کی اقسام
• اس میں a شامل نہیں ہو سکتا SELECT فہرست ذیلی سوال۔
• اس میں تجزیاتی افعال شامل نہیں ہوسکتے ہیں (مثال کے طور پر، RANK) میں SELECT شق
• یہ کسی ٹیبل کا حوالہ نہیں دے سکتا جس پر ایک XMLIndex انڈیکس کی وضاحت کی گئی ہے۔
• اس میں a شامل نہیں ہو سکتا MODEL شق
• اس میں a شامل نہیں ہو سکتا HAVING ذیلی استفسار کے ساتھ شق۔
• اس میں نیسٹڈ استفسارات شامل نہیں ہوسکتے ہیں۔ ANY, ALL، یا NOT EXISTS.
• اس میں a شامل نہیں ہو سکتا [START WITH …] CONNECT BY شق
• اس میں مختلف سائٹس پر ایک سے زیادہ تفصیلی جدولیں نہیں ہو سکتیں۔
• ON COMMIT مادی خیالات میں ریموٹ ڈیٹیل ٹیبل نہیں ہو سکتے۔
• نیسٹڈ میٹریلائزڈ ویوز میں جوائن یا ایگریگیٹ ہونا ضروری ہے۔
• مواد میں شامل ہونے کے خیالات اور ایک کے ساتھ مجموعی طور پر مجموعی خیالات 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 کالم۔
• مادی نظر ایک یا زیادہ ریموٹ ٹیبلز پر مبنی نہیں ہے۔
• اگر آپ استعمال کرتے ہیں a CHAR میٹریلائزڈ ویو لاگ کے فلٹر کالم میں ڈیٹا ٹائپ، ماسٹر سائٹ کے کریکٹر سیٹ اور میٹریلائزڈ ویو ایک جیسا ہونا چاہیے۔
• اگر مادی منظر میں مندرجہ ذیل میں سے کوئی ایک ہے، تو تیز ریفریش صرف روایتی DML انسرٹس اور ڈائریکٹ لوڈز پر سپورٹ کرتا ہے۔
  • کے ساتھ مادی خیالات MIN or MAX مجموعات
  • مادی خیالات جن کے پاس ہیں۔ SUM(expr) لیکن نہیں COUNT(expr)
  • بغیر مواد کے نظارے۔ COUNT(*)

  اس طرح کے مادی نظر کو صرف داخل کرنے والا مادی نظر کہا جاتا ہے۔

• کے ساتھ ایک مادی نظارہ MAX or MIN ڈیلیٹ یا مکسڈ ڈی ایم ایل اسٹیٹمنٹس کے بعد تیزی سے ریفریش کیا جاسکتا ہے اگر اس میں a نہیں ہے۔ 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) جیسا کہ مندرجہ ذیل مثال میں ہے:

  View_with_unionall AS بنائیں دیکھیں (SELECT c.rowid crid, c.cust_id, 2 umarker from گاہک c WHERE c.cust_last_name = 'Smith' UNION تمام منتخب کریں c.rowid crid, c.cust_id, 3 umarker FROM گاہک c_last_name c. 'جونس')؛ مٹیریلائزڈ ویو بنائیں unionall_inside_view_mv ڈیمانڈ پر تیزی سے ریفریش کریں جیسا کہ منتخب کریں * view_with_unionall سے؛
  

  نوٹ کریں کہ نقطہ نظر view_with_unionall تیز ریفریش کے لیے ضروریات کو پورا کرتا ہے۔

• میں ہر سوال بلاک UNION ALL استفسار کو ایگریگیٹس کے ساتھ ایک تیز ریفریش ایبل میٹریلائزڈ ویو یا جوائنز کے ساتھ تیز ریفریش ایبل میٹریلائزڈ ویو کی ضروریات کو پورا کرنا چاہیے۔

  متعلقہ قسم کے تیز ریفریش ایبل میٹیریلائزڈ ویو کے لیے ضروری ہونے کے مطابق ٹیبلز پر مناسب مادی شکل والے ویو لاگز بنائے جائیں۔
  نوٹ کریں کہ اوریکل ڈیٹا بیس صرف جوائنز کے ساتھ سنگل ٹیبل کے مادی منظر کے خصوصی کیس کی اجازت دیتا ہے۔ ROWID کالم میں شامل کیا گیا ہے۔ SELECT فہرست اور مادّی نظر کے لاگ میں۔ یہ نقطہ نظر کے وضاحتی سوال میں دکھایا گیا ہے۔ view_with_unionall.

• ۔ SELECT ہر سوال کی فہرست میں شامل ہونا ضروری ہے۔ UNION ALL مارکر، اور UNION ALL کالم میں ہر ایک میں ایک الگ مستقل عددی یا سٹرنگ ویلیو ہونی چاہیے۔ UNION ALL شاخ مزید، مارکر کالم کو اسی ترتیب والی پوزیشن میں ظاہر ہونا چاہیے۔ SELECT ہر سوال کے بلاک کی فہرست۔ دیکھیں"یونین آل مارکر اور سوال دوبارہ لکھیں۔» کے بارے میں مزید معلومات کے لیے 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 شق یا ویو میں JOIN آپریشن کی ON شق میں ظاہر نہیں ہو سکتے۔
• ویو ڈیفینیشن میں استعمال ہونے والی CLR صارف کی وضاحت شدہ اقسام کے CLR فنکشنز اور طریقوں میں درج ذیل جدول میں دکھائے گئے خصوصیات کے مطابق ہونا ضروری ہے۔

  پراپرٹی
  نوٹ

  ڈیٹرمینسٹک = سچ
  واضح طور پر Microsoft .NET Framework طریقہ کار کی ایک خصوصیت کے طور پر اعلان کیا جانا چاہیے۔

  PRECISE = سچ
  .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, تصویر, XML، یا فائل اسٹریم کالم
  ذیلی استفسار
  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 پابندی
• اگر نقطہ نظر کی تعریف میں 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, تصویر, XML، یا فائل اسٹریم کالم
ذیلی استفسار
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

بیرونی شمولیت، یونین، آرڈر بائے اور دیگر ممنوع ہیں۔ کیا استعمال نہیں کیا جا سکتا اس کے بجائے یہ بتانا آسان ہو سکتا ہے کہ کیا استعمال کیا جا سکتا ہے۔ فہرست شاید بہت مختصر ہوگی۔

خلاصہ کرنے کے لیے: LGPL ٹکنالوجی میں ہر ایک میں پابندیوں کا ایک بہت بڑا مجموعہ (آئیے تجارتی نوٹ کریں) DBMS بمقابلہ کوئی نہیں (ایک منطقی، تکنیکی کے استثناء کے ساتھ)۔ تاہم، یہ واضح رہے کہ اس طریقہ کار کو متعلقہ منطق میں نافذ کرنا بیان کردہ فنکشنل منطق کے مقابلے میں کچھ زیادہ مشکل ہے۔

Реализация

یہ کیسے کام کرتا ہے؟ PostgreSQL کو بطور "ورچوئل مشین" استعمال کیا جاتا ہے۔ اندر ایک پیچیدہ الگورتھم ہے جو سوالات بناتا ہے۔ یہاں ماخذ کوڈ. اور آئی ایف ایس کے ایک گروپ کے ساتھ ہیورسٹکس کا صرف ایک بڑا مجموعہ نہیں ہے۔ لہذا، اگر آپ کے پاس مطالعہ کرنے کے لیے چند مہینے ہیں، تو آپ فن تعمیر کو سمجھنے کی کوشش کر سکتے ہیں۔

کیا یہ مؤثر طریقے سے کام کرتا ہے؟ کافی موثر۔ بدقسمتی سے، یہ ثابت کرنا مشکل ہے. میں صرف اتنا کہہ سکتا ہوں کہ اگر آپ بڑی ایپلی کیشنز میں موجود ہزاروں سوالات پر غور کریں، تو اوسطاً وہ ایک اچھے ڈویلپر کی نسبت زیادہ کارآمد ہیں۔ ایک بہترین ایس کیو ایل پروگرامر کسی بھی سوال کو زیادہ مؤثر طریقے سے لکھ سکتا ہے، لیکن ہزار سوالات کے ساتھ اس کے پاس ایسا کرنے کے لیے حوصلہ یا وقت نہیں ہوگا۔ صرف ایک چیز جس کا میں اب تاثیر کے ثبوت کے طور پر حوالہ دے سکتا ہوں وہ یہ ہے کہ اس DBMS پر بنائے گئے پلیٹ فارم پر کئی منصوبے کام کر رہے ہیں۔ ERP سسٹمز، جس میں ہزاروں مختلف مادی فنکشنز ہیں، جن میں ہزاروں صارفین اور ٹیرا بائٹ ڈیٹا بیس ہیں جن میں سیکڑوں ملین ریکارڈز ایک باقاعدہ دو پروسیسر سرور پر چل رہے ہیں۔ تاہم، کوئی بھی ڈاؤن لوڈ کر کے تاثیر کی جانچ/تردید کر سکتا ہے۔ پلیٹ فارم اور PostgreSQL، کهولنا، آن کرنا ایس کیو ایل کے سوالات کو لاگ ان کرنا اور وہاں کی منطق اور ڈیٹا کو تبدیل کرنے کی کوشش کرنا۔

اگلے مضامین میں، میں اس بارے میں بھی بات کروں گا کہ آپ کس طرح فنکشنز پر پابندیاں لگا سکتے ہیں، تبدیلی کے سیشنز کے ساتھ کام کر سکتے ہیں، اور بہت کچھ۔

ماخذ: www.habr.com