Praktický návod k PgSQL (diskuse)

[ovo]

SELECT MAX(polozka_0) polozka_1 FROM tabulka GROUP BY polozka_0,polozka_1 urcite se to v pgsql pise takhle? I kdyz opomenu carku mezi sloupci v sekci SELECT, tak groupovat pres sloupec, z ktereho neco pocitam je docela divne, ne?

[pavel 'goldenfish' kysilka]

diky za opravu

[Pavel Stehule]

Je tu samozrejme emacs :->, resp. sql-postgres mod. M-x sql-postgres. Jako CASE s postgresem dobre spolupracuje cesky CASE Studio 2, http://www.casestudio.com v cene pod 6000Kc. Krome psql muzete jeste pouzit pgbash, ktery neni az tak pohodlny, ale zase se pohybujete v prostredi standardniho bashe( http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html)

[Jiri Chaloupka]

na starsich verzich uvedena syntaxe funguje, nikoliv jiz na 7.3.x. Lepe psat rovnou LIMIT OFFSET ... Co se proceduralniho jazyka tyce, v PgSQL se pouziva plpgsql, ktery se od klasickeho Oracliho Pl/SQL trochu odlisuje, res. neumi vse co je mozne v Pl/SQL. Jinak obrovskou vyhodou je ze databaze *funguje* velmi podobne jako velke databaze, takze pripadny prechod z PgSQL na Oracle ci DB2 je podstatne prirozenejsi ...

[Zdik Kudrle]

No, s tim prechodem na DB2 bych si dovolil trochu polemizovat. Prave takovou vec ted totiz resim a reknu vam, nic prijemneho. I kdyz jsem priznivce spise MySQL nez PgSQL (na PG se mi nelibi cela filozofie veci - napr. ze se clovek musi prihlasovat k databazi), tak zaplatpanbu za tyhle dva softy. Protoze, pratele, vsechny velke komercni DB (a jako ze jsem jiz na par delal) vetsinou nezvladaji spousty veci, co tyhle. (tim nemyslim supr-upr transakcni zpracovani, v tom samozrejme vedou, myslim spise spousty vychytavek, ktere zprijemnuji programatorovi zivot)

[Jirka Jurek]

Tora umi pracovat s PgSQL pomoci libqsqlpsql.so pluginu z qt knihoven.

[donald]

No okrem toho, ze umi select-ovat, insert-ovat, update-ovat z tabulek a zobrazovat jednotlive objekty v databaze, tora nic jineho s PostgreSQL neumi. Tora je spis orientovana na Oracle.. a jen tak povrxne na PostgreSQL a MySQL

[Karel Zak]

Pekne, jen male postouchnuti. Ta DB se jmenuje PostgreSQL (!= PgSQL / postgres / Postgres) a stalo by za to ujednotit si mam-li na zacatku psat male ci velke pismeno. Dejte si do .vimrc: "iab PG PostgreSQL" a budete mi vystarano a muzete pouzivat jen "PG"

[theo]

Ac to neni primo o trigerech, vysel pred cca pul rokem na root.cz serial o ucetnictvi na linuxu. Ten serial neni az tak o ucetnictvi, jako o PostgreSQL.

[Jan Kubik]

"Funkce ušetří mnoho práce ... nemusite pracovat s databázi pouze na aplikační úrovni." - NAOPAK -pracovat pouze na aplikacni urovni usetri spoustu prace "Triggery.." - a modularizace reseni je fuc "Transakce..." - i u transakci je nutno zalohovat, jinak je nutno hledat nove zamestnani "Integrita dat pomocí cizích kličů" - je z duvodu modularizace reseni lepsi ralizovana aplikaci "Složené dotazy" - pro modularizaci reseni velmi slaba pomucka "Možnosti této databáse." - jsou dalekosahle ... "Databázová konsole psql " - pocet ruznych nazoru na kvalitu cehokoliv se blizi vzdy 6 miliardam "Lepší system práv, přístupů a zabezpečení." - pristupy a prava se resi zasadne v aplikaci "Cena za databási ..." - ???? "Stabilita." ... viz obsahla dokumentace k MySQL - pojednani o stabilite "Řekl bych i lepší dokumentace oproti MySQL..." - NAOPAK - ta nejvetsi vyhoda MySQL je bohata dokumentace - viz plne regaly v knihkupectvi To samozrejme neznamena, ze Postgresql je spatne software, nebo ze MySQL je super.

