ഒരു ഡാറ്റാബേസിൽ എഴുതുന്നതും വായിക്കുന്നതും ബാലൻസ് ചെയ്യുന്നു

മുമ്പത്തേതിൽ ലേഖനം റിലേഷണൽ ഡാറ്റാബേസുകളിലേതുപോലെ പട്ടികകൾക്കും ഫീൽഡുകൾക്കും പകരം ഫംഗ്‌ഷനുകളുടെ അടിസ്ഥാനത്തിൽ നിർമ്മിച്ച ഒരു ഡാറ്റാബേസിന്റെ ആശയവും നടപ്പിലാക്കലും ഞാൻ വിവരിച്ചു. ക്ലാസിക്കൽ സമീപനത്തേക്കാൾ ഈ സമീപനത്തിന്റെ ഗുണങ്ങൾ കാണിക്കുന്ന നിരവധി ഉദാഹരണങ്ങൾ ഇത് നൽകി. അവരെ വേണ്ടത്ര ബോധ്യപ്പെടുത്തുന്നില്ലെന്ന് പലരും കണ്ടെത്തി.

ഈ ലേഖനത്തിൽ, ഓപ്പറേറ്റിംഗ് ലോജിക്കിൽ ഒരു മാറ്റവുമില്ലാതെ ഡാറ്റാബേസിലേക്ക് റൈറ്റുകളും റീഡുകളും വേഗത്തിലും സൗകര്യപ്രദമായും സന്തുലിതമാക്കാൻ ഈ ആശയം നിങ്ങളെ എങ്ങനെ അനുവദിക്കുന്നുവെന്ന് ഞാൻ കാണിക്കും. ആധുനിക വാണിജ്യ DBMS-കളിൽ (പ്രത്യേകിച്ച്, 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);


ഏത് ഡിബിഎംഎസിലും ഈ ചോദ്യം നിർവ്വഹിക്കുന്നതിന്റെ സങ്കീർണ്ണത ഇതിന് തുല്യമായിരിക്കും O (ജീവനക്കാരുടെ എണ്ണം)കാരണം ഈ കണക്കുകൂട്ടലിന് ജീവനക്കാരുടെ മുഴുവൻ ടേബിളും സ്കാൻ ചെയ്യുകയും തുടർന്ന് അവരെ ഡിപ്പാർട്ട്മെന്റ് അനുസരിച്ച് ഗ്രൂപ്പുചെയ്യുകയും വേണം. തിരഞ്ഞെടുത്ത പ്ലാനിനെ ആശ്രയിച്ച് ചില ചെറിയ (ഡിപ്പാർട്ട്‌മെന്റുകളേക്കാൾ കൂടുതൽ ജീവനക്കാർ ഉണ്ടെന്ന് ഞങ്ങൾ വിശ്വസിക്കുന്നു) സപ്ലിമെന്റും ഉണ്ടാകും. O (ജീവനക്കാരുടെ ലോഗ് നമ്പർ) അഥവാ O (വകുപ്പുകളുടെ എണ്ണം) ഗ്രൂപ്പിംഗിനും മറ്റും.

വ്യത്യസ്ത ഡിബിഎംഎസുകളിൽ എക്സിക്യൂഷൻ ഓവർഹെഡ് വ്യത്യസ്തമായിരിക്കാമെന്നത് വ്യക്തമാണ്, എന്നാൽ സങ്കീർണ്ണത ഒരു തരത്തിലും മാറില്ല.

നിർദ്ദിഷ്ട നടപ്പാക്കലിൽ, പ്രവർത്തനക്ഷമമായ DBMS ഒരു സബ്ക്വറി സൃഷ്ടിക്കും, അത് ഡിപ്പാർട്ട്മെന്റിന് ആവശ്യമായ മൂല്യങ്ങൾ കണക്കാക്കും, തുടർന്ന് പേര് ലഭിക്കുന്നതിന് ഡിപ്പാർട്ട്മെന്റ് ടേബിളുമായി ഒരു ജോയിൻ ചെയ്യുക. എന്നിരുന്നാലും, ഓരോ ഫംഗ്ഷനും, പ്രഖ്യാപിക്കുമ്പോൾ, ഒരു പ്രത്യേക MATERIALIZED മാർക്കർ സജ്ജമാക്കാൻ സാധിക്കും. അത്തരം ഓരോ പ്രവർത്തനത്തിനും സിസ്റ്റം സ്വയമേവ ഒരു അനുബന്ധ ഫീൽഡ് സൃഷ്ടിക്കും. ഒരു ഫംഗ്‌ഷന്റെ മൂല്യം മാറ്റുമ്പോൾ, അതേ ഇടപാടിൽ ഫീൽഡിന്റെ മൂല്യവും മാറും. ഈ ഫംഗ്ഷൻ ആക്സസ് ചെയ്യുമ്പോൾ, മുൻകൂട്ടി കണക്കാക്കിയ ഫീൽഡ് ആക്സസ് ചെയ്യപ്പെടും.

