સંતુલન ડેટાબેઝમાં લખે છે અને વાંચે છે

અગાઉના માં લેખ મેં રિલેશનલ ડેટાબેસેસની જેમ કોષ્ટકો અને ક્ષેત્રોને બદલે ફંક્શનના આધારે બનેલા ડેટાબેઝના ખ્યાલ અને અમલીકરણનું વર્ણન કર્યું છે. તે ક્લાસિકલ એક કરતાં આ અભિગમના ફાયદા દર્શાવતા ઘણા ઉદાહરણો પ્રદાન કરે છે. ઘણાને તેઓ પૂરતા વિશ્વાસપાત્ર ન જણાયા.

આ લેખમાં, હું બતાવીશ કે કેવી રીતે આ ખ્યાલ તમને ઓપરેટિંગ તર્કમાં કોઈ ફેરફાર કર્યા વિના ડેટાબેઝમાં લખવા અને વાંચવાને ઝડપથી અને સરળતાથી સંતુલિત કરવાની મંજૂરી આપે છે. આધુનિક કોમર્શિયલ ડીબીએમએસ (ખાસ કરીને, ઓરેકલ અને માઇક્રોસોફ્ટ એસક્યુએલ સર્વર) માં સમાન કાર્યક્ષમતા લાગુ કરવાનો પ્રયાસ કરવામાં આવ્યો છે. લેખના અંતે હું બતાવીશ કે તેઓએ જે કર્યું, તેને હળવાશથી કહીએ તો, બહુ સારું કામ ન કર્યું.

વર્ણન

પહેલાની જેમ, વધુ સારી રીતે સમજવા માટે હું ઉદાહરણો સાથે વર્ણન શરૂ કરીશ. ચાલો કહીએ કે આપણે એવા તર્કને અમલમાં મૂકવાની જરૂર છે જે વિભાગોની સૂચિ પરત કરશે જેમાં કર્મચારીઓની સંખ્યા અને તેમના કુલ પગાર છે.

કાર્યાત્મક ડેટાબેઝમાં તે આના જેવું દેખાશે:

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 (કર્મચારીઓની સંખ્યા લોગ) અથવા O(વિભાગોની સંખ્યા) જૂથ બનાવવા માટે અને તેથી વધુ.

તે સ્પષ્ટ છે કે વિવિધ DBMS માં એક્ઝેક્યુશન ઓવરહેડ અલગ હોઈ શકે છે, પરંતુ જટિલતા કોઈપણ રીતે બદલાશે નહીં.

સૂચિત અમલીકરણમાં, કાર્યાત્મક DBMS એક સબક્વેરી જનરેટ કરશે જે વિભાગ માટે જરૂરી મૂલ્યોની ગણતરી કરશે, અને પછી નામ મેળવવા માટે વિભાગના ટેબલ સાથે જોડાઓ. જો કે, દરેક કાર્ય માટે, જ્યારે ઘોષણા કરવામાં આવે છે, ત્યારે વિશિષ્ટ સામગ્રીયુક્ત માર્કર સેટ કરવાનું શક્ય છે. સિસ્ટમ આવા દરેક કાર્ય માટે આપમેળે અનુરૂપ ક્ષેત્ર બનાવશે. ફંક્શનની કિંમત બદલતી વખતે, તે જ વ્યવહારમાં ફીલ્ડની કિંમત પણ બદલાશે. આ ફંક્શનને એક્સેસ કરતી વખતે, પૂર્વ ગણતરી કરેલ ફીલ્ડ એક્સેસ કરવામાં આવશે.