[pavel 'goldenfish' kysilka]

trochu jsem nepochopil o co vam, jde.mozna by neskodilo dopsat vetu, ze se mnou v par vecech nesouhlasite. ale dobre budu vam oponovat.
1)osobne zastavam nazor, ze resit veci na aplikacni urovni neni vzdy jaksi to prave orechove. ale zalezi to skutecne na programatorovi. me osobne vyhovuje vice reseni, kdy to, co jde delam pres v databasi.samozrejme ne za kazdou cenu.
pokud mate neco portovat na jiny programovaci jazyk, tak muzete prepisovat celou aplikacni vrstvu.
2)prava a pristupy- v clanku mam na mysli prava a pristupy k databasovym strukturam a objektum. a vcelku by me zajimalo, zda je mozne se na mysql nejak kryptovane pripojit? ted nemyslim pres ssh tunel.
3) stabilita - zatim jsem neslysel o tom, ze by nekomu sletela database na postgressu. o mysql ano.
i kdyz kazdy ma nejake zkusenosti s nejakou databasi a nerikam, ze postgress sletet nemuze.
4) dokumentace - mam na mysli dokumentaci na internetu, co se tyce postgreee a dokumentace typu man ( ktera neni mezi uzivateli prilis v oblibe).beru to, ze v mysql dela dost lidi diky jeji jednoduchosti, ale daji se na mysql delat potom umerne slozite ci jednoduche veci. ne vzdy sebou nosim knihu. a pokud u sebe nemam knihu, staci napsat na konsoli man neco a je to. a urcite je to rychlejsi nez zacit listovat v knizce.
5) cena za databasi. vemte si MSSQL co umi a co umi PgSQL.pomer cena ku moznosti je podle me vcelku dost dobry.a pokud si dam na projekt nejakou databasi, budu premyslet o tom, jak muzu casem vyuzit jeji moznosti vzhledem k projektu. a u mysql mi to nevychazi dobre. zde v par prikladech muzu pockat, az vyvojari MySQL doprogramuji par vlastnosti a bude to poradne otestovano.

[Jan Kubik]

