PostgreSQL એન્ટિપેટર્ન: SQL માં સ્થિતિ મૂલ્યાંકન

SQL એ C++ નથી, ન તો તે JavaScript છે. તેથી, તાર્કિક અભિવ્યક્તિઓનું મૂલ્યાંકન અલગ છે, અને આ એક જ વસ્તુ નથી:

WHERE fncondX() AND fncondY()

= fncondX() && fncondY()

PostgreSQL ક્વેરીનો અમલ કરવાની યોજનાને ઑપ્ટિમાઇઝ કરતી વખતે મનસ્વી રીતે સમકક્ષ શરતો "પુનઃવ્યવસ્થિત" કરી શકે છે, વ્યક્તિગત રેકોર્ડ્સ માટે તેમાંથી કોઈપણની ગણતરી કરશો નહીં, લાગુ કરેલ ઇન્ડેક્સની સ્થિતિનો સંદર્ભ લો... ટૂંકમાં, સૌથી સહેલો રસ્તો એ છે કે તમે મેનેજ કરી શકતા નથી તેઓ કયા ક્રમમાં હશે (અને શું તેમની ગણતરી કરવામાં આવશે) સમાન શરતો

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

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

#0: RTFM

શરૂ કરી રહ્યા છીએ દસ્તાવેજીકરણમાંથી ઉદાહરણ:

જ્યારે મૂલ્યાંકનનો ક્રમ મહત્વપૂર્ણ હોય, ત્યારે તેને રચના સાથે નિશ્ચિત કરી શકાય છે CASE. ઉદાહરણ તરીકે, વાક્યમાં શૂન્ય દ્વારા ભાગાકારને ટાળવાની આ રીત WHERE અવિશ્વસનીય:

SELECT ... WHERE x > 0 AND y/x > 1.5;

સલામત વિકલ્પ:

SELECT ... WHERE CASE WHEN x > 0 THEN y/x > 1.5 ELSE false END;

વપરાયેલ બાંધકામ CASE અભિવ્યક્તિને ઑપ્ટિમાઇઝેશનથી સુરક્ષિત કરે છે, તેથી જ્યારે જરૂરી હોય ત્યારે જ તેનો ઉપયોગ કરવો જોઈએ.

#1: ટ્રિગર સ્થિતિ

BEGIN
  IF cond(NEW.fld) AND EXISTS(SELECT ...) THEN
    ...
  END IF;
  RETURN NEW;
END;

બધું સારું લાગે છે, પરંતુ... કોઈએ વચન આપ્યું નથી કે રોકાણ કર્યું છે SELECT જો પ્રથમ શરત ખોટી હોય તો ચલાવવામાં આવશે નહીં. સાથે તેને ઠીક કરો નેસ્ટેડ IF:

BEGIN
  IF cond(NEW.fld) THEN
    IF EXISTS(SELECT ...) THEN
      ...
    END IF;
  END IF;
  RETURN NEW;
END;

હવે ચાલો કાળજીપૂર્વક જોઈએ - ટ્રિગર ફંક્શનનું આખું શરીર "આવરિત" હોવાનું બહાર આવ્યું IF. અને આનો અર્થ એ છે કે અમને આ સ્થિતિને પ્રક્રિયામાંથી દૂર કરવાથી કંઈપણ અટકાવતું નથી WHEN- શરતો:

BEGIN
  IF EXISTS(SELECT ...) THEN
    ...
  END IF;
  RETURN NEW;
END;
...
CREATE TRIGGER ...
  WHEN cond(NEW.fld);

જો શરત ખોટી હોય તો આ અભિગમ તમને ગેરંટી સાથે સર્વર સંસાધનોને બચાવવા માટે પરવાનગી આપે છે.

#2: અથવા/અને સાંકળ

SELECT ... WHERE EXISTS(... A) OR EXISTS(... B)

નહિંતર, તે મેળવી શકાય છે કે બંને EXISTS સાચું હશે, પરંતુ બંને ચલાવવામાં આવશે.

પરંતુ જો આપણે ખાતરીપૂર્વક જાણીએ કે તેમાંથી એક "સાચું" છે ઘણી વાર (અથવા "ખોટા" - માટે AND-ચેઇન્સ) - શું કોઈક રીતે "તેની પ્રાધાન્યતા વધારવી" શક્ય છે જેથી બીજી વાર ફરીથી અમલમાં ન આવે?

તે તારણ આપે છે કે તે શક્ય છે - અલ્ગોરિધમિકલ અભિગમ લેખના વિષયની નજીક છે PostgreSQL એન્ટિપેટર્ન: દુર્લભ એન્ટ્રી જોઇનની મધ્યમાં પહોંચે છે.

ચાલો આ બંને શરતોને ફક્ત "કેસ હેઠળ ધક્કો મારીએ":

SELECT ...
WHERE
  CASE
    WHEN EXISTS(... A) THEN TRUE
    WHEN EXISTS(... B) THEN TRUE
  END

આ કિસ્સામાં, અમે વ્યાખ્યાયિત કર્યું નથી ELSE-મૂલ્ય, એટલે કે, જો બંને શરતો ખોટી હોય CASE પાછા આવસે NULL, જે તરીકે અર્થઘટન કરવામાં આવે છે FALSE в WHERE- શરતો.