പ്രത്യേകിച്ചും, നിങ്ങൾ ഫംഗ്‌ഷനുകൾക്കായി MATERIALIZED സജ്ജമാക്കുകയാണെങ്കിൽ കൗണ്ട് എംപ്ലോയീസ് и ശമ്പളം, തുടർന്ന് രണ്ട് ഫീൽഡുകൾ വകുപ്പുകളുടെ പട്ടികയിൽ പട്ടികയിൽ ചേർക്കും, അത് ജീവനക്കാരുടെ എണ്ണവും അവരുടെ മൊത്തം ശമ്പളവും സംഭരിക്കും. ജീവനക്കാരിലോ അവരുടെ ശമ്പളത്തിലോ ഡിപ്പാർട്ട്‌മെന്റ് അഫിലിയേഷനുകളിലോ മാറ്റം വരുമ്പോഴെല്ലാം, ഈ ഫീൽഡുകളുടെ മൂല്യങ്ങൾ സിസ്റ്റം യാന്ത്രികമായി മാറ്റും. മുകളിലുള്ള ചോദ്യം ഈ ഫീൽഡുകളിലേക്ക് നേരിട്ട് ആക്‌സസ് ചെയ്യുകയും അത് നടപ്പിലാക്കുകയും ചെയ്യും O (വകുപ്പുകളുടെ എണ്ണം).

എന്തൊക്കെയാണ് നിയന്ത്രണങ്ങൾ? ഒരു കാര്യം മാത്രം: അത്തരമൊരു ഫംഗ്‌ഷന് അതിന്റെ മൂല്യം നിർവചിച്ചിരിക്കുന്ന പരിമിതമായ ഇൻപുട്ട് മൂല്യങ്ങൾ ഉണ്ടായിരിക്കണം. അല്ലെങ്കിൽ, അനന്തമായ വരികളുള്ള ഒരു പട്ടിക ഉണ്ടാകാൻ കഴിയാത്തതിനാൽ, അതിന്റെ എല്ലാ മൂല്യങ്ങളും സംഭരിക്കുന്ന ഒരു പട്ടിക നിർമ്മിക്കുന്നത് അസാധ്യമാണ്.

ഉദാഹരണം:

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


N ന്റെ അനന്തമായ മൂല്യങ്ങൾക്കായി ഈ ഫംഗ്ഷൻ നിർവചിച്ചിരിക്കുന്നു (ഉദാഹരണത്തിന്, ഏതെങ്കിലും നെഗറ്റീവ് മൂല്യം അനുയോജ്യമാണ്). അതിനാൽ, നിങ്ങൾക്ക് അതിൽ MATERIALIZED ഇടാൻ കഴിയില്ല. അതിനാൽ ഇതൊരു ലോജിക്കൽ പരിമിതിയാണ്, സാങ്കേതികമായ ഒന്നല്ല (അതായത്, ഞങ്ങൾക്ക് ഇത് നടപ്പിലാക്കാൻ കഴിയാത്തതുകൊണ്ടല്ല). അല്ലെങ്കിൽ, നിയന്ത്രണങ്ങളൊന്നുമില്ല. നിങ്ങൾക്ക് ഗ്രൂപ്പിംഗുകൾ, സോർട്ടിംഗ്, കൂടാതെ അല്ലെങ്കിൽ, പാർട്ടീഷൻ, ആവർത്തനം മുതലായവ ഉപയോഗിക്കാം.

ഉദാഹരണത്തിന്, മുമ്പത്തെ ലേഖനത്തിന്റെ പ്രശ്നം 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 ഉണ്ടാകില്ല. പകരം ഒരു ലളിതമായ GROUP BY ആയിരിക്കും.

ഈ സംവിധാനം ഉപയോഗിച്ച്, ആവശ്യമെങ്കിൽ നിങ്ങൾക്ക് ഡാറ്റാബേസ് എളുപ്പത്തിൽ ഡീനോർമലൈസ് ചെയ്യാനും കഴിയും:

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

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


ഒരു ഫംഗ്ഷൻ വിളിക്കുമ്പോൾ തീയതി ഓർഡർ ലൈനിനായി, ഒരു സൂചിക ഉള്ള ഫീൽഡ് ഓർഡർ ലൈനുകൾ ഉപയോഗിച്ച് പട്ടികയിൽ നിന്ന് വായിക്കും. ഓർഡർ തീയതി മാറുമ്പോൾ, സിസ്റ്റം തന്നെ ലൈനിലെ ഡീനോർമലൈസ് ചെയ്ത തീയതി സ്വയമേവ വീണ്ടും കണക്കാക്കും.

ഗുണങ്ങളുമുണ്ട്

ഈ മുഴുവൻ മെക്കാനിസവും എന്തിനുവേണ്ടിയാണ്? ക്ലാസിക് DBMS-കളിൽ, ചോദ്യങ്ങൾ തിരുത്തിയെഴുതാതെ, ഒരു ഡവലപ്പർക്കോ DBA ക്കോ സൂചികകൾ മാറ്റാനും സ്ഥിതിവിവരക്കണക്കുകൾ നിർണ്ണയിക്കാനും അവ എങ്ങനെ എക്‌സിക്യൂട്ട് ചെയ്യണമെന്ന് അന്വേഷണ പ്ലാനറോട് പറയാനും മാത്രമേ കഴിയൂ (കൂടാതെ വാണിജ്യ DBMS-കളിൽ മാത്രമേ സൂചനകൾ ലഭ്യമാകൂ). അവർ എത്ര ശ്രമിച്ചാലും ലേഖനത്തിലെ ആദ്യത്തെ ചോദ്യം പൂർത്തിയാക്കാൻ അവർക്ക് കഴിയില്ല O (വകുപ്പുകളുടെ എണ്ണം) ചോദ്യങ്ങൾ മാറ്റുകയോ ട്രിഗറുകൾ ചേർക്കുകയോ ചെയ്യാതെ. നിർദ്ദിഷ്ട സ്കീമിൽ, വികസന ഘട്ടത്തിൽ നിങ്ങൾ ഡാറ്റ സ്റ്റോറേജ് ഘടനയെക്കുറിച്ചും ഏത് അഗ്രഗേഷനുകൾ ഉപയോഗിക്കണമെന്നും ചിന്തിക്കേണ്ടതില്ല. ഇവയെല്ലാം ഈച്ചയിൽ, നേരിട്ട് പ്രവർത്തനത്തിൽ എളുപ്പത്തിൽ മാറ്റാൻ കഴിയും.