cilem meho prispevku bylo poukazat na to, ze podle bodu, ktere jste uvedl neni duvod menit databazi. Samozrejme pouze v tech pripadech, kdy je reseni provedeno na aplikacni urovni. Existuje rada priznivcu Vami preferovaneho pristupu, argumenty pro a proti jsou na internetu k vyhledani a nechci je zde opakovat. Navrhuji spolecne pripraveny clanek, ktery pojednava o teto problematice. Ukaze-li se , ze aplikacni pristup reseni je vyhodnejsi, pak neplati argumenty ve vasem clanku, ktere se poji k teto problematice a zmena databaze neni nutna. Pristupova prava.) Mam na mysli rizeni pristupu k nejake tabulce, sloupci. tedy napr. uzivatel XYZ nesmi mazat v tabulce ZAKAZNIK apod. Jestlize mluvime o tom samem, tak pak opakuji, jestlize se pro takove veci vyuziva funktionality database, tak se jedna jednoznacne o chybny navrh. A proto je nesmyslne prechazet kvuli necemu, co neni potreba z jedne databaze na druhou. Stabilita.) Zde jsme partne stejneho mineni. Mohu doplnit, ze jsem mel tu cest pracovat v projektech snad se vsemi beznymi databazemi a zatim padaly vsechny. Jiste tedy zadny argument, ke zmene databaze. Dokumentace) Musim priznat, ze o tomto bode je mozno u piva prima diskutovat. A vsadim se, ze vam nekdo rozbije pullitr o hlavu, kdyz reknete neco spatneho o phpAdmin pro MySQL. Tento bod radeji vynechame. Ze by nekdo musel pryc od MySQL, kvuli spatne dokumentaci si nedovedu predstavit. Cena) Puvodne jsem chtel k te cene napsat vetu meho znameho - je nakupci a casto klade tu znamou filozofickou otazku "co stoji auto?". Chtel jsem tim naznacit, ze takove otazky jsou velmi komplikovane, jestlize nezname v konkretnim pripade blizsi okolnosti. Abych se ale nevyhybal odpovedi: MSSQL nas nezajima, neb bezi na jedine platforme a to jeste na takove ne prave orechove . Zbyva jako priklad komercni databaze Oracle ve srovnani s Postgresql. U velke zakazky za 150 tEU je podil Oracle ca. 15 tEU - 10%. Vedeni rozhodne pro Oracle. Nemusite tedy prejit z MySQL na Postgresql, protoze velkou zakazku stejne nedostanete. U male zakazky za 15 tEU nemuzete samozrejme prijit s Oracle, zde je mozno nabidnout Postgresql nebo MySQL. Protoze se jedna o jednodussi aplikaci , vystacite s MySQL - neni li dokonce lepsi. Opet neni treba menit databazi. Tot vse a pekny zbytek weekendu

[theo]

ad pristupova prava: prectete si sql standard, neco o zabezpeceni dat a (znovu?) neco navrhu databazi.

[Jan Kubik]

kdo si ma precist ten standard - kubik nebo kysilka? A proc?

[theo]

jednoznacne kubik. proc? no kdyz nekdo chce neco kazat, pak by bylo dobre, aby o tematu taky neco vedel. nejsem databazovy expert a dokonce ani zadny veliky vyvojar, ale tolik toho o databazich vim, ze si dovoluji mit nazor, ze kazete bludy. je mi lito. nechci napadat vasi osobu, ale to co tvrdite (tj. vase myslenky) je prinejmensim uhozene. ps: nerad flamuju, tim min o tak stupidnim tematu jako je PostgreSQL verzus MySQL.

[Jan Kubik]

halo brnaku .. vubec - i kdyz to tak nevypada, mi nejde o flame. Poukazuji na diskuzi z 11.10.2002 na cz.comp.database.misc - tak jsem tuto problematiku nadhodil - s vysledkem, ze zkuseni kolegove potvrdili, ze pristupova prava se resi v aplikacni vrstve. Samozrejme jsou proto jeste jine duvody, nez ze par lidi v nejake konferenci reklo... Ale jak jsem napsal jiz kolegovi Kysilkovi, je na case sepsat kriticky clanek k SQL. Abychom zde netlachali zadarmo.

[theo]

takze to neni z vasi hlavy? tak to jsem klidny. zeptam se jinak: jaky vyzam maji pristupova prava v aplikacni urovni? imho a afaik jsou v databazich pristupova prava k tomu, aby ridila pristup uzivatelu k databazi tj. kdo kam muze zapisovat, kdo muze co cist etc... jestlize jsou pristupova prava resena nejakym proprietalnim zpusobem na aplikacni urovni, je veskera bezpecnost dat v hajicku dubovem, protoze kterekoliv hovado ovladajici sql a rekneme komandlajnu (kdyz bude stejne jako ja dostatecne zdechly stahovat si nejake graficke udeladla :) muze delat v databazi curbes. mimoto -- i ta stup... pardon mysql ma tenhle system (byt imho implementovany nemozne, ale ma). rizeni pristupovych prav na aplikacni urovni si muzete dovolit u proprietalnich databazi, ale ani tam to neni idealni. klasicke sql servery (tim minim Oracle, Ingres, PostgreSQL, dokonce i MySQL a mnohe dalsi) maji zakladni zabezpeceni dat resene na urovni databaze jako acl. jinak s argumentem, ze bezpecnost na aplikacni urovni je database-independent sice souhlasim, ale ruku na srdce -- kdyz zacnu vyvijet nejaky system postaveney na databazi, pak obvykle nejdrive zvolim databazi a nasledne zacnu neco delat. opacny postup je naprosto sileny, ne-li primo idiotsky. v momente kdy mam databazi, ktera uz sama resi bezpecnost nativne (ale musi ji resit kvalitne), je jakekoliv psani dalsi bezpecnostni vrstvy jednak vynalezanim kola a druhak zpomalovanim celeho vysledneho systemu (dalsi kontroly prav navic, ktere se navic budou zrejme kontrolovat proti nejake databazi :). takze asi tak btw: ja v brne jenom studuju, ale on ten hantec je takovy paradne nakazlivy :) no vypada to, ze zacinam psat pojednani o databazich na pokracovani