ખાસ કરીને, જો તમે વિધેયો માટે MATERIALIZED સેટ કરો છો કર્મચારીઓની સંખ્યા и પગાર રકમ, પછી વિભાગોની સૂચિ સાથે કોષ્ટકમાં બે ક્ષેત્રો ઉમેરવામાં આવશે, જે કર્મચારીઓની સંખ્યા અને તેમના કુલ પગારને સંગ્રહિત કરશે. જ્યારે પણ કર્મચારીઓ, તેમના પગાર અથવા વિભાગના જોડાણમાં ફેરફાર થાય છે, ત્યારે સિસ્ટમ આપોઆપ આ ક્ષેત્રોના મૂલ્યોમાં ફેરફાર કરશે. ઉપરોક્ત ક્વેરી આ ફીલ્ડ્સને સીધા જ એક્સેસ કરશે અને તેમાં એક્ઝિક્યુટ કરવામાં આવશે 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 હશે નહિ. તેના બદલે એક સરળ GROUP BY હશે.

આ મિકેનિઝમનો ઉપયોગ કરીને, જો જરૂરી હોય તો તમે ડેટાબેઝને સરળતાથી ડિનોર્મલાઈઝ પણ કરી શકો છો:

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

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


જ્યારે ફંક્શનને કૉલ કરો તારીખ ઓર્ડર લાઇન માટે, જે ફીલ્ડ માટે ઇન્ડેક્સ છે તે ટેબલમાંથી ઓર્ડર લાઇન સાથે વાંચવામાં આવશે. જ્યારે ઓર્ડરની તારીખ બદલાય છે, ત્યારે સિસ્ટમ પોતે જ લાઇનમાં અસાધારણ તારીખની પુનઃગણતરી કરશે.

લાભો

આ સમગ્ર મિકેનિઝમ શેના માટે છે? ક્લાસિક ડીબીએમએસમાં, ક્વેરી ફરીથી લખ્યા વિના, ડેવલપર અથવા ડીબીએ માત્ર ઇન્ડેક્સ બદલી શકે છે, આંકડા નક્કી કરી શકે છે અને ક્વેરી પ્લાનરને તેને કેવી રીતે એક્ઝિક્યુટ કરવું તે કહી શકે છે (અને હિન્ટ્સ માત્ર કોમર્શિયલ ડીબીએમએસમાં જ ઉપલબ્ધ છે). ભલે તેઓ ગમે તેટલા પ્રયત્નો કરે, તેઓ માં લેખમાં પ્રથમ ક્વેરી પૂર્ણ કરી શકશે નહીં O (વિભાગોની સંખ્યા) ક્વેરીઝ બદલ્યા વિના અથવા ટ્રિગર્સ ઉમેર્યા વિના. સૂચિત યોજનામાં, વિકાસના તબક્કે તમારે ડેટા સ્ટોરેજ સ્ટ્રક્ચર અને કયા એકત્રીકરણનો ઉપયોગ કરવો તે વિશે વિચારવાની જરૂર નથી. આ બધું ફ્લાય પર સરળતાથી બદલી શકાય છે, સીધા ઓપરેશનમાં.

વ્યવહારમાં તે આના જેવો દેખાય છે. કેટલાક લોકો સીધા હાથ પરના કાર્યના આધારે તર્ક વિકસાવે છે. તેઓ અલ્ગોરિધમ્સ અને તેમની જટિલતાને સમજી શકતા નથી, ન એક્ઝેક્યુશન પ્લાન્સ, ન તો જોડાવાના પ્રકારો, ન તો અન્ય કોઈ તકનીકી ઘટક. આ લોકો ડેવલપર્સ કરતાં વધુ બિઝનેસ એનાલિસ્ટ છે. પછી, આ બધું પરીક્ષણ અથવા ઓપરેશનમાં જાય છે. લાંબા સમયથી ચાલતી ક્વેરીઝના લોગીંગને સક્ષમ કરે છે. જ્યારે લાંબી ક્વેરી મળી આવે છે, ત્યારે અન્ય લોકો (વધુ તકનીકી - અનિવાર્યપણે DBA) અમુક મધ્યવર્તી કાર્ય પર MATERIALIZED ને સક્ષમ કરવાનું નક્કી કરે છે. આ રેકોર્ડિંગને થોડું ધીમું કરે છે (કારણ કે તેને વ્યવહારમાં વધારાના ફીલ્ડને અપડેટ કરવાની જરૂર છે). જો કે, માત્ર આ ક્વેરી નોંધપાત્ર રીતે ઝડપી નથી, પણ અન્ય તમામ કે જેઓ આ કાર્યનો ઉપયોગ કરે છે. તે જ સમયે, કયા કાર્યને પૂર્ણ કરવું તે નક્કી કરવું પ્રમાણમાં સરળ છે. બે મુખ્ય પરિમાણો: સંભવિત ઇનપુટ મૂલ્યોની સંખ્યા (આ તે છે કે અનુરૂપ કોષ્ટકમાં કેટલા રેકોર્ડ્સ હશે), અને અન્ય કાર્યોમાં તેનો ઉપયોગ કેટલી વાર થાય છે.

