Dotaz: PostgreSQL namespace - podpora pro jazykove mutace

[Johny]

Zdravim, mam takovy problem/napad.... mam databazi ve ktere jsou ulozeny preklady pro urcite tabulky, je to udelane nasledujicim zpusobem (zjednodusene):

t_content_flow
  - id_content_flow (integer)

a k tomu je prekladova tabulka

l_content_flow
  - id_content_flow (integer)
  - id_lang (char2) // FK do tabulky s kodama jazyku
  - cf_name // preklad pro ten t_content_flow

standartne udelam join a pridam do toho podminku pro aktualne nastavenej jazyk v aplikaci.... ale neslo by nejak vyuzit rovnou nejakeho namespace aby me napriklad view vracelo primo aktualni preklad abych se o to nemusel pote starat?

Odpovědi

[Zdenek Kotala]

No teoreticky, by kazdy jazyk mohl mit vlastni schema s tabulkou preklad a pak menit search path. ale osobne mne to prijde dost nebezpecne, asi jako hrat si se sirkama v pracharne. Co Vam vadi na tom where? Muzete treba zkusit partitioning po jazycich, to by melo vliv na rychlost, pokud Vam jde o to.

[Johny]

Nene, zatim mi o rychlost nejde, je to spis o pohodlnosti, ze bych nemusel vsude resit ten where.... ale problem to neni, byl to jenom takovej spis napad :) stejne mam nad tim postavene takove trochu priohnute ORM

[Hlípa]

Jestli jde o pohodlnost, tak tam nechte ten WHERE. Ostatni varianty se mohou zdat jako pohodlnejsi, ale ve finale to prinese spis problemy.

[happy barney]

pre pohodlnosť? To by som:
a) urobil funkciu get_text (refid, language)
b) vytvoril si cache v programe

[default]

Já to na PostgreSQL řešil. Dokonce zde v poradně jsem popisoval způsob, jak jsem toho dosáhnul. Tak se podívej. Třeba ti to pomůže…

[Johny]

Jeee diky ti moc, presne tohle jsem shanel :) Jeste, nemas tuseni jak je to pak s optimalizaci treba ve view? Jestli si to postgresql zacachuje jako v klasickem view?

[default]

Tohle je spíš otázka na pana Stěhuleho. Podle mě PostgreSQL optimalizuje až na úrovni dotazů — tvůj dotaz doplní o definici VIEW:

CREATE OR REPLACE VIEW my_super_view AS
SELECT
    x || y AS something
FROM
    my_table_1 t1 INNER JOIN my_table_2 t2 ON (t1.col1 = t2.col2);

SELECT
    v.something
FROM
    my_super_view v
WHERE
    v.something LIKE 'x%';

dotaz, kterým se až vlastní optimizér začne zabývat, bude:

SELECT
    v.something
FROM
    (SELECT
        x || y AS something
    FROM
        my_table_1 t1 INNER JOIN my_table_2 t2 ON (t1.col1 = t2.col2)) v
WHERE
    v.something LIKE 'x%';

A určitě si ten dotaz ještě přepíše.

Ale třeba se mýlím.

[okbob]

+/- takhle to nějak je. Navíc se provede flatening - kdy se poddotazy (pokud to lze) převádí přímo do hlavního dotazu. Optimalizuje se až výsledek.

flattening:

1. puvodni dotaz, SELECT * FROM pohled WHERE a = b
2. substituce SELECT * FROM (SELECT a, b FROM tab) x WHERE x.a = x.b
3. flattening SELECT a, b FROM tab WHERE a = b;