توازن په ډیټابیس کې لیکي او لوستل کوي

په تیرو کې مقالې ما د ډیټابیس مفکوره او پلي کول تشریح کړل چې د دندو پر بنسټ جوړ شوي، نه د جدولونو او ساحو په څیر د اړونده ډیټابیسونو په څیر. دا ډیری مثالونه وړاندې کړي چې د دې طریقې ګټې په کلاسیک ډول ښودلې. ډیری یې وموندل چې دوی کافي قانع ندي.

په دې مقاله کې، زه به وښیم چې دا مفهوم څنګه تاسو ته اجازه درکوي چې په عملیاتي منطق کې کوم بدلون پرته ډیټابیس ته د لیکلو او لوستلو توازن په چټکه او اسانتیا سره. ورته فعالیت هڅه شوې چې په عصري سوداګریزو DBMSs کې پلي شي (په ځانګړي توګه اوریکل او مایکروسافټ 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 (د کارمندانو شمیره) او یا او (د څانګو شمیر) د ګروپ کولو او داسې نورو لپاره.

دا روښانه ده چې د اعدام سر سر په مختلفو DBMSs کې توپیر لري، مګر پیچلتیا به په هیڅ ډول بدلون ونلري.

په وړاندیز شوي تطبیق کې، فعال DBMS به یوه فرعي پوښتنه رامینځته کړي چې د ډیپارټمنټ لپاره اړین ارزښتونه به محاسبه کړي، او بیا به د نوم ترلاسه کولو لپاره د ډیپارټمنټ میز سره یوځای شي. په هرصورت، د هر فعالیت لپاره، کله چې اعلان کول، دا ممکنه ده چې یو ځانګړی مادی شوی مارکر تنظیم کړئ. سیسټم به په اوتومات ډول د هر ورته فعالیت لپاره ورته ساحه رامینځته کړي. کله چې د فنکشن ارزښت بدل شي، د ساحې ارزښت به په ورته لیږد کې هم بدلون ومومي. کله چې دې فنکشن ته لاسرسی ومومئ، مخکې حساب شوي ساحې ته به لاسرسی ومومي.

په ځانګړې توګه، که تاسو د دندو لپاره مواد جوړ کړئ د کارمندانو شمیر и معاش، بیا به د څانګو لیست سره په میز کې دوه ساحې اضافه شي ، کوم چې به د کارمندانو شمیر او د دوی ټول معاش ذخیره کړي. هرکله چې د کارمندانو، د دوی په معاشونو یا د څانګې په تړاو کې بدلون راشي، سیسټم به په اتوماتيک ډول د دې برخو ارزښت بدل کړي. پورته پوښتنه به دې ساحو ته مستقیم لاسرسی ومومي او په کې به اجرا شي او (د څانګو شمیر).

بندیزونه څه دي؟ یوازې یو شی: دا ډول فنکشن باید د ان پټ ارزښتونو محدود شمیر ولري د کوم لپاره چې ارزښت یې تعریف شوی. که نه نو، دا به ناشونې وي چې یو میز جوړ کړئ چې ټول ارزښتونه یې ذخیره کړي، ځکه چې د لامحدود قطارونو سره میز شتون نلري.

بېلګه:

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


دا فنکشن د N لامحدود ارزښتونو لپاره تعریف شوی (د مثال په توګه، کوم منفي ارزښت مناسب دی). له همدې امله، تاسو نشئ کولی په دې باندې مواد واچوئ. نو دا یو منطقي محدودیت دی، نه تخنیکي (دا ځکه چې موږ نشو کولی دا پلي کړو). که نه نو، هیڅ محدودیتونه شتون نلري. تاسو کولی شئ ګروپونه وکاروئ، ترتیب کړئ، او او یا، PARTITION، تکرار، او داسې نور.

د مثال په توګه، د تیرې مقالې په 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 نه وي. پرځای به یو ساده ګروپ 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 کې شتون لري). مهمه نده چې دوی څومره هڅه وکړي ، دوی به ونه شي کولی په مقاله کې لومړۍ پوښتنه بشپړه کړي O (د څانګو شمیر) د پوښتنو بدلولو یا محرکاتو اضافه کولو پرته. په وړاندیز شوي سکیم کې، د پراختیا په مرحله کې تاسو اړتیا نلرئ د معلوماتو ذخیره کولو جوړښت په اړه فکر وکړئ او کوم راټولونه باید وکارول شي. دا ټول په مستقیم ډول په الوتنه کې په اسانۍ سره بدلیدلی شي.