એનાલોગ

આધુનિક કોમર્શિયલ ડીબીએમએસમાં સમાન મિકેનિઝમ છે: ફાસ્ટ રિફ્રેશ (ઓરેકલ) અને ઇન્ડેક્સ્ડ વ્યૂ (માઈક્રોસોફ્ટ એસક્યુએલ સર્વર) સાથે મટીરિયલાઈઝ્ડ વ્યૂ. PostgreSQL માં, ટ્રાન્ઝેક્શનમાં મટીરિયલાઈઝ્ડ વ્યૂ અપડેટ કરી શકાતો નથી, પરંતુ માત્ર વિનંતી પર (અને ખૂબ કડક પ્રતિબંધો સાથે પણ), તેથી અમે તેને ધ્યાનમાં લેતા નથી. પરંતુ તેમની પાસે ઘણી સમસ્યાઓ છે જે તેમના ઉપયોગને નોંધપાત્ર રીતે મર્યાદિત કરે છે.

પ્રથમ, જો તમે પહેલાથી જ નિયમિત દૃશ્ય બનાવ્યું હોય તો જ તમે ભૌતિકીકરણને સક્ષમ કરી શકો છો. નહિંતર, તમારે આ ભૌતિકીકરણનો ઉપયોગ કરવા માટે નવા બનાવેલા દૃશ્યને ઍક્સેસ કરવા માટે બાકીની વિનંતીઓ ફરીથી લખવી પડશે. અથવા બધું જેમ છે તેમ છોડી દો, પરંતુ તે ઓછામાં ઓછું બિનઅસરકારક રહેશે જો ત્યાં ચોક્કસ પહેલાથી ગણતરી કરેલ ડેટા હોય, પરંતુ ઘણી ક્વેરી હંમેશા તેનો ઉપયોગ કરતી નથી, પરંતુ તેની પુનઃગણતરી કરે છે.

બીજું, તેમની પાસે મોટી સંખ્યામાં પ્રતિબંધો છે:

ઓરેકલ

5.3.8.4 ફાસ્ટ રિફ્રેશ પર સામાન્ય પ્રતિબંધો

ભૌતિક દૃષ્ટિકોણની વ્યાખ્યાયિત ક્વેરી નીચે પ્રમાણે પ્રતિબંધિત છે:

• ભૌતિક દૃષ્ટિકોણમાં પુનરાવર્તિત ન હોય તેવા અભિવ્યક્તિઓનો સંદર્ભ હોવો જોઈએ નહીં SYSDATE અને ROWNUM.
• ભૌતિક દૃશ્યમાં સંદર્ભો ન હોવા જોઈએ RAW or LONG RAW ડેટા પ્રકારો.
• તે સમાવી શકતું નથી SELECT સૂચિ સબક્વેરી.
• તેમાં વિશ્લેષણાત્મક કાર્યો શામેલ હોઈ શકતા નથી (ઉદાહરણ તરીકે, RANKમાં SELECT કલમ
• તે કોષ્ટકનો સંદર્ભ આપી શકતો નથી કે જેના પર a 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 ડિલીટ અથવા મિશ્રિત ડીએમએલ સ્ટેટમેન્ટ જો તેમાં a ન હોય તો તે ઝડપથી રિફ્રેશ કરી શકાય છે 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) નીચેના ઉદાહરણની જેમ:

  જુઓ વ્યુ_વિથ_યુનિયોનલ AS બનાવો (ગ્રાહકો પાસેથી c.rowid crid, c.cust_id, 2 umarker પસંદ કરો c જ્યાં c.cust_last_name = 'Smith' UNION બધા પસંદ કરો c.rowid crid, c.cust_id, 3 umarker FROM ગ્રાહકો પાસેથી c_last_name. 'જોન્સ'); યુનિયનલ_ઇનસાઇડ_વ્યુ_એમવીને મટીરિયલાઇઝ્ડ વ્યુ બનાવો પસંદ કરો * વ્યુ_વિથ_યુનિયનલમાંથી;
  

  નોંધ કરો કે દૃશ્ય 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.