[pavel 'goldenfish' kysilka]

zdravim,
urcite se pridam jeste do flame asi zitra nad ranem. ted jsem grogy.zase se to programoavani zvrtlo.
jinak ale musim uznat, ze tato diskuse bude patrne stat za to.ted mysleno v dobrem.
zatim goldenfish

[pavel 'goldenfish' kysilka]

dobre ranko,
pokusim se nejak kratce odpovedet.
1) zmena database - zalezi to na svobodny volbe kazdyho. nekdy je mysql vyhovujici a jsou mista, kam bych pgsql nedal, ani kdyby mi platili. ja nechci sirit pgsql jako nabozenstvi a menit za kazdou cenu vsechny database na mysql. to fakt ne.
2) prava v databasi+reseni pres aplikacni vrstvu. a podobne.
celkove co jde resim v databasi.ne na ukor rychlosti a znacne slozitosti.jednoduche pocty. pokud pracujete pouze s databasi je to rychlejsi. pokud do toho jeste pridate aplikaci mate jednu vrstu navic. a taky se zvysuje moznost chyb.
dalsi duvod pro me je zmena progeramovaciho jazyka aplikace a moznost prenosu na jine projekty.muzete pouzivate to co vytvorili kolegove a nemusite kvuli tomu prepisovat do jineho jazyka celou aplikacni vrstvu.to je podle me hlavni myslenka.database vam zustava stejna, ale muzete menit programovaci jazyk.
3)clanek - mozna v kvetnu budu mit cas.bez zaruky. ted neco pisu a vcelku by to mohla byt bomba. co, to neprozradim. ale nejsem proti tomu kdyz neco vyjde. pripadne se mi pripomente v kvetnu na goldenfish256@centrum.cz .diky.
4) celkove zaverem - pgsql me vcelku dost chytlo. hlavne pro to co umi a pro moznosti. nejhorsi je na jakemkoli jazyku ci treba databasi, kdyz zjistite, ze uz nejsou nove veci a nemuzete dal. pak uz prejit na neco jineho. jako ja snad pristi mesic na neco objektoveho.a prave kdyz jsem cetl manualy k pgsql, tak jsem se nestacil divit a bude mi to trvt pekne dlouho nez do hlavy dostanu alespon zlomek toho, co pgsql umi.
jinak dobra flame, ale je na case ji utnout a rozpoutat dalsi treba az pri nejakem dalsim clanku.zatim goldenfish

[Abraxis]

"Triggery - a modularizace reseni je fuc" - jak jinak chces delat audity a podobne veci? Bez toho se to delat DOST blbe... "Transakce - i u transakci je nutno zalohovat, jinak je nutno hledat nove zamestnani" - transakce NEJSOU v ZADNEM pripade kvuli zalohovani. To by mel vedet kazdy, kdo ma za sebou aspon jeden semestr z databazi "Integrita dat pomocí cizích kličů - je z duvodu modularizace reseni lepsi ralizovana aplikaci" - a to je presne ten duvod, proc tady cizi klice jsou, protoze v aplikaci (cim vetsi tim casteji) se velmi casto zapomenes a prusvih je na svete (a kdo to ma ladit )) "Složené dotazy - pro modularizaci reseni velmi slaba pomucka" - to, ze MySQL neumi vnorene dotazy, to mu doposud nejsem schopen zapomenout