په عمل کې دا داسې ښکاري. ځینې ​​​​خلک په مستقیم ډول په لاس کې د دندې پراساس منطق رامینځته کوي. دوی نه الګوریتمونه او د دوی پیچلتیا، نه د اجرا کولو پلانونه، نه د یوځای کیدو ډولونه، او نه هم کوم بل تخنیکي برخې پوهیږي. دا خلک د پراختیا کونکو په پرتله ډیر سوداګریز شنونکي دي. بیا، دا ټول ازموینې یا عملیات ته ځي. د اوږدې مودې پوښتنو د ننوتلو وړ کوي. کله چې یوه اوږده پوښتنه وموندل شي، نو نور خلک (ډیر تخنیکي - په لازمي ډول DBA) پریکړه کوي چې په ځینې منځګړیتوب فعالیت کې MATERIALIZED فعال کړي. دا ثبت کول یو څه ورو کوي (ځکه چې دا په لیږد کې اضافي ساحې تازه کولو ته اړتیا لري). په هرصورت، نه یوازې دا پوښتنه د پام وړ چټکه شوې، بلکې ټول نور چې دا فنکشن کاروي. په ورته وخت کې، پریکړه کول چې کوم فعالیت د مادي کولو لپاره نسبتا اسانه دی. دوه اصلي پیرامیټونه: د احتمالي ان پټ ارزښتونو شمیر (دا په ورته جدول کې به څومره ریکارډونه وي) او دا چې په نورو دندو کې څو ځله کارول کیږي.

اینلاګونه

عصري سوداګریز DBMSs ورته میکانیزمونه لري: د فاسټ ریفریش (اوریکل) سره د موادو لیدلوری او INDEXED VIEW (Microsoft SQL Server). په PostgreSQL کې، مادی شوی لید په لیږد کې تازه نشي کیدی، مګر یوازې په غوښتنه (او حتی د خورا سخت محدودیتونو سره)، نو موږ یې په پام کې نه نیسو. مګر دوی ډیری ستونزې لري چې د پام وړ د دوی کارول محدودوي.

لومړی، تاسو کولی شئ یوازې مادي کول فعال کړئ که تاسو دمخه منظم لید جوړ کړی وي. که نه نو، تاسو به د دې مادي کولو کارولو لپاره نوي جوړ شوي لید ته د لاسرسي لپاره پاتې غوښتنې بیا ولیکئ. یا هرڅه لکه څنګه چې وي پریږدئ، مګر دا به لږترلږه غیر اغیزمن وي که چیرې مخکې له مخکې محاسبه شوي معلومات شتون ولري، مګر ډیری پوښتنې تل دا نه کاروي، مګر بیا یې حسابوي.

دوهم، دوی یو لوی شمیر محدودیتونه لري:

سينه_پوښ

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 د حذف یا مخلوط DML بیاناتو وروسته ګړندی ریفریش کیدونکی دی که چیرې دا ونه لري WHERE شق.
  د ړنګولو یا مخلوط DML وروسته اعظمي / دقیقې ګړندي ریفریش د یوازې داخلولو قضیې په څیر ورته چلند نلري. دا د اغیزمنو ډلو لپاره اعظمي / دقیقې ارزښتونه حذف او بیا تنظیموي. تاسو اړتیا لرئ د هغې د فعالیت اغیزې څخه خبر اوسئ.
• د نومول شوي لیدونو یا فرعي پوښتنو سره مادي شوي لیدونه 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 د آپریټر ملاتړ تنظیم کړئ REFRESH FAST اختیار که چیرې لاندې شرایط پوره وي:

• ټاکل شوې پوښتنه باید ولري UNION ALL په لوړه کچه چلونکی.

  د UNION ALL آپریټر نشي کولی د فرعي پوښتنې دننه ځای په ځای شي، د یو استثنا سره: UNION ALL کیدای شي په فرعي پوښتنو کې وي FROM فقره چمتو شوې چې تعریف شوې پوښتنه د فورمې څخه وي SELECT * FROM (له دې سره وګورئ یا فرعي پوښتنه وکړئ UNION ALL) لکه په لاندې مثال کې:

  د لید لید جوړ کړئ. 'جونز')؛ د موادو سره تړلی لید جوړ کړئ unionall_inside_view_mv د غوښتنې په اساس ګړندي تازه کړئ لکه څنګه چې انتخاب کړئ * له لید_سره_یونیز ټول؛
  

  په یاد ولرئ چې لید 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 دندې او میتودونه باید مشخصات ولري لکه څنګه چې په لاندې جدول کې ښودل شوي.

  د ملکیت
  یادښت

  تصمیم نیونکی = ریښتیا
  باید په ښکاره ډول د مایکروسافټ .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)

  اخستل شوی جدول (د مشخص کولو په واسطه تعریف شوی SELECT بیان په FROM فقره)
  ځان سره یوځای کوي
  په کارولو سره د کالمونو مشخص کول SELECT * or SELECT <table_name>.*

  DISTINCT
STDEV, STDEVP, VAR, VARP، او یا AVG
  د ګډ جدول بیان (CTE)

  ثاب1, متن, متن, انځور, ایکس ایم ایل، او یا د فایل جریان کالمونه
  پوښتنه
  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 شتون لري، د 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)

اخستل شوی جدول (د مشخص کولو په واسطه تعریف شوی SELECT بیان په FROM فقره)
ځان سره یوځای کوي
په کارولو سره د کالمونو مشخص کول SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARP، او یا AVG
د ګډ جدول بیان (CTE)

ثاب1, متن, متن, انځور, ایکس ایم ایل، او یا د فایل جریان کالمونه
پوښتنه
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

بهر یوځای کیدل، اتحادیه، امر او نور منع دي. ښایي دا اسانه وي چې مشخص کړئ چې څه کارول کیدی شي د دې په پرتله چې نشي کارول کیدی. لیست به شاید ډیر لنډ وي.

د لنډیز کولو لپاره: په LGPL ټیکنالوژۍ کې په هر کې د محدودیتونو لوی سیټ (راځئ چې سوداګریز یادونه وکړو) DBMS vs هیڅ نه (د یو منطقي استثنا سره ، تخنیکي نه). په هرصورت، دا باید په پام کې ونیول شي چې په اړونده منطق کې د دې میکانیزم پلي کول د بیان شوي فعال منطق په پرتله یو څه ستونزمن دي.

پلي کول

څنګه کار کوي؟ PostgreSQL د "مجازی ماشین" په توګه کارول کیږي. دننه یو پیچلی الګوریتم شتون لري چې پوښتنې رامینځته کوي. دلته سرچینه. او د ifs د یوې ډلې سره یوازې د هیوریسټیک لوی سیټ شتون نلري. نو، که تاسو د مطالعې لپاره څو میاشتې لرئ، تاسو کولی شئ د معمارۍ د پوهیدو هڅه وکړئ.

ایا دا په مؤثره توګه کار کوي؟ کافي اغیزمن. له بده مرغه، دا ثابتول ستونزمن دي. زه یوازې ویلای شم چې که تاسو په زرګونو پوښتنو ته پام وکړئ چې په لوی غوښتنلیکونو کې شتون لري ، نو په اوسط ډول دوی د ښه پراختیا کونکي په پرتله خورا مؤثر دي. یو غوره SQL پروګرامر کولی شي هره پوښتنه په اغیزمنه توګه ولیکي، مګر د زرو پوښتنو سره هغه به په ساده ډول د دې کولو لپاره هڅونه یا وخت ونه لري. یوازینی شی چې زه یې اوس د مؤثریت ثبوت په توګه بیانولی شم دا دی چې ډیری پروژې په دې DBMS کې جوړ شوي پلیټ فارم کې کار کوي د ERP سیسټمونه، کوم چې په زرګونو مختلف مادی شوي دندې لري ، د زرګونو کاروونکو او ټیرابایټ ډیټابیسونو سره د سلګونو ملیون ریکارډونو سره په منظم دوه پروسیسر سرور کې پرمخ ځي. په هرصورت، هرڅوک کولی شي د ډاونلوډ کولو له لارې اغیزمنتوب وګوري / رد کړي پلیټ فارم او PostgreSQL، چالان کول د SQL پوښتنو ته ننوتل او هلته د منطق او ډاټا بدلولو هڅه کول.

په لاندې مقالو کې ، زه به پدې اړه هم وغږیږم چې تاسو څنګه کولی شئ په دندو محدودیتونه تنظیم کړئ ، د بدلون غونډو سره کار وکړئ ، او نور ډیر څه.

سرچینه: www.habr.com