🥇PostgreSQLren aurkako ereduak: Baldintzen ebaluazioa SQLn

SQL ez da C++, ezta JavaScript ere. Beraz, adierazpen logikoen ebaluazioa ezberdina da, eta hau ez da batere gauza bera:

WHERE fncondX() AND fncondY()

= fncondX() && fncondY()

PostgreSQL kontsulta baten exekuzio plana optimizatzen duzun bitartean Baldintza baliokideak modu arbitrarioan "berrantolatu" ditzake, ez kalkulatu horietako bat erregistro indibidualetarako, aipatu aplikatutako indizearen baldintza... Laburbilduz, modurik errazena zuk suposatzea da. ezin kudeatu ordenan egongo diren (eta zenbatuko diren ala ez) berdinak baldintzak.

Hori dela eta, oraindik lehentasuna kudeatu nahi baduzu, egituraz egin behar duzu baldintza hauek desorekatu baldintzarekin esamoldeak и operadoreak.

Datuak eta haiekin lan egitea da oinarria gure VLSI konplexuarena, beraz, guretzat oso garrantzitsua da haietako eragiketak zuzen ez ezik, eraginkortasunez ere egitea. Ikus ditzagun adibide zehatzak non adierazpen-ebaluazioan akatsak egin daitezkeen eta non merezi duen haien eraginkortasuna hobetzea.

#0: RTFM

Hasi dokumentaziotik ateratako adibidea:

Ebaluazio-ordena garrantzitsua denean, konstruktuarekin finkatu daiteke CASE. Adibidez, modu honetan esaldi batean zeroz zatitzea saihesteko WHERE fidagarria:
SELECT ... WHERE x > 0 AND y/x > 1.5;
Aukera segurua:
SELECT ... WHERE CASE WHEN x > 0 THEN y/x > 1.5 ELSE false END;
Erabilitako eraikuntza CASE Adierazpena optimizaziotik babesten du, beraz, beharrezkoa denean bakarrik erabili behar da.

#1: trigger-baldintza

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

Dena itxura ona dirudi, baina... Inork ez du agintzen inbertitu duenik SELECT ez da exekutatuko lehen baldintza faltsua bada. Konpondu habiaratu IF:

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

Ikus dezagun arretaz: abiarazle-funtzioaren gorputz osoa "bilduta" zegoen IF. Eta horrek esan nahi du ezerk ez digula eragozten baldintza hau prozedura erabiliz kentzea WHEN-baldintzak:

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

Ikuspegi honek zerbitzariaren baliabideak berme batekin gorde ditzakezu baldintza faltsua bada.

#2: EDO/ETA katea

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

Bestela, lor daiteke biak EXISTS egia izango da, baina biak exekutatu egingo dira.

Baina ziur badakigu horietako bat "egia" dela askoz maizago (edo "gezurra" - zeren AND-kateak) - posible al da nolabait "bere lehentasuna handitzea" bigarrena berriro ere exekutatu ez dadin?

Posible dela ematen du - algoritmikoki hurbilketa artikuluaren gaitik hurbil dago PostgreSQLren aurkako ereduak: sarrera arraroa JOIN baten erdira iristen da.

Eman ditzagun bi baldintza hauek "KASU azpian":

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

Kasu honetan, ez dugu definitu ELSE-balioa, hau da, baldintza biak faltsuak badira CASE itzuliko da NULL, honela interpretatzen dena FALSE в WHERE- baldintzak.

Adibide hau beste modu batean konbina daiteke - dastatzeko eta koloreztatzeko:

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

#3: nola [ez] idatzi baldintzak

Bi egun eman genituen abiarazle honen abiarazte "arraro"aren arrazoiak aztertzen - ikus dezagun zergatik.

Iturria:

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. arazoa: Desberdintasunak ez du NULL kontuan hartzen

Demagun dena OLD-eremuek garrantzia zuten NULL. Zer gertatuko da?

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

Eta baldintzak lantzearen ikuspuntutik NULL baliokidea FALSE, goian esan bezala.

Erabaki: erabili operadorea IS DISTINCT FROM tik ROW-operadorea, erregistro osoak aldi berean alderatuz:

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

2. problema: funtzionalitate beraren ezarpen ezberdina

Dezagun konparatu:

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

Zergatik daude aparteko inbertsioak SELECT? Funtzio bat to_regclass? Zergatik da ezberdina...

Konpon dezagun:

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

3. arazoa: bool lehentasuna

Formateatu dezagun iturria:

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

Aupa... Izan ere, lehen bi baldintzen egiaren kasuan, baldintza osoa bihurtzen da. TRUE, desberdintasunak alde batera utzita. Eta hau ez da batere nahi genuena.

Konpon dezagun:

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

4. arazoa (txikia): eremu baterako EDO baldintza konplexua

Egia esan, 3. zenbakian arazoak izan genituen, hain zuzen ere, hiru baldintza zeudelako. Baina horien ordez, bat egin dezakezu, mekanismoa erabiliz coalesce ... IN:

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

Gu ere bai NULL "harrapatzea", eta konplexua OR Ez duzu parentesiekin nahastu behar.

Guztira

Konpon dezagun lortu duguna:

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

Eta abiarazte-funtzio hau bakarrik erabil daitekeela kontuan hartuta UPDATEabiarazlea presentzia dela eta OLD/NEW goi-mailako egoeran, orduan egoera hori orokorrean atera daiteke WHEN-baldintza #1-n erakusten den moduan...

Iturria: www.habr.com

PostgreSQLren aurkako ereduak: Baldintzen ebaluazioa SQLn