હું ઓરેકલના ચાહકોને નારાજ કરવા માંગતો નથી, પરંતુ તેમના પ્રતિબંધોની સૂચિને ધ્યાનમાં લેતા, એવું લાગે છે કે આ પદ્ધતિ સામાન્ય કેસમાં કોઈક પ્રકારના મોડેલનો ઉપયોગ કરીને લખવામાં આવી નથી, પરંતુ હજારો ભારતીયો દ્વારા લખવામાં આવી હતી, જ્યાં દરેકને તક આપવામાં આવી હતી. તેમની પોતાની શાખા લખો, અને તેમાંના દરેકે તે કરી શકે તે કર્યું. અને કર્યું. વાસ્તવિક તર્ક માટે આ પદ્ધતિનો ઉપયોગ કરવો એ માઇનફિલ્ડમાંથી ચાલવા જેવું છે. તમે કોઈપણ સમયે બિન-સ્પષ્ટ પ્રતિબંધોમાંથી એકને હિટ કરીને ખાણ મેળવી શકો છો. તે કેવી રીતે કાર્ય કરે છે તે પણ એક અલગ પ્રશ્ન છે, પરંતુ તે આ લેખના અવકાશની બહાર છે.

માઈક્રોસોફ્ટ એસક્યુએલ સર્વર

વધારાની જરૂરીયાતો

SET વિકલ્પો અને નિર્ણાયક કાર્ય આવશ્યકતાઓ ઉપરાંત, નીચેની આવશ્યકતાઓને પૂર્ણ કરવી આવશ્યક છે:

• વપરાશકર્તા કે જે એક્ઝિક્યુટ કરે છે CREATE INDEX દૃશ્યનો માલિક હોવો જોઈએ.
• જ્યારે તમે ઇન્ડેક્સ બનાવો છો, ત્યારે IGNORE_DUP_KEY વિકલ્પ બંધ (ડિફૉલ્ટ સેટિંગ) પર સેટ હોવો જોઈએ.
• કોષ્ટકો બે ભાગના નામો દ્વારા સંદર્ભિત હોવા જોઈએ, સ્કીમા.ટેબલનું નામ દૃશ્ય વ્યાખ્યામાં.
• દૃશ્યમાં સંદર્ભિત વપરાશકર્તા-વ્યાખ્યાયિત કાર્યોનો ઉપયોગ કરીને બનાવવો આવશ્યક છે WITH SCHEMABINDING વિકલ્પ.
• દૃશ્યમાં સંદર્ભિત કોઈપણ વપરાશકર્તા-વ્યાખ્યાયિત કાર્યો બે-ભાગના નામો દ્વારા સંદર્ભિત હોવા જોઈએ, ..
• વપરાશકર્તા દ્વારા નિર્ધારિત કાર્યની ડેટા એક્સેસ પ્રોપર્ટી હોવી આવશ્યક છે NO SQL, અને બાહ્ય ઍક્સેસ મિલકત હોવી આવશ્યક છે NO.
• કોમન લેંગ્વેજ રનટાઈમ (CLR) ફંક્શન્સ વ્યુની સિલેક્ટ લિસ્ટમાં દેખાઈ શકે છે, પરંતુ ક્લસ્ટર્ડ ઈન્ડેક્સ કીની વ્યાખ્યાનો ભાગ ન હોઈ શકે. CLR ફંક્શન્સ વ્યૂના WHERE ક્લોઝ અથવા વ્યૂમાં JOIN ઑપરેશનના ON ક્લોઝમાં દેખાઈ શકતા નથી.
• વ્યુ ડેફિનેશનમાં ઉપયોગમાં લેવાતા CLR વપરાશકર્તા-વ્યાખ્યાયિત પ્રકારોના CLR ફંક્શન્સ અને પદ્ધતિઓમાં નીચેના કોષ્ટકમાં બતાવ્યા પ્રમાણે ગુણધર્મો સેટ હોવા જોઈએ.

  સંપત્તિ
  નૉૅધ

  નિર્ધારિત = સાચું
  Microsoft .NET ફ્રેમવર્ક પદ્ધતિના લક્ષણ તરીકે સ્પષ્ટપણે જાહેર કરવું આવશ્યક છે.

  PRECISE = સાચું
  .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, લખાણ, ntext, છબી, XML, અથવા ફાઇલસ્ટ્રીમ કૉલમ
  સબક્વેરી
  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 સ્ટેટમેન્ટમાં નીચેના 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, લખાણ, ntext, છબી, XML, અથવા ફાઇલસ્ટ્રીમ કૉલમ