[PaJaSoft]

Tak to chci videt, jak se da udrzet datova/referencni integrita na aplikacni urovni, kdyz aplikace nema zadnou moznost zajistit, ze s databazi bude pracovat jen ona a ze nikdo jiny nezmrvi data... Kdyz pomoci DML databazi sdelite, co a jak ma byt, tak proste nemate sanci ty data zmrsit, pokud si je nezmrsi datastor sam a pak je treba jej vyhodit...

A jeste jedna vec, kdyz uz budu predpokladat, ze k databazi pristupuje jen ma aplikace, tak zrejme jste toho napsal opravdu velmi malo, protoze velmi casto se stane, ze operaci nelze zapsat atomicky - ano narazim spise na transakce - a kdyz v teto neatomicke operaci z duvodu, ktere naprosto nemuzete ovlivnit ta operace neni korektne dokoncena, tak mate po integrite a jiz nemate sanci zjistit, co jste pomoci sve kvalitni aplikace podelal...

[Jan Kubik]

halo pane inzenyre, uz vam asi pres rok dluzim odpoved, proc je SQL srot. No snad se k tomu dostaneme s "goldenfishem" v tom spolecnem clanku. Uvitam samozrejme konstruktivni kritiku a jiz se tesim na mnohe argumenty. Jinak co se tyce toho samostatneho pristupu aplikace k databazi, tak je to skutecne tak, ze veskere objekty databaze patri jedinemu uzivateli a toho zna pouze aplikace. Zadni jini uzivatele vubec neexistuji a proto take nemohou nic zkazit. Transakce jako takove nekritizuji a vsude tam kde je to potreba se pouziji. Zaverem jeste k te aplikacni vrstve. Dnes jeste natrefime obcas aplikace, kde se nalezaji stovky ci tisice SQL-statements, ktere programatori skutecne napsali od ruky. A kdyz se neco zmeni, tak jdou do toho kodu a meni ty SQL statements a trigerry atd. Takovou aplikaci samozrejme nemam na mysli a nedovedu si ani predstavit, ze by se dnes na univerzitach jeste tohle prednaselo. - no, tak jisty si vlastne nejsem, kdyz tak ctu ty blahovosti napr. pana Hofmana, ze se firma rozhodne pro nejakou databazi a eventuelne jeste pouzije ty proprieterni skopiciny te ktere databaze.

[Aristo]

hmm, som podobný prišelec z MySQL a práve riešim problém s autoicrementom (len viac úrovňovým). Ten príklad vyššie je fajn avšak ako spraviť: id, id_vazba tak aby po zadaní akejkoľvek hodnoty do ID, bola id_vazba incrementované o 1 len v rámci tejto hodnoty (groupy ID)?????

Príklad: Tabulka s poliami ID a ID_VAZBA. ID_VAZBA je AUTOINCREMENT. na obe polia je UNIQE INDEX.

po pridaní položiek s ID - 1, 1, 1, 2, 1, 2, 1, 3 je:

- výsledok v MySQL 1;1 1;2 1;3 2;1 1;4 2;2 1;5 3;1

- no v PgSQL 1;1 1;2 1;3 2;4 1;5 2;6 1;7 3;8

Ako sa dá tento problém vyriešiť v PqSQL?????

[michal00]

žeby before trigger ktorý volá inú sequence podľa typu/group ?

[Peša]

Můžu se zptat jestli se někdy někomu podařilo rozběhat PgSQL na windows Vista??? A jestli jo tak jestli by mi mohl prozradit jak. :)) Diky

[Ivan]

Jednou se mi to podařilo, ale po odinstalování už mi to znova nainstolovat nejde. Možná že to požaduje neaktualizovaný windows.