આ ઉદાહરણને બીજી રીતે જોડી શકાય છે - સ્વાદ અને રંગ માટે:

SELECT ...
WHERE
  CASE
    WHEN NOT EXISTS(... A) THEN EXISTS(... B)
    ELSE TRUE
  END

#3: શરતો કેવી રીતે લખવી [નહીં]

અમે આ ટ્રિગરના "વિચિત્ર" ટ્રિગરિંગના કારણોનું વિશ્લેષણ કરવામાં બે દિવસ ગાળ્યા - ચાલો જોઈએ શા માટે.

સ્ત્રોત:

IF( NEW."Документ_" is null or NEW."Документ_" = (select '"Комплект"'::regclass::oid) or NEW."Документ_" = (select to_regclass('"ДокументПоЗарплате"')::oid)
     AND (   OLD."ДокументНашаОрганизация" <> NEW."ДокументНашаОрганизация"
          OR OLD."Удален" <> NEW."Удален"
          OR OLD."Дата" <> NEW."Дата"
          OR OLD."Время" <> NEW."Время"
          OR OLD."ЛицоСоздал" <> NEW."ЛицоСоздал" ) ) THEN ...

સમસ્યા #1: અસમાનતા NULL માટે જવાબદાર નથી

ચાલો માની લઈએ કે બધું OLD- ક્ષેત્રો મહત્વપૂર્ણ છે NULL. શું થશે?

SELECT NULL <> 1 OR NULL <> 2;
-- NULL

અને શરતો બહાર કામ ના દૃષ્ટિકોણથી NULL સમકક્ષ FALSE, ઉપર જણાવ્યા મુજબ.

નિર્ણય: ઓપરેટરનો ઉપયોગ કરો IS DISTINCT FROM થી ROW-ઓપરેટર, એકસાથે સમગ્ર રેકોર્ડની તુલના:

SELECT (NULL, NULL) IS DISTINCT FROM (1, 2);
-- TRUE

સમસ્યા નંબર 2: સમાન કાર્યક્ષમતાના વિવિધ અમલીકરણ

સરખામણી કરો:

NEW."Документ_" = (select '"Комплект"'::regclass::oid)
NEW."Документ_" = (select to_regclass('"ДокументПоЗарплате"')::oid)

શા માટે વધારાના રોકાણો છે SELECT? એક કાર્ય to_regclass? કેમ અલગ છે...

ચાલો ઠીક કરીએ:

NEW."Документ_" = '"Комплект"'::regclass::oid
NEW."Документ_" = '"ДокументПоЗарплате"'::regclass::oid

સમસ્યા #3: બુલ અગ્રતા

ચાલો સ્ત્રોતને ફોર્મેટ કરીએ:

{... IS NULL} OR
{... Комплект} OR
{... ДокументПоЗарплате} AND
( {... неравенства} )

અરેરે... હકીકતમાં, તે બહાર આવ્યું છે કે પ્રથમ બે સ્થિતિઓમાંથી કોઈપણની સત્યતાના કિસ્સામાં, સમગ્ર સ્થિતિ TRUE, અસમાનતાઓની અવગણના. અને આ આપણે જે ઇચ્છતા હતા તે બિલકુલ નથી.

ચાલો ઠીક કરીએ:

(
  {... IS NULL} OR
  {... Комплект} OR
  {... ДокументПоЗарплате}
) AND
( {... неравенства} )

સમસ્યા #4 (નાની): જટિલ અથવા એક ક્ષેત્ર માટે સ્થિતિ

ખરેખર, અમને નંબર 3 માં સમસ્યા હતી કારણ કે ત્યાં ત્રણ શરતો હતી. પરંતુ તેમને બદલે, તમે મિકેનિઝમનો ઉપયોગ કરીને એક સાથે મેળવી શકો છો coalesce ... IN:

coalesce(NEW."Документ_"::text, '') IN ('', '"Комплект"', '"ДокументПоЗарплате"')

અમે પણ છે NULL "કેચ", અને જટિલ OR તમારે કૌંસ સાથે ગડબડ કરવાની જરૂર નથી.

કુલ

ચાલો આપણે જે મેળવ્યું તેને ઠીક કરીએ:

IF (
  coalesce(NEW."Документ_"::text, '') IN ('', '"Комплект"', '"ДокументПоЗарплате"') AND
  (
    OLD."ДокументНашаОрганизация"
  , OLD."Удален"
  , OLD."Дата"
  , OLD."Время"
  , OLD."ЛицоСоздал"
  ) IS DISTINCT FROM (
    NEW."ДокументНашаОрганизация"
  , NEW."Удален"
  , NEW."Дата"
  , NEW."Время"
  , NEW."ЛицоСоздал"
  )
) THEN ...

અને આપેલ છે કે આ ટ્રિગર ફંક્શનનો ઉપયોગ ફક્ત માં જ થઈ શકે છે UPDATEહાજરીને કારણે ટ્રિગર OLD/NEW ઉપલા સ્તરની સ્થિતિમાં, પછી આ સ્થિતિ સામાન્ય રીતે બહાર લઈ શકાય છે WHEN#1 માં બતાવ્યા પ્રમાણે સ્થિતિ...

સોર્સ: www.habr.com