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 ആന്റിപാറ്റേണുകൾ: ഒരു അപൂർവ റെക്കോർഡ് ഒരു ജോയിനിന്റെ മധ്യത്തിൽ എത്തും.

CASE-ന് കീഴിൽ ഈ രണ്ട് വ്യവസ്ഥകളും നമുക്ക് "തള്ളുക":

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-ൽ കാണിച്ചിരിക്കുന്നതുപോലെ -condition...

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