പ്രായോഗികമായി ഇത് ഇതുപോലെ കാണപ്പെടുന്നു. ചിലർ ചുമതലയെ അടിസ്ഥാനമാക്കി നേരിട്ട് യുക്തി വികസിപ്പിക്കുന്നു. അവർക്ക് അൽഗോരിതങ്ങളും അവയുടെ സങ്കീർണ്ണതയും, എക്സിക്യൂഷൻ പ്ലാനുകളും, ജോയിനുകളുടെ തരങ്ങളും, മറ്റേതെങ്കിലും സാങ്കേതിക ഘടകങ്ങളും മനസ്സിലാകുന്നില്ല. ഈ ആളുകൾ ഡെവലപ്പർമാരേക്കാൾ കൂടുതൽ ബിസിനസ്സ് അനലിസ്റ്റുകളാണ്. തുടർന്ന്, ഇതെല്ലാം പരിശോധനയിലേക്കോ പ്രവർത്തനത്തിലേക്കോ പോകുന്നു. ദീർഘകാല അന്വേഷണങ്ങളുടെ ലോഗിംഗ് പ്രവർത്തനക്ഷമമാക്കുന്നു. ഒരു നീണ്ട ചോദ്യം കണ്ടെത്തുമ്പോൾ, മറ്റ് ആളുകൾ (കൂടുതൽ സാങ്കേതിക - അടിസ്ഥാനപരമായി DBA) ചില ഇന്റർമീഡിയറ്റ് ഫംഗ്ഷനിൽ MATERIALIZED പ്രവർത്തനക്ഷമമാക്കാൻ തീരുമാനിക്കുന്നു. ഇത് റെക്കോർഡിംഗ് അൽപ്പം മന്ദഗതിയിലാക്കുന്നു (ഇതിന് ഇടപാടിൽ ഒരു അധിക ഫീൽഡ് അപ്‌ഡേറ്റ് ചെയ്യേണ്ടതിനാൽ). എന്നിരുന്നാലും, ഈ ചോദ്യം ഗണ്യമായി വേഗത്തിലാക്കുക മാത്രമല്ല, ഈ പ്രവർത്തനം ഉപയോഗിക്കുന്ന മറ്റെല്ലാവരും. അതേ സമയം, ഏത് ഫംഗ്‌ഷൻ യാഥാർത്ഥ്യമാക്കണമെന്ന് തീരുമാനിക്കുന്നത് താരതമ്യേന എളുപ്പമാണ്. രണ്ട് പ്രധാന പാരാമീറ്ററുകൾ: സാധ്യമായ ഇൻപുട്ട് മൂല്യങ്ങളുടെ എണ്ണം (അനുബന്ധ പട്ടികയിൽ എത്ര റെക്കോർഡുകൾ ഉണ്ടായിരിക്കും), മറ്റ് ഫംഗ്ഷനുകളിൽ ഇത് എത്ര തവണ ഉപയോഗിക്കുന്നു.

അനലോഗുകൾ

ആധുനിക വാണിജ്യ DBMS-കൾക്ക് സമാനമായ സംവിധാനങ്ങളുണ്ട്: ഫാസ്റ്റ് റിഫ്രഷ് (ഒറാക്കിൾ) ഉള്ള മെറ്റീരിയലൈസ്ഡ് വ്യൂ, ഇൻഡെക്സ്ഡ് വ്യൂ (മൈക്രോസോഫ്റ്റ് SQL സെർവർ). PostgreSQL-ൽ, ഒരു ഇടപാടിൽ MATERIALIZED VIEW അപ്‌ഡേറ്റ് ചെയ്യാൻ കഴിയില്ല, എന്നാൽ അഭ്യർത്ഥന പ്രകാരം മാത്രം (വളരെ കർശനമായ നിയന്ത്രണങ്ങളോടെ പോലും), അതിനാൽ ഞങ്ങൾ അത് പരിഗണിക്കില്ല. എന്നാൽ അവയുടെ ഉപയോഗം ഗണ്യമായി പരിമിതപ്പെടുത്തുന്ന നിരവധി പ്രശ്നങ്ങളുണ്ട്.

ഒന്നാമതായി, നിങ്ങൾ ഇതിനകം ഒരു സാധാരണ കാഴ്ച സൃഷ്ടിച്ചിട്ടുണ്ടെങ്കിൽ മാത്രമേ നിങ്ങൾക്ക് മെറ്റീരിയലൈസേഷൻ പ്രവർത്തനക്ഷമമാക്കാൻ കഴിയൂ. അല്ലെങ്കിൽ, ഈ മെറ്റീരിയലൈസേഷൻ ഉപയോഗിക്കുന്നതിന് പുതുതായി സൃഷ്‌ടിച്ച കാഴ്‌ച ആക്‌സസ് ചെയ്യുന്നതിന് നിങ്ങൾ ശേഷിക്കുന്ന അഭ്യർത്ഥനകൾ വീണ്ടും എഴുതേണ്ടിവരും. അല്ലെങ്കിൽ എല്ലാം അതേപടി വിടുക, പക്ഷേ മുൻകൂട്ടി കണക്കാക്കിയ ചില ഡാറ്റ ഉണ്ടെങ്കിൽ അത് കുറഞ്ഞത് ഫലപ്രദമല്ല, പക്ഷേ പല അന്വേഷണങ്ങളും എല്ലായ്പ്പോഴും അത് ഉപയോഗിക്കുന്നില്ല, പക്ഷേ അത് വീണ്ടും കണക്കാക്കുക.

രണ്ടാമതായി, അവർക്ക് ധാരാളം നിയന്ത്രണങ്ങളുണ്ട്:

ഒറാക്കിൾ

5.3.8.4 വേഗത്തിലുള്ള പുതുക്കലിനുള്ള പൊതു നിയന്ത്രണങ്ങൾ

മെറ്റീരിയലൈസ്ഡ് കാഴ്‌ചയുടെ നിർവചിക്കുന്ന ചോദ്യം ഇനിപ്പറയുന്ന രീതിയിൽ പരിമിതപ്പെടുത്തിയിരിക്കുന്നു:

• മെറ്റീരിയലൈസ്ഡ് കാഴ്‌ചയിൽ ആവർത്തിക്കാത്ത പദപ്രയോഗങ്ങളെക്കുറിച്ചുള്ള പരാമർശങ്ങൾ അടങ്ങിയിരിക്കരുത് SYSDATE ഒപ്പം ROWNUM.
• മെറ്റീരിയലൈസ് ചെയ്ത കാഴ്ചയിൽ റഫറൻസുകൾ അടങ്ങിയിരിക്കരുത് RAW or LONG RAW ഡാറ്റ തരങ്ങൾ.
• ഇതിൽ എ അടങ്ങിയിരിക്കാൻ കഴിയില്ല SELECT ലിസ്റ്റ് സബ്ക്വറി.
• ഇതിൽ വിശകലന പ്രവർത്തനങ്ങൾ അടങ്ങിയിരിക്കരുത് (ഉദാഹരണത്തിന്, RANK) ൽ SELECT ഉപവാക്യം.
• ഇതിന് ഒരു പട്ടികയെ പരാമർശിക്കാൻ കഴിയില്ല XMLIndex സൂചിക നിർവചിച്ചിരിക്കുന്നു.
• ഇതിൽ എ അടങ്ങിയിരിക്കാൻ കഴിയില്ല MODEL ഉപവാക്യം.
• ഇതിൽ എ അടങ്ങിയിരിക്കാൻ കഴിയില്ല HAVING ഉപചോദ്യത്തോടുകൂടിയ ഉപവാക്യം.
• ഇതിൽ ഉള്ള നെസ്റ്റഡ് അന്വേഷണങ്ങൾ ഉൾക്കൊള്ളാൻ കഴിയില്ല ANY, ALL, അഥവാ NOT EXISTS.
• ഇതിൽ എ അടങ്ങിയിരിക്കാൻ കഴിയില്ല [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 നിരകൾ.
• ഒന്നോ അതിലധികമോ റിമോട്ട് ടേബിളുകളെ അടിസ്ഥാനമാക്കിയുള്ളതല്ല മെറ്റീരിയലൈസ്ഡ് കാഴ്‌ച.
• നിങ്ങൾ ഒരു ഉപയോഗിക്കുകയാണെങ്കിൽ CHAR മെറ്റീരിയലൈസ്ഡ് വ്യൂ ലോഗിന്റെ ഫിൽട്ടർ കോളങ്ങളിലെ ഡാറ്റാ തരം, മാസ്റ്റർ സൈറ്റിന്റെ പ്രതീക സെറ്റുകളും മെറ്റീരിയലൈസ്ഡ് കാഴ്‌ചയും ഒന്നുതന്നെയായിരിക്കണം.
• മെറ്റീരിയലൈസ് ചെയ്‌ത കാഴ്‌ചയ്‌ക്ക് ഇനിപ്പറയുന്നവയിൽ ഒന്ന് ഉണ്ടെങ്കിൽ, പരമ്പരാഗത DML ഇൻസേർട്ടുകളിലും ഡയറക്ട് ലോഡുകളിലും മാത്രമേ ഫാസ്റ്റ് റിഫ്രഷ് പിന്തുണയ്‌ക്കൂ.
  • ഉപയോഗിച്ച് മെറ്റീരിയൽവൽക്കരിച്ച കാഴ്ചകൾ MIN or MAX സംഖ്യകൾ
  • ഉള്ള വസ്‌തുവൽക്കരിച്ച കാഴ്‌ചകൾ SUM(expr) പക്ഷെ ഇല്ല COUNT(expr)
  • ഇല്ലാത്ത കാഴ്ചകൾ COUNT(*)

  അത്തരം ഭൗതികമായ കാഴ്ചയെ ഇൻസേർട്ട്-ഒൺലി മെറ്റീരിയലൈസ്ഡ് വ്യൂ എന്ന് വിളിക്കുന്നു.

• കൂടെയുള്ള ഒരു വസ്തുനിഷ്ഠമായ കാഴ്ച MAX or MIN ഇല്ലാതാക്കിയതിന് ശേഷം വേഗത്തിൽ പുതുക്കാവുന്നതോ അല്ലെങ്കിൽ മിക്സഡ് ഡിഎംഎൽ പ്രസ്താവനകളോ ഇല്ലെങ്കിൽ WHERE ഉപവാക്യം.
  ഇല്ലാതാക്കിയതിന് ശേഷമുള്ള പരമാവധി/മിനിറ്റ് ഫാസ്റ്റ് റിഫ്രഷ് അല്ലെങ്കിൽ മിക്‌സ്ഡ് ഡിഎംഎല്ലിന് ഇൻസേർട്ട്-ഒൺലി കെയ്‌സിന്റെ അതേ സ്വഭാവം ഇല്ല. ഇത് ബാധിത ഗ്രൂപ്പുകൾക്കായി പരമാവധി/മിനിറ്റ് മൂല്യങ്ങൾ ഇല്ലാതാക്കുകയും വീണ്ടും കണക്കാക്കുകയും ചെയ്യുന്നു. അതിന്റെ പ്രകടന സ്വാധീനത്തെക്കുറിച്ച് നിങ്ങൾ അറിഞ്ഞിരിക്കണം.
• എന്നതിൽ പേരിട്ടിരിക്കുന്ന കാഴ്‌ചകളോ സബ്‌ക്വറികളോ ഉള്ള മെറ്റീരിയലൈസ്ഡ് കാഴ്‌ചകൾ FROM കാഴ്‌ചകൾ പൂർണ്ണമായി ലയിപ്പിക്കാൻ കഴിയുമെങ്കിൽ ക്ലോസ് വേഗത്തിൽ പുതുക്കാൻ കഴിയും. ഏതൊക്കെ കാഴ്‌ചകൾ ലയിക്കും എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾക്ക്, കാണുക ഒറാക്കിൾ ഡാറ്റാബേസ് SQL ഭാഷാ റഫറൻസ്.
• ബാഹ്യ ജോയിനുകളൊന്നും ഇല്ലെങ്കിൽ, നിങ്ങൾക്ക് അനിയന്ത്രിതമായ തിരഞ്ഞെടുപ്പുകളും ചേരലുകളും ഉണ്ടാകാം 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 എന്നതിലെ സബ്ക്വറിയിൽ ആകാം FROM നിർവചിക്കുന്ന ചോദ്യം ഫോമിലാണെന്ന് നൽകിയിട്ടുള്ള ക്ലോസ് SELECT * FROM (കാണുക അല്ലെങ്കിൽ ഉപചോദ്യം UNION ALL) ഇനിപ്പറയുന്ന ഉദാഹരണത്തിലെന്നപോലെ:

  വ്യൂ_വിത്ത്_യൂണിയോണൽ എഎസ് ആയി കാഴ്ച്ച സൃഷ്ടിക്കുക (ഉപഭോക്താക്കളിൽ നിന്ന് c.rowid crid, c.cust_id, 2 umarker തിരഞ്ഞെടുക്കുക c എവിടെയാണ് c.cust_last_name = 'Smith' UNION എല്ലാം തിരഞ്ഞെടുക്കുക c.rowid crid, c.cust_id, 3 ഉപഭോക്താക്കൾ മുതൽ c. 'ജോൺസ്'); വ്യൂ_വിത്ത്_യൂണിയോണലിൽ നിന്ന് തിരഞ്ഞെടുക്കുക * ആവശ്യാനുസരണം മെറ്റീരിയലൈസ്ഡ് വ്യൂ യൂണിയൻ_ഇൻസൈഡ്_വ്യൂ_എംവി വേഗത്തിൽ പുതുക്കുക;
  

  കാഴ്ച എന്നത് ശ്രദ്ധിക്കുക view_with_unionall വേഗത്തിലുള്ള പുതുക്കലിനുള്ള ആവശ്യകതകൾ നിറവേറ്റുന്നു.

• എന്നതിലെ ഓരോ ചോദ്യ ബ്ലോക്കും UNION ALL അഗ്രഗേറ്റുകൾ ഉപയോഗിച്ച് വേഗത്തിൽ പുതുക്കാവുന്ന മെറ്റീരിയലൈസ്ഡ് കാഴ്‌ചയുടെ ആവശ്യകതകൾ അല്ലെങ്കിൽ ജോയിംഗുകൾക്കൊപ്പം വേഗത്തിൽ പുതുക്കാവുന്ന മെറ്റീരിയലൈസ്ഡ് കാഴ്‌ചയുടെ ആവശ്യകതകൾ ചോദ്യം നിറവേറ്റണം.

  ഫാസ്റ്റ് റിഫ്രഷ് ചെയ്യാവുന്ന മെറ്റീരിയലൈസ്ഡ് കാഴ്‌ചയ്‌ക്ക് ആവശ്യമായ മെറ്റീരിയലൈസ്ഡ് വ്യൂ ലോഗുകൾ ടേബിളിൽ സൃഷ്‌ടിച്ചിരിക്കണം.
  ഒറാക്കിൾ ഡാറ്റാബേസ് ഒരൊറ്റ ടേബിളിന്റെ സ്പെഷ്യലൈസ്ഡ് കാഴ്‌ചയെ ജോയിനുകൾ മാത്രം നൽകി അനുവദിക്കുന്നുവെന്നത് ശ്രദ്ധിക്കുക. 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.

ഒറാക്കിൾ ആരാധകരെ വ്രണപ്പെടുത്താൻ ഞാൻ ആഗ്രഹിക്കുന്നില്ല, പക്ഷേ അവരുടെ നിയന്ത്രണങ്ങളുടെ പട്ടിക വിലയിരുത്തുമ്പോൾ, ഈ സംവിധാനം പൊതുവായി എഴുതിയത് ഏതെങ്കിലും തരത്തിലുള്ള മോഡൽ ഉപയോഗിച്ചല്ല, മറിച്ച് ആയിരക്കണക്കിന് ഇന്ത്യക്കാരാണ്, അവിടെ എല്ലാവർക്കും അവസരം നൽകിയിട്ടുണ്ടെന്ന് തോന്നുന്നു. അവരവരുടെ ശാഖ എഴുതുക, ഓരോരുത്തരും അവനവന്റെ കഴിവ് ചെയ്തു. യഥാർത്ഥ യുക്തിക്കായി ഈ സംവിധാനം ഉപയോഗിക്കുന്നത് ഒരു മൈൻഫീൽഡിലൂടെ നടക്കുന്നത് പോലെയാണ്. വ്യക്തമല്ലാത്ത നിയന്ത്രണങ്ങളിൽ ഒന്ന് അടിച്ച് നിങ്ങൾക്ക് എപ്പോൾ വേണമെങ്കിലും ഒരു ഖനി ലഭിക്കും. ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നത് ഒരു പ്രത്യേക ചോദ്യമാണ്, എന്നാൽ ഇത് ഈ ലേഖനത്തിന്റെ പരിധിക്കപ്പുറമാണ്.

Microsoft SQL സെർവർ

അധിക ആവശ്യകതകൾ

SET ഓപ്‌ഷനുകൾക്കും ഡിറ്റർമിനിസ്റ്റിക് ഫംഗ്‌ഷൻ ആവശ്യകതകൾക്കും പുറമേ, ഇനിപ്പറയുന്ന ആവശ്യകതകൾ പാലിക്കേണ്ടതുണ്ട്:

• എക്സിക്യൂട്ട് ചെയ്യുന്ന ഉപയോക്താവ് CREATE INDEX കാഴ്ചയുടെ ഉടമ ആയിരിക്കണം.
• നിങ്ങൾ സൂചിക സൃഷ്ടിക്കുമ്പോൾ, IGNORE_DUP_KEY ഓപ്‌ഷൻ ഓഫ് ആയി സജ്ജീകരിച്ചിരിക്കണം (സ്ഥിരസ്ഥിതി ക്രമീകരണം).
• പട്ടികകൾ രണ്ട് ഭാഗങ്ങളുള്ള പേരുകളാൽ പരാമർശിക്കേണ്ടതാണ്, പദ്ധതി.പട്ടികയുടെ പേര് കാഴ്ച നിർവചനത്തിൽ.
• കാഴ്‌ചയിൽ പരാമർശിച്ചിരിക്കുന്ന ഉപയോക്തൃ-നിർവചിച്ച ഫംഗ്‌ഷനുകൾ ഉപയോഗിച്ച് സൃഷ്‌ടിക്കണം WITH SCHEMABINDING ഓപ്ഷൻ.
• കാഴ്‌ചയിൽ പരാമർശിച്ചിരിക്കുന്ന ഏതൊരു ഉപയോക്തൃ-നിർവചിച്ച ഫംഗ്‌ഷനുകളും രണ്ട് ഭാഗങ്ങളുള്ള പേരുകളാൽ പരാമർശിക്കേണ്ടതാണ്, ..
• ഉപയോക്താവ് നിർവചിച്ച ഫംഗ്‌ഷന്റെ ഡാറ്റ ആക്‌സസ് പ്രോപ്പർട്ടി ആയിരിക്കണം NO SQL, കൂടാതെ ബാഹ്യ ആക്സസ് പ്രോപ്പർട്ടി ആയിരിക്കണം NO.
• കോമൺ ലാംഗ്വേജ് റൺടൈം (CLR) ഫംഗ്‌ഷനുകൾ കാഴ്‌ചയുടെ തിരഞ്ഞെടുത്ത ലിസ്റ്റിൽ ദൃശ്യമാകും, പക്ഷേ ക്ലസ്റ്റേർഡ് ഇൻഡക്‌സ് കീയുടെ നിർവചനത്തിന്റെ ഭാഗമാകാൻ കഴിയില്ല. CLR ഫംഗ്‌ഷനുകൾ കാഴ്‌ചയുടെ WHERE ക്ലോസിലോ ഒരു ജോയിൻ ഓപ്പറേഷന്റെ ഓൺ ക്ലോസിലോ ദൃശ്യമാകില്ല.
• കാഴ്‌ച നിർവചനത്തിൽ ഉപയോഗിക്കുന്ന CLR ഉപയോക്തൃ-നിർവചിച്ച തരങ്ങളുടെ CLR ഫംഗ്‌ഷനുകളും രീതികളും ഇനിപ്പറയുന്ന പട്ടികയിൽ കാണിച്ചിരിക്കുന്നതുപോലെ സജ്ജീകരിച്ച പ്രോപ്പർട്ടികൾ ഉണ്ടായിരിക്കണം.

  പ്രോപ്പർട്ടി
  കുറിപ്പ്

  ഡിറ്റർമിനിസ്റ്റിക് = ശരി
  Microsoft .NET Framework രീതിയുടെ ആട്രിബ്യൂട്ടായി വ്യക്തമായി പ്രഖ്യാപിക്കണം.

  PRECISE = TRUE
  .NET ഫ്രെയിംവർക്ക് രീതിയുടെ ആട്രിബ്യൂട്ടായി വ്യക്തമായി പ്രഖ്യാപിക്കണം.

  ഡാറ്റ ആക്സസ് = SQL ഇല്ല
  DataAccessKind.None എന്നതിലേക്കും SystemDataAccess ആട്രിബ്യൂട്ട് SystemDataAccessKind.None എന്നതിലേക്കും സജ്ജീകരിച്ചുകൊണ്ട് നിർണ്ണയിക്കപ്പെടുന്നു.

  ബാഹ്യ പ്രവേശനം = ഇല്ല
  CLR ദിനചര്യകൾക്കായി ഈ പ്രോപ്പർട്ടി NO എന്നതിലേക്ക് ഡിഫോൾട്ട് ചെയ്യുന്നു.

• ഉപയോഗിച്ച് കാഴ്ച സൃഷ്ടിക്കണം WITH SCHEMABINDING ഓപ്ഷൻ.
• കാഴ്‌ചയുടെ അതേ ഡാറ്റാബേസിൽ ഉള്ള അടിസ്ഥാന ടേബിളുകൾ മാത്രമേ കാഴ്‌ച പരാമർശിക്കാവൂ. കാഴ്ചയ്ക്ക് മറ്റ് കാഴ്ചകൾ പരാമർശിക്കാൻ കഴിയില്ല.
• കാഴ്ച നിർവചനത്തിലെ SELECT പ്രസ്താവനയിൽ ഇനിപ്പറയുന്ന ഇടപാട്-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, ടെക്സ്റ്റ്, 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 നിലവിലുണ്ട്, VIEW നിർവചനത്തിൽ അടങ്ങിയിരിക്കണം COUNT_BIG(*) അടങ്ങിയിരിക്കരുത് HAVING. ഇവ GROUP BY ഇൻഡെക്‌സ് ചെയ്‌ത കാഴ്‌ച നിർവചനത്തിന് മാത്രമേ നിയന്ത്രണങ്ങൾ ബാധകമാകൂ. ഇവ തൃപ്തികരമല്ലെങ്കിൽപ്പോലും ഒരു അന്വേഷണത്തിന് അതിന്റെ എക്സിക്യൂഷൻ പ്ലാനിൽ ഒരു സൂചികയിലുള്ള കാഴ്ച ഉപയോഗിക്കാനാകും GROUP BY നിയന്ത്രണങ്ങൾ.
• കാഴ്ചയുടെ നിർവചനത്തിൽ എ GROUP BY ക്ലോസ്, അദ്വിതീയ ക്ലസ്റ്റേർഡ് ഇൻഡക്‌സിന്റെ കീയിൽ വ്യക്തമാക്കിയിരിക്കുന്ന നിരകളെ മാത്രമേ പരാമർശിക്കാൻ കഴിയൂ GROUP BY ഉപവാക്യം.

"ഞങ്ങൾ കുറച്ച് ചെയ്യും, പക്ഷേ നന്നായി" എന്ന സ്കീം അനുസരിച്ച് ഇത് ചെയ്യാൻ അവർ തീരുമാനിച്ചതിനാൽ ഇന്ത്യക്കാർ അതിൽ ഉൾപ്പെട്ടിട്ടില്ലെന്ന് ഇവിടെ വ്യക്തമാണ്. അതായത്, അവർക്ക് മൈതാനത്ത് കൂടുതൽ ഖനികളുണ്ട്, പക്ഷേ അവയുടെ സ്ഥാനം കൂടുതൽ സുതാര്യമാണ്. ഏറ്റവും നിരാശാജനകമായ കാര്യം ഈ പരിമിതിയാണ്:

കാഴ്‌ചയുടെ അതേ ഡാറ്റാബേസിൽ ഉള്ള അടിസ്ഥാന ടേബിളുകൾ മാത്രമേ കാഴ്‌ച പരാമർശിക്കാവൂ. കാഴ്ചയ്ക്ക് മറ്റ് കാഴ്ചകൾ പരാമർശിക്കാൻ കഴിയില്ല.

നമ്മുടെ പദാവലിയിൽ, ഒരു ഫംഗ്‌ഷന് മറ്റൊരു മെറ്റീരിയൽ ഫംഗ്‌ഷൻ ആക്‌സസ് ചെയ്യാൻ കഴിയില്ല എന്നാണ് ഇതിനർത്ഥം. ഇത് മുകുളത്തിലെ എല്ലാ പ്രത്യയശാസ്ത്രങ്ങളെയും വെട്ടിമാറ്റുന്നു.
കൂടാതെ, ഈ പരിമിതി (കൂടുതൽ വാചകത്തിൽ) ഉപയോഗ കേസുകൾ വളരെയധികം കുറയ്ക്കുന്നു:

കാഴ്ച നിർവചനത്തിലെ SELECT പ്രസ്താവനയിൽ ഇനിപ്പറയുന്ന ഇടപാട്-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, ടെക്സ്റ്റ്, 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

ഔട്ടർ ജോയിൻസ്, യൂണിയൻ, ഓർഡർ ബൈ എന്നിവയും മറ്റുള്ളവയും നിരോധിച്ചിരിക്കുന്നു. ഉപയോഗിക്കാനാകാത്തതിനെക്കാൾ എന്തെല്ലാം ഉപയോഗിക്കാമെന്ന് വ്യക്തമാക്കുന്നത് എളുപ്പമായിരുന്നിരിക്കാം. പട്ടിക ഒരുപക്ഷേ വളരെ ചെറുതായിരിക്കും.

ചുരുക്കത്തിൽ: LGPL സാങ്കേതികവിദ്യയിലെ എല്ലാ (വാണിജ്യപരമായും ശ്രദ്ധിക്കാം) DBMS വേഴ്സസ് (ഒരു ലോജിക്കൽ ഒഴികെ, സാങ്കേതികമല്ലാത്തത്) നിയന്ത്രണങ്ങളുടെ ഒരു വലിയ കൂട്ടം. എന്നിരുന്നാലും, വിവരിച്ച ഫംഗ്ഷണൽ ലോജിക്കിനെ അപേക്ഷിച്ച് റിലേഷണൽ ലോജിക്കിൽ ഈ സംവിധാനം നടപ്പിലാക്കുന്നത് കുറച്ചുകൂടി ബുദ്ധിമുട്ടാണ് എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്.

നടപ്പാക്കൽ

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു? PostgreSQL ഒരു "വെർച്വൽ മെഷീൻ" ആയി ഉപയോഗിക്കുന്നു. ചോദ്യങ്ങൾ നിർമ്മിക്കുന്ന സങ്കീർണ്ണമായ ഒരു അൽഗോരിതം ഉള്ളിലുണ്ട്. ഇവിടെ ഉറവിടം. ഒരു കൂട്ടം ifs ഉള്ള ഹ്യൂറിസ്റ്റിക്‌സിന്റെ ഒരു വലിയ കൂട്ടം മാത്രമല്ല ഉള്ളത്. അതിനാൽ, നിങ്ങൾക്ക് പഠിക്കാൻ രണ്ട് മാസമുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് വാസ്തുവിദ്യ മനസ്സിലാക്കാൻ ശ്രമിക്കാം.

ഇത് ഫലപ്രദമായി പ്രവർത്തിക്കുന്നുണ്ടോ? തികച്ചും ഫലപ്രദമാണ്. നിർഭാഗ്യവശാൽ, ഇത് തെളിയിക്കാൻ പ്രയാസമാണ്. വലിയ ആപ്ലിക്കേഷനുകളിൽ നിലവിലുള്ള ആയിരക്കണക്കിന് അന്വേഷണങ്ങൾ നിങ്ങൾ പരിഗണിക്കുകയാണെങ്കിൽ, ശരാശരി അവ ഒരു നല്ല ഡെവലപ്പറുടെതിനേക്കാൾ കാര്യക്ഷമമാണെന്ന് മാത്രമേ എനിക്ക് പറയാൻ കഴിയൂ. ഒരു മികച്ച SQL പ്രോഗ്രാമർക്ക് ഏത് ചോദ്യവും കൂടുതൽ കാര്യക്ഷമമായി എഴുതാൻ കഴിയും, എന്നാൽ ആയിരം ചോദ്യങ്ങളുണ്ടെങ്കിൽ അത് ചെയ്യാൻ അദ്ദേഹത്തിന് പ്രചോദനമോ സമയമോ ഉണ്ടാകില്ല. ഈ DBMS-ൽ നിർമ്മിച്ച പ്ലാറ്റ്‌ഫോമിൽ നിരവധി പ്രോജക്ടുകൾ പ്രവർത്തിക്കുന്നു എന്നതാണ് ഫലപ്രാപ്തിയുടെ തെളിവായി എനിക്ക് ഇപ്പോൾ ഉദ്ധരിക്കാൻ കഴിയുന്ന ഒരേയൊരു കാര്യം. ERP സംവിധാനങ്ങൾ, ആയിരക്കണക്കിന് വ്യത്യസ്ത മെറ്റീരിയൽ ഫംഗ്‌ഷനുകളുള്ള, ആയിരക്കണക്കിന് ഉപയോക്താക്കളും ടെറാബൈറ്റ് ഡാറ്റാബേസുകളും ഒരു സാധാരണ രണ്ട്-പ്രോസസർ സെർവറിൽ പ്രവർത്തിക്കുന്ന നൂറുകണക്കിന് ദശലക്ഷക്കണക്കിന് റെക്കോർഡുകളുമുണ്ട്. എന്നിരുന്നാലും, ഡൗൺലോഡ് ചെയ്യുന്നതിലൂടെ ആർക്കും ഫലപ്രാപ്തി പരിശോധിക്കാം/ നിരസിക്കാം പ്ലാറ്റ്ഫോം കൂടാതെ PostgreSQL, ഓൺചെയ്യുന്നു SQL അന്വേഷണങ്ങൾ ലോഗ് ചെയ്യുകയും ലോജിക്കും ഡാറ്റയും മാറ്റാൻ ശ്രമിക്കുകയും ചെയ്യുന്നു.

ഇനിപ്പറയുന്ന ലേഖനങ്ങളിൽ, ഫംഗ്‌ഷനുകളിൽ നിങ്ങൾക്ക് എങ്ങനെ നിയന്ത്രണങ്ങൾ സജ്ജീകരിക്കാം, മാറ്റ സെഷനുകൾക്കൊപ്പം പ്രവർത്തിക്കാം, കൂടാതെ മറ്റു പലതിനെക്കുറിച്ചും ഞാൻ സംസാരിക്കും.

അവലംബം: www.habr.com