સબક્વેરી
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 નો ઉપયોગ "વર્ચ્યુઅલ મશીન" તરીકે થાય છે. અંદર એક જટિલ અલ્ગોરિધમ છે જે પ્રશ્નો બનાવે છે. અહીં સ્ત્રોત. અને આઈએફએસના સમૂહ સાથે હ્યુરિસ્ટિક્સનો માત્ર એક મોટો સમૂહ નથી. તેથી, જો તમારી પાસે અભ્યાસ કરવા માટે થોડા મહિના હોય, તો તમે આર્કિટેક્ચરને સમજવાનો પ્રયાસ કરી શકો છો.

શું તે અસરકારક રીતે કામ કરે છે? તદ્દન અસરકારક. કમનસીબે, આ સાબિત કરવું મુશ્કેલ છે. હું માત્ર એટલું જ કહી શકું છું કે જો તમે મોટી એપ્લિકેશન્સમાં અસ્તિત્વમાં રહેલી હજારો ક્વેરીઝને ધ્યાનમાં લો, તો સરેરાશ તે સારા ડેવલપર કરતાં વધુ કાર્યક્ષમ છે. એક ઉત્તમ એસક્યુએલ પ્રોગ્રામર કોઈપણ ક્વેરી વધુ અસરકારક રીતે લખી શકે છે, પરંતુ હજાર ક્વેરીઝ સાથે તેની પાસે તે કરવા માટે પ્રેરણા અથવા સમય નથી હોતો. અસરકારકતાના પુરાવા તરીકે હું હવે માત્ર એક જ વસ્તુ ટાંકી શકું છું કે આ DBMS પર બનેલા પ્લેટફોર્મ પર ઘણા પ્રોજેક્ટ્સ કામ કરી રહ્યા છે. ERP સિસ્ટમ્સ, જેમાં હજારો યુઝર્સ અને ટેરાબાઈટ ડેટાબેસેસ સાથે હજારો અલગ-અલગ મટીરિયલાઈઝ્ડ ફંક્શન્સ છે, જેમાં સેંકડો મિલિયન રેકોર્ડ્સ નિયમિત બે-પ્રોસેસર સર્વર પર ચાલે છે. જો કે, કોઈપણ ડાઉનલોડ કરીને અસરકારકતા તપાસી/નકારી શકે છે પ્લેટફોર્મ અને PostgreSQL, ચાલુ કરી રહ્યા છીએ એસક્યુએલ ક્વેરી લોગીંગ અને ત્યાં તર્ક અને ડેટા બદલવાનો પ્રયાસ કરી રહ્યા છીએ.

નીચેના લેખોમાં, હું તે વિશે પણ વાત કરીશ કે તમે કેવી રીતે કાર્યો પર નિયંત્રણો સેટ કરી શકો છો, પરિવર્તન સત્રો સાથે કામ કરી શકો છો અને ઘણું બધું.

સોર્સ: www.habr.com