From mlebeda na centrum.cz Wed Oct 3 07:58:45 2001 From: mlebeda na centrum.cz (Martin Lebeda) Date: Wed, 3 Oct 2001 07:58:45 +0200 Subject: spousteni Oracle ias 9i Message-ID: <1175654447.20011003075845@centrum.cz> Ahoj, mohl by mi někdo poradit jak spustit %subj% automaticky po startu, on totiž musí běžet z X session. Nevím přesně proč, ale je to tak. Takže to funguje takto: naběhne linux (RH62) a normálně z rc.local scriptu spustím databázi. Až sem to je ok. Pak se přihlásím (skrze xdm - runlevel 5, automaticky mi naběhnou X) jako uživatel oracle a ručně spustím OiAS, mám na to dávku. Pokud se OiAS spustí dříve než X, nebo se nespustí z X session, skončí pokus o tisk z Forms serveru s Oracle toolkit error. Jak spuštění OiAS automatizovat? Máte někdo zkušenosti s provozem OiAS na Linuxu? díky za rady Martin From sherry na pikebo.cz Wed Oct 3 09:17:44 2001 From: sherry na pikebo.cz (Jan Serak) Date: Wed, 03 Oct 2001 09:17:44 +0200 Subject: spousteni Oracle ias 9i References: <1175654447.20011003075845@centrum.cz> Message-ID: <3BBABB98.40DC318B@pikebo.cz> Martin Lebeda wrote: > > Ahoj, > > mohl by mi někdo poradit jak spustit %subj% automaticky po startu, on > totiž musí běžet z X session. Nevím přesně proč, ale je to tak. Takže > to funguje takto: naběhne linux (RH62) a normálně z rc.local scriptu > spustím databázi. Až sem to je ok. Pak se přihlásím (skrze xdm - > runlevel 5, automaticky mi naběhnou X) jako uživatel oracle a ručně > spustím OiAS, mám na to dávku. Pokud se OiAS spustí dříve než X, nebo > se nespustí z X session, skončí pokus o tisk z Forms serveru s Oracle > toolkit error. Podle mych informaci si potrebuje Forms server (i Report server) hned pri spusteni nacucnout odnekud fonty. Nejsem odbornik na X, abych dokazal posoudit, zda neexistuje lepsi cesta, nez pouzite ziskani fontu z Xserveru. U jednoho naseho zakaznika jsme museli automaticke spusteni aplikacniho serveru pri spusteni vzdat. Pouzivaji totiz HP server bez graficke karty a pro uspesne nahozeni iAS musi jet jedno specialni(!) PC s windowsovou(!!!) implementaci X Window (nastesti se nechali presvedcit a daji tam Linux). I tak je to vachrlate a pousteji to radeji rucne. Ale velmi bude zalezet, v jakem prostredi to chcete provozovat. Na produkcnim serveru je IMHO mensi zlo rucne startovat iAS nez x uzivatelu v prubehu prace urvat jen proto, ze se automaticky nastartovany iAS pustil bez Xu. Jan Serak From yeti na seznam.cz Wed Oct 3 10:28:57 2001 From: yeti na seznam.cz (mlekar dan) Date: Wed, 3 Oct 2001 10:28:57 +0200 Subject: spousteni Oracle ias 9i In-Reply-To: <3BBABB98.40DC318B@pikebo.cz> References: <1175654447.20011003075845@centrum.cz> <3BBABB98.40DC318B@pikebo.cz> Message-ID: <01100310285700.00499@yeti> > Podle mych informaci si potrebuje Forms server (i Report server) hned > pri spusteni nacucnout odnekud fonty. Nejsem odbornik na X, abych > dokazal > posoudit, zda neexistuje lepsi cesta, nez pouzite ziskani fontu z > Xserveru. co treba spusteni xfs (font serveru) behem startu... From sherry na pikebo.cz Wed Oct 3 10:42:49 2001 From: sherry na pikebo.cz (Jan Serak) Date: Wed, 03 Oct 2001 10:42:49 +0200 Subject: spousteni Oracle ias 9i References: <1175654447.20011003075845@centrum.cz> <3BBABB98.40DC318B@pikebo.cz> <01100310285700.00499@yeti> Message-ID: <3BBACF89.36D13056@pikebo.cz> mlekar dan wrote: > > > Podle mych informaci si potrebuje Forms server (i Report server) hned > > pri spusteni nacucnout odnekud fonty. Nejsem odbornik na X, abych > > dokazal > > posoudit, zda neexistuje lepsi cesta, nez pouzite ziskani fontu z > > Xserveru. > > co treba spusteni xfs (font serveru) behem startu... Vypada to na prvni poslech jako dobra cesta, ale iAS o font serveru nic nevi a vedet nechce. Chce mit nastavenu promennou prostredi DISPLAY, aby se spojil s nejakym Xserverem (XtAppInitialize? - podrob- nosti fakt ode mne nechtejte) a teprve potom se snazi ziskat dostupne fonty. Jestli by to slo primo z xfs bez konektu na Xserver, to fakt nevim. Je to spis otazka na Oracle. 9iAS to dela tak, jak to dela, s tim asi nehneme :-( Jan Serak From stano-cznews na meduna.org Wed Oct 3 19:22:33 2001 From: stano-cznews na meduna.org (Stanislav Meduna) Date: Wed, 3 Oct 2001 17:22:33 +0000 (UTC) Subject: spousteni Oracle ias 9i References: <1175654447.20011003075845@centrum.cz> <3BBACF89.36D13056@pikebo.cz> Message-ID: <9pfhgp$2hp$1@meduna.org> On Wed, 3 Oct 2001 08:42:37 +0000 (UTC), Jan Serak wrote: : Vypada to na prvni poslech jako dobra cesta, ale iAS o font serveru : nic nevi a vedet nechce. Chce mit nastavenu promennou prostredi : DISPLAY, aby se spojil s nejakym Xserverem (XtAppInitialize? - podrob- : nosti fakt ode mne nechtejte) a teprve potom se snazi ziskat dostupne : fonty. Xvfb by nepomohol? To je X server s "obrazovkou" v pamati a na podobne problemy sme ho vo firme pouzivali. Zdravi -- Stano From koala na fi.muni.cz Thu Oct 4 10:23:44 2001 From: koala na fi.muni.cz (Ondrej Koala Vacha) Date: Thu, 4 Oct 2001 10:23:44 +0200 (CEST) Subject: jeden select? In-Reply-To: <9pfhgp$2hp$1@meduna.org> Message-ID: Dobrý den, mam následující dotaz. Mám doklady, které jsou v dvojici tabulek - hlavičky a řádky: create table doklady_hlavicky ( id int(5), id_adresy int(5) # -> adresy.id ); create table doklady_radky ( id_doklady_hlavicky int(5), id_veci int(5), # -> veci.id mnozstvi int(5) ); a tabulky s adresami a věcmi: create table adresy (id int(5), nazev char(10)); create table veci (id int(5), nazev char(10)); Zjistit, jaké množství patří k jaké adrese je téměř trivální: select sum(doklady_radky.mnozstvi) from adresy,veci,doklady_hlavicky,doklady_radky where doklady_hlavicky.id = doklady_radky.id_doklady_hlavicky and doklady_hlavicky.id_adresy = adresy.id and doklady_radky.id_veci = veci.id group by adresy.id,veci.id A teď dotaz: kdybych měl ještě jednu dvojici tabulek dokladů, je možno tento dotaz udělat opět jedním selectem? Zkoušel jsem to, ale nepodařilo se mi ani dosáhnout funkčnosti, o rychlosti ani nemluvě. Samozřejmě se dá udělat pro každou tabulku dokladů jeden select, výsledky někam schovat a nakonec zobrazit. s pozdravem -- Ondrej Koala Vacha From zakkr na zf.jcu.cz Thu Oct 4 11:23:17 2001 From: zakkr na zf.jcu.cz (Karel Zak) Date: Thu, 4 Oct 2001 11:23:17 +0200 Subject: jeden select? In-Reply-To: ; from koala@fi.muni.cz on Thu, Oct 04, 2001 at 10:23:44AM +0200 References: <9pfhgp$2hp$1@meduna.org> Message-ID: <20011004112317.A22302@zf.jcu.cz> On Thu, Oct 04, 2001 at 10:23:44AM +0200, Ondrej Koala Vacha wrote: > > Dobrý den, > > mam následující dotaz. > Mám doklady, které jsou v dvojici tabulek - hlavičky a řádky: > create table doklady_hlavicky ( > id int(5), > id_adresy int(5) # -> adresy.id > ); > create table doklady_radky ( > id_doklady_hlavicky int(5), > id_veci int(5), # -> veci.id > mnozstvi int(5) > ); > > a tabulky s adresami a věcmi: > create table adresy (id int(5), nazev char(10)); > create table veci (id int(5), nazev char(10)); > > Zjistit, jaké množství patří k jaké adrese je téměř trivální: > > select sum(doklady_radky.mnozstvi) > from adresy,veci,doklady_hlavicky,doklady_radky > where > doklady_hlavicky.id = doklady_radky.id_doklady_hlavicky > and doklady_hlavicky.id_adresy = adresy.id > and doklady_radky.id_veci = veci.id > group by adresy.id,veci.id > > > A teď dotaz: kdybych měl ještě jednu dvojici tabulek dokladů, > je možno tento dotaz udělat opět jedním selectem? Zkoušel jsem to, > ale nepodařilo se mi ani dosáhnout funkčnosti, o rychlosti ani nemluvě. Napada mne union, ale ten asi MySQL nema (tise prepokladam, ze je jedna o MySQL:-) IMHO by bylo zajimavejsi zamyslet se nad tim, chci-li opravdu dve tabulky, bez nejakeho vzajemneho vztahu a pritom s nima pracovat najednou. > Samozřejmě se dá udělat pro každou tabulku dokladů jeden select, > výsledky někam schovat a nakonec zobrazit. Ano, dva selecty do jedne tabulky a treti na poslani na klienta. Karel -- Karel Zak http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz From koala na fi.muni.cz Thu Oct 4 12:18:37 2001 From: koala na fi.muni.cz (Ondrej Koala Vacha) Date: Thu, 4 Oct 2001 12:18:37 +0200 (CEST) Subject: jeden select? In-Reply-To: <20011004112317.A22302@zf.jcu.cz> Message-ID: On Thu, 4 Oct 2001, Karel Zak wrote: > Napada mne union, ale ten asi MySQL nema (tise prepokladam, ze je jedna > o MySQL:-) Nikoli nutně, zajímá mě, jestli to vůbec je řešitelné na úrovni prostého dotazu podobně jako jedna dvojice tabulek, nebo je nutno vytáhnout něco složitějšího. Union jsem nepoužil ještě ani v mysql, ted jsem se díval a řekl bych, že se liší od unionu jinde, i když i union ala mysql by byl řešení tohoto problému. > > IMHO by bylo zajimavejsi zamyslet se nad tim, chci-li opravdu dve tabulky, > bez nejakeho vzajemneho vztahu a pritom s nima pracovat najednou. > Ano, i to je zajímavé :). Ale mě pro ted stačí prosté zjištění, že jsem se nepřehlédl, a že tato úloha pro počet=1 má řešení jednoduché, >1 složité. -- Ondrej Koala Vacha From zakkr na zf.jcu.cz Thu Oct 4 12:47:50 2001 From: zakkr na zf.jcu.cz (Karel Zak) Date: Thu, 4 Oct 2001 12:47:50 +0200 Subject: jeden select? In-Reply-To: ; from koala@fi.muni.cz on Thu, Oct 04, 2001 at 12:18:37PM +0200 References: <20011004112317.A22302@zf.jcu.cz> Message-ID: <20011004124750.C22302@zf.jcu.cz> On Thu, Oct 04, 2001 at 12:18:37PM +0200, Ondrej Koala Vacha wrote: > On Thu, 4 Oct 2001, Karel Zak wrote: > > > Napada mne union, ale ten asi MySQL nema (tise prepokladam, ze je jedna > > o MySQL:-) > > Nikoli nutně, zajímá mě, jestli to vůbec je řešitelné na úrovni prostého > dotazu podobně jako jedna dvojice tabulek, nebo je nutno vytáhnout něco > složitějšího. Union jsem nepoužil ještě ani v mysql, ted jsem se díval a > řekl bych, že se liší od unionu jinde, i když i union ala mysql by byl > řešení tohoto problému. Ted koukam na manual 4.0.0 a rekl bych ze je to stejne jako u ostatnich SQL, jen tam neni moznost INTERSECT a EXCEPT. Myslim, ze vam by to ale mohlo stacit. Otazkou je rychlost :-) -- Karel Zak http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz From Ales.Zika na pel.br.ds.mfcr.cz Mon Oct 8 07:29:01 2001 From: Ales.Zika na pel.br.ds.mfcr.cz (=?iso-8859-2?Q?=22Z=EDka_Ale=B9=2C_Ing=2E=22?=) Date: Mon, 8 Oct 2001 07:29:01 +0200 Subject: Cestina v psql pod Cygwin Message-ID: <30A3D33A0D99D4119CDD0060084676F61D2B64@fupelnt2.pel.br.ds.mfcr.cz> Mam na PC s W2k nainstalovan Cygwin s PostreSQL 7.1.3 a psql mi odmita zobrazovat cestinu a misto diakrtiriky mi vraci kody znaku ve spicatych zavorkach, pritom na vstupu ji zpracovava bez protestu. Kdyz napr. INSERTnu do tabulky jmeno 'Jiri' (s hacekm a carkou nad ri), tak SELECT vrati 'Ji'. V man strance jsem k tomu nic nenasel. Co s tim? Diky, Ales Zika Pelhrimov e-mail: Ales.Zika na pel.br.ds.mfcr.cz Ales.Zika na seznam.cz SMS: Ales.Zika na sms.underground.cz From kubis na vosji.cz Mon Oct 8 06:44:43 2001 From: kubis na vosji.cz (Tomáš Kubiš) Date: Mon, 8 Oct 2001 06:44:43 +0200 Subject: Spravny datab.navrh Message-ID: <9pravd$te1$1@mspool.euroweb.cz> Ahoj, resim nasledujici problem. Mam dve tabulky: tabulka profesor a tabulka ostatni. profesor ostatni ------- id - integer id - integer jmeno jmeno ... ...... ... ...... A pak mam tabulku temata temata ------ cislo - integere oponent ------ a tady je kamen urazu, jak mam spravne navrhnout tuto tabulku? Potrebuji aby fungovala ref.integrita mezi timto polickem a policky ostastni(id) a profesor(id). Jiz vim, ze takto jednoduse to nejde, nesetkal jste se nekdo s necim podobnym? Dekuji za kazdou radu. Tomas Kubis. From ludek.rasek na centrum.cz Mon Oct 8 08:30:54 2001 From: ludek.rasek na centrum.cz (Ludek Rasek) Date: Mon, 8 Oct 2001 08:30:54 +0200 Subject: Spravny datab.navrh In-Reply-To: <9pravd$te1$1@mspool.euroweb.cz>; from kubis@vosji.cz on Mon, Oct 08, 2001 at 06:44:43AM +0200 References: <9pravd$te1$1@mspool.euroweb.cz> Message-ID: <20011008083054.A979@p38rasek.cbu.pvt.cz> On Mon, Oct 08, 2001 at 06:44:43AM +0200, Tomáš Kubiš wrote: > Ahoj, > resim nasledujici problem. Mam dve tabulky: > tabulka profesor a tabulka ostatni. > > profesor ostatni > ------- > id - integer id - integer > jmeno jmeno > ... ...... > ... ...... > A pak mam tabulku temata > > temata > ------ > cislo - integere > oponent ------ a tady je kamen urazu, jak mam spravne navrhnout tuto > tabulku? Potrebuji aby fungovala ref.integrita mezi timto polickem a > policky > ostastni(id) a profesor(id). Jiz vim, ze takto jednoduse to nejde, > nesetkal > jste se nekdo s necim podobnym? Jak profesori, tak ostatni jsou lide (vetsinou), a tak resenim asi bude udelat tabulku napr. lide, kam spadnou vsichni (ziskate tak navic kontrolu jednoznacnosti klice pres vsechny lidi). Profesori pak mohou byt identifikovani hodnotou jednoho z atributu. Pokud maji nejaky jine udaje nez ostatni lide, vyplati se udelat pro profesory podrizenoy detailni tabulku. V postgresu by asi sla na tenhle problem vyuzit objektovost - konkretne dedicnost. V tabulce temat pak muzete pouzit beznou referencni integritu. Ludek Rasek From vladimir.naprstek na scplyn.cz Mon Oct 8 09:51:39 2001 From: vladimir.naprstek na scplyn.cz (=?ISO-8859-1?B?VmxhZGlt7XIgTuFwcnN0ZWs=?=) Date: Mon, 08 Oct 2001 08:51:39 +0100 Subject: Spravny datab.navrh Message-ID: Zdravím, a co zkusit udelat misto dvou tabulek jednu, s tím, že přidáte ještě atribut, který budě říkat, zda se jedná o profesora či nikoliv. Pak si můžete udělat dva pohledy - pro profesory a pro ostatní. Výhodou pak bude, že získáte jednu řadu identifikátorů a hlavně se v referenční integritě odkazujete na jednu tabulku. A ve výsledku máte o jednu tabulku méně. Nebo je nějaký důvod mít profesory a ostatní ve zvláštních tabulkách? Pokud ano, asi Vám nezbude, než na referenční integritu zapomenout a vztahy si hlídat v aplikaci. P.S. pokud Vaše databáze umí udělat vazbu na pohled, pak z profesorů a ostatních udělejte pohled a referujte do tohoto pohledu. Ale dost pochybuji, že to db bude umět... -------------------------------------------------------------------------------------------- Ing. Vladimír Náprstek, mail-to:vladimir.naprstek na scplyn.cz From info na ppservis.com Mon Oct 8 10:36:04 2001 From: info na ppservis.com (pp) Date: Mon, 8 Oct 2001 10:36:04 +0200 Subject: mySQL a regulární výrazy Message-ID: <9proga$454$1@morticia.kit.vslib.cz> Dotaz : Umí MySQL regulární výrazy ? pp --- Odchozí zpráva neobsahuje viry. Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz). Verze: 6.0.282 / Virová báze: 150 - datum vydání: 25.9.2001 From horak na sit.plzen-city.cz Mon Oct 8 11:13:37 2001 From: horak na sit.plzen-city.cz (=?iso-8859-2?Q?Hor=E1k_Daniel?=) Date: Mon, 8 Oct 2001 11:13:37 +0200 Subject: Cestina v psql pod Cygwin Message-ID: > Mam na PC s W2k nainstalovan Cygwin s PostreSQL 7.1.3 a psql mi > odmita zobrazovat cestinu a misto diakrtiriky mi vraci kody znaku ve > spicatych zavorkach, pritom na vstupu ji zpracovava bez > protestu. Kdyz napr. > INSERTnu do tabulky jmeno 'Jiri' (s hacekm a carkou nad ri), > tak SELECT > vrati 'Ji'. V man strance jsem k tomu nic nenasel. Duvodem podle mne je, ze v Cygwin nejsou implementovany locales. Dan From vladimir.naprstek na scplyn.cz Mon Oct 8 12:18:37 2001 From: vladimir.naprstek na scplyn.cz (=?ISO-8859-1?B?VmxhZGlt7XIgTuFwcnN0ZWs=?=) Date: Mon, 08 Oct 2001 11:18:37 +0100 Subject: =?ISO-8859-1?B?UmU6IG15U1FMIGEgcmVndWzhcm7tIHb9?= =?ISO-8859-1?B?cmF6eQ==?= Message-ID: v manualu je urcite popis funkce regexp... -------------------------------------------------------------------------------------------- Ing. Vladimír Náprstek, mail-to:vladimir.naprstek na scplyn.cz From pepa.svob na worldonline.cz Mon Oct 8 11:54:27 2001 From: pepa.svob na worldonline.cz (Josef Svoboda) Date: Mon, 8 Oct 2001 11:54:27 +0200 Subject: mySQL a regulární výrazy References: <9proga$454$1@morticia.kit.vslib.cz> Message-ID: <9prt6t$jol$1@regina.gin.cz> > Dotaz : Umí MySQL regulární výrazy ? Ano, umi je, pouziva balik Henryho Spencera. JS From mlebeda na centrum.cz Mon Oct 8 12:05:24 2001 From: mlebeda na centrum.cz (Martin Lebeda) Date: Mon, 8 Oct 2001 10:05:24 +0000 (UTC) Subject: Cestina v psql pod Cygwin References: Message-ID: horak na sit.plzen-city.cz (Horák Daniel) wrote in news:D5637E9568BDF3499B8BB02C12B4461DD44F na EXCHANGE.mmp.plzen-city.cz: >> Mam na PC s W2k nainstalovan Cygwin s PostreSQL 7.1.3 a psql mi >> odmita zobrazovat cestinu a misto diakrtiriky mi vraci kody znaku ve >> spicatych zavorkach, pritom na vstupu ji zpracovava bez >> protestu. Kdyz napr. >> INSERTnu do tabulky jmeno 'Jiri' (s hacekm a carkou nad ri), tak >> SELECT vrati 'Ji'. V man strance jsem k tomu nic nenasel. > > Duvodem podle mne je, ze v Cygwin nejsou implementovany locales. O nikoliv, ja je tam mam, cestinu mi zobrazuje jen ve 1250 (neumim zmenit), spise nebude PostreSQL zkompilovan se spravnymi parametry, ale to uz jenom hadam. Martin From dev na b2bexpander.com Mon Oct 8 21:19:10 2001 From: dev na b2bexpander.com (Jiri Chaloupka) Date: Mon, 8 Oct 2001 21:19:10 +0200 Subject: spojeni tabulek Message-ID: <01100821184900.01720@linux> Omlouvam se, je to ponekud stupidni dotaz, ale asi jsem uz pretazeny ... mam 2 tabulky, rekneme tabulku A a B, pricemz tabulka B obsahuje klic na tabulku A - sloupec A_id. Tabulka A obsahuje zaznamy id | name 1 | jmeno1 2 | jmeno 2 3 | jmeno 3 tabulka B obsahuje zaznamy id | A_id | text 1 | 1 | text1 2 | 2 | text2 a pak mam sql dotaz ve tvaru "select A.id, A.name, B.text from A, B where A.id = B.A_id" a tento dotaz mi vrati vysledek: id | name | text 1 | jmeno1 | text 1 2 | jmeno 2 | text 2 3 | jmeno 3 | text 2 nejak nechapu, ten treti radek tam preci nema byt, ale nemohu se ho zbavit ... Kde mam blbost? Dik ... From kubis na vosji.cz Tue Oct 9 07:22:07 2001 From: kubis na vosji.cz (Tomáš Kubiš) Date: Tue, 9 Oct 2001 07:22:07 +0200 Subject: Pohledy, vazby na pohled Message-ID: <9pu1hf$fl6$1@mspool.euroweb.cz> Ahoj, mate nekdo zkusenost z pohledy v PostgreSQL, staci jednoduchy prikladek. moc dík Tomáš Kubiš From roubm9am na barbora.ms.mff.cuni.cz Tue Oct 9 09:04:42 2001 From: roubm9am na barbora.ms.mff.cuni.cz (Milan Roubal) Date: Tue, 9 Oct 2001 09:04:42 +0200 Subject: Pohledy, vazby na pohled References: <9pu1hf$fl6$1@mspool.euroweb.cz> Message-ID: <01c701c15090$ab5435e0$561b71c3@krlis> create view visible_vtipy as select vtipy.text as text from vtipy where vtipy.visible='true'; Zdravi Milan Roubal ----- Original Message ----- From: "Tomáš Kubiš" To: Sent: Tuesday, October 09, 2001 7:22 AM Subject: Pohledy, vazby na pohled Ahoj, mate nekdo zkusenost z pohledy v PostgreSQL, staci jednoduchy prikladek. moc dík Tomáš Kubiš From fc282 na email.com Fri Oct 12 09:15:51 2001 From: fc282 na email.com (Cyril Franko) Date: Fri, 12 Oct 2001 09:15:51 +0200 Subject: mysql OleDB Message-ID: <004c01c152ed$bb48c600$10c03ac1@euroweb.sk> zdravim, ma niekto rozbehane MyOLEDB pre MySQL ? From lucifer na email.cz Mon Oct 15 10:41:56 2001 From: lucifer na email.cz (lucifer na email.cz) Date: Mon, 15 Oct 2001 10:41:56 +0200 (CEST) Subject: Objektovy PostgreSQL? Message-ID: <3BCAA154.000001.08170@www2.email.atc> DD. Na prvni webove strance PostgreSQL se pise, ze to je objektove - relacni DB. Mohl bych se zeptat, kde je k tomu 'objektove' nejake dalsi info? Resp. Co konkretne to znamena v provedeni pgsql? Diky, M. Bauer --- Objevte oranžový svět financí a vyhrajte v soutěži s ING! http://soutez.ing.cz From zakkr na zf.jcu.cz Mon Oct 15 11:17:46 2001 From: zakkr na zf.jcu.cz (Karel Zak) Date: Mon, 15 Oct 2001 11:17:46 +0200 Subject: Objektovy PostgreSQL? In-Reply-To: <3BCAA154.000001.08170@www2.email.atc>; from lucifer@email.cz on Mon, Oct 15, 2001 at 10:41:56AM +0200 References: <3BCAA154.000001.08170@www2.email.atc> Message-ID: <20011015111745.B19715@zf.jcu.cz> On Mon, Oct 15, 2001 at 10:41:56AM +0200, lucifer na email.cz wrote: > DD. > > Na prvni webove strance PostgreSQL se pise, ze to je objektove - relacni DB. > Mohl bych se zeptat, kde je k tomu 'objektove' nejake dalsi info? > Resp. Co konkretne to znamena v provedeni pgsql? > Otazna zni "co obecne znamena 'objektove' u databazi"? :-) Relational Databases Currently the most wide spread model, and the one which most commercial systems are based upon. Object Oriented Databases Based on the Object Oriented philosophy. It allows users to create their own objects and specify how these relate to each other. Object Relational Databases A set of new functionality added to relational systems, which allow data to be manipulated in the form of objects, as well as providing the traditional relational interface. Ciste OO DB (ODBM) nepouzivaji zadny high-level jazyk jako je SQL, ale pristupuji k DB jako k objektum a data neukladaji do radek, ale do objektu. IMHO je todle je mrtva zalezitost na urovni nejakych obecnych DB, a bude asi vice vyuzivano nejakych komponentovych technologii (Corba apod.), kde komponenty delaji API k bezne DB. Zatimco Object-Relational DBMS pouzivani SQL a umoznuji definovat vlastni metody (funkce), vlastni datove typy, triggery. Nejedna se tedy o zalezitost rozhrani (tim je stale SQL) jak by se mohlo zdat. Karel -- Karel Zak http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz From zakkr na zf.jcu.cz Mon Oct 15 11:48:30 2001 From: zakkr na zf.jcu.cz (Karel Zak) Date: Mon, 15 Oct 2001 11:48:30 +0200 Subject: C, python, perl, ...? In-Reply-To: <20011015112148.A30928@lxserver.deltes.cz>; from skim@deltaes.cz on Mon, Oct 15, 2001 at 11:21:48AM +0200 References: <3BCA7E7F.BA338B2D@tmapy.cz> <3BCA897F.6052A4F8@fonet.cz> <20011015105430.A19715@zf.jcu.cz> <20011015112148.A30928@lxserver.deltes.cz> Message-ID: <20011015114830.C19715@zf.jcu.cz> On Mon, Oct 15, 2001 at 11:21:48AM +0200, Michal Špaček wrote: > Zdravim. > > On Mon, Oct 15, 2001 at 10:54:31AM +0200, Karel Zak wrote: > > On Mon, Oct 15, 2001 at 09:00:15AM +0200, Ing. Pavel PaJaSoft Janousek wrote: > > > > je na tento pripad vhodnejsi? Napr. v C se mi zda neefektivni podpora > > > > databazi, jini rikaji, ze python je lepsi nez perl, ... > > > Perl ma DBI, Python mozna ma rovnez neco, PHP ma kulovy, a C/C++ > > ODBC (ma ho i PHP, coz neznamena, ze bych zrovna tento jazyk > > doporucoval...) Neni duvod proc o tomto debatovat privatne (dovolil jsem si CC do konference). Je mozne, ze mne nekdo opravi. Please, bez flame a vecne! > Chtel jsem se zeptat, jestli je nejaky duvod proc PHP nedoporucovat. > Nejake duvody vim sam, ale neni toho moc :o) Mne vadi, ze to nema pointery (coz uznavam, ze je takova moje C-kova deformace :-) IMHO tento jazyk neprinesl nic noveho (a podle meho nazoru nemusel byt vubec napsan:-). Zajimava na nem byla jen moznost integrace do apache coz dnes je mozne i u Perlu nebo Pythonu a nevidim duvod proc z tohoto duvodu psat novy jazyk (stacilo napsat handler k nejakemu existujicimu jazyku). U Pythonu je dokonce moznost volat z URL primo objekty a ne jen cely soubor. Dalsi velka vyhoda byla moznost psat kod primo do web stranek. Coz je vyhoda, ktera se u vetsich projektu meni na nevyhodu a pouziva se pak ruznych systemu templates. (Zde by se urcite ozvali uzivatele Javy s moznosti integrace tohoto jazyka do web stranek). Jedna se o jazyk primo sity na miru webu. Pokud se podivate na nektere moduly Pythonu tak zjistite, ze prace s generovanim HTML muze byt i daleko lepsi. Vadi mi, ze kdyz se nekdo nauci PHP a chtel by ho pouzit i na psani ne-WWW veci tak to neni tak snadne (i kdyz jsem uz videl nekde -snad se nepletu- i rozsireni o GTK). PHP nedosahuje moznosti takove modularyty jako Perl nebo Python (u Pythonu je i velmi dobre propracovana moznost integrace jazyka do jinych programu). Obecne se moc nepouziva moznost psat modul primo v C do apache. Coz neni zase tak moc tezke a z vlastni zkusenosti vim, ze to muze byt lepsi nez pouzit PHP na vetsi projekt. Podivam-li se na Perl, Python, C/C++ (mozna i Javu) jsem schopen rict co, ktery jazyk prinesl noveho. U PHP mne nic rozumneho nenapada. (V PHP jsem napsal desitky tisic radek a stale ho pouzivam. Nekdy ze setrovacnosti jindy pro male veci. Obecne proto, ze jsem drive neumel Python a nechal se strhnout mainstream nazorem.) Karel -- Karel Zak http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz From adelton na informatics.muni.cz Mon Oct 15 11:59:00 2001 From: adelton na informatics.muni.cz (Honza Pazdziora) Date: Mon, 15 Oct 2001 11:59:00 +0200 Subject: C, python, perl, ...? In-Reply-To: <20011015114830.C19715@zf.jcu.cz>; from zakkr@zf.jcu.cz on Mon, Oct 15, 2001 at 11:48:30AM +0200 References: <3BCA7E7F.BA338B2D@tmapy.cz> <3BCA897F.6052A4F8@fonet.cz> <20011015105430.A19715@zf.jcu.cz> <20011015112148.A30928@lxserver.deltes.cz> <20011015114830.C19715@zf.jcu.cz> Message-ID: <20011015115900.S21000@anxur.fi.muni.cz> On Mon, Oct 15, 2001 at 11:48:30AM +0200, Karel Zak wrote: > > Podivam-li se na Perl, Python, C/C++ (mozna i Javu) jsem schopen > rict co, ktery jazyk prinesl noveho. U PHP mne nic rozumneho > nenapada. Ono PHP vzniklo jako jednoducha vec, u ktere se casem zjistilo, ze je potreba delat slozitejsi veci a tak se to rozrustalo. Do jiste miry funkce a moznosti out-of-box PHP rostly se schopnostmi typickeho webovskeho autora -- na zacatku databaze proste nebyly potreba, takze bylo pro uzivatele/vyvojare jednodussi vzit specializovany nastroj, nez obecny prostredek, ze ktereho by pouzili pouze cast. No a casem lidi zjistili, ze stejne potrebuji vsechno, takze se doplnovalo a rozsirovalo. Myslim, ze minimalne z hlediska popularizace nestatickeho webu PHP urcite udelalo svuj kus prace. Jinak souhlasim v podstate se vsim, co bylo receno a co jsem tudiz smazal. ;-) -- ------------------------------------------------------------------------ Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/ .project: Perl, DBI, Oracle, MySQL, auth. WWW servers, DBD::XBase. Please note that I will be off-line from Oct 5 for about a week. From Martin.Spirk na pvt.cz Mon Oct 15 12:43:31 2001 From: Martin.Spirk na pvt.cz (Martin Spirk) Date: Mon, 15 Oct 2001 12:43:31 +0200 Subject: C, python, perl, ...? In-Reply-To: <20011015114830.C19715@zf.jcu.cz> References: <3BCA7E7F.BA338B2D@tmapy.cz> <20011015112148.A30928@lxserver.deltes.cz> <20011015114830.C19715@zf.jcu.cz> Message-ID: <200110151038.MAA05373@p44u01.plz.pvt.cz> On Mon 15. October 2001 11:48, you wrote: > > Podivam-li se na Perl, Python, C/C++ (mozna i Javu) jsem schopen > rict co, ktery jazyk prinesl noveho. U PHP mne nic rozumneho > nenapada. > To by me zajimalo, zatim setrvavam u C/C++, ale kdybych musel sahnout po necem jinem (asi hlavne kvuli webu), tak jsem uvazoval o PHP (asi proto ze se o nem nejvice mluvi). Perl jsem nekde zahledl a pripadal mi dost necitelny, ale Python neznam vubec, cim je zajimavy oproti ostanim? Martin From yeti na seznam.cz Mon Oct 15 12:57:06 2001 From: yeti na seznam.cz (mlekar dan) Date: Mon, 15 Oct 2001 12:57:06 +0200 Subject: C, python, perl, ...? In-Reply-To: <20011015114830.C19715@zf.jcu.cz> References: <3BCA7E7F.BA338B2D@tmapy.cz> <20011015112148.A30928@lxserver.deltes.cz> <20011015114830.C19715@zf.jcu.cz> Message-ID: <01101512570601.00493@yeti> > videl nekde -snad se nepletu- i rozsireni o GTK). gtk.php.net Pokud nekdo hleda clanky v cestine, na builder.cz byl serial, tak pred pul rokem. O stabilite, implementaci funkci, kvalite dokumentace, etc, at si udela obrazek kazdy nejlepe vlastni zkusenosti. Jako hracka to nebylo kolem verze 0.0.4 spatne (to projekt existoval pul roku) (dnes je 0.1.1). From xvalous na pluto.pslib.cz Mon Oct 15 12:56:50 2001 From: xvalous na pluto.pslib.cz (Tomas Valousek) Date: Mon, 15 Oct 2001 12:56:50 +0200 (CEST) Subject: C, python, perl, ...? In-Reply-To: <200110151038.MAA05373@p44u01.plz.pvt.cz> Message-ID: On Mon, 15 Oct 2001, Martin Spirk wrote: > On Mon 15. October 2001 11:48, you wrote: > > > > Podivam-li se na Perl, Python, C/C++ (mozna i Javu) jsem schopen > > rict co, ktery jazyk prinesl noveho. U PHP mne nic rozumneho > > nenapada. > > > > To by me zajimalo, zatim setrvavam u C/C++, ale kdybych musel sahnout po > necem jinem (asi hlavne kvuli webu), tak jsem uvazoval o PHP (asi proto ze se > o nem nejvice mluvi). Perl jsem nekde zahledl a pripadal mi > dost necitelny, ale Python neznam vubec, cim je zajimavy oproti ostanim? PERL je podle meho nazoru nejjednodussi(syntaxi) a nejuniverzalnejsi programovaci jazyk. Jeho jednoznacnou vyhodou oproti PHP je, ze krome toho, ze se v nem dobre programuje pro web, tak se v nem dobre programuje aplikace pro temer jakekoliv jine pouziti. S pouzitim mod_perl dosahuje na webu velmi vysoke rychlosti, v nekterych oblastech je rychlejsi nez PHP, v nekterych pomalejsi, ale celkove jsou na tom co se rychlosti tyce zhruba stejne. => proc se ucit PHP, ktere ma omezene moznosti (vetsinou se da pouzit pouze na web), kdyz se muzu naucit PERL, ktery ma relativne neomezene moznosti a je zhruba stejne slozite se naucit PHP nebo PERL. -- Tomas -VALY- Valousek web design, internet projects, linux etc.. email: tomas na valousek.cz www: http://www.spsselib.hiedu.cz/~xvalous (~=ALT+126) From info na ppservis.com Mon Oct 15 12:40:56 2001 From: info na ppservis.com (pp) Date: Mon, 15 Oct 2001 12:40:56 +0200 Subject: Fulltextový index na MySQL Message-ID: <9qeee7$4gv$1@morticia.kit.vslib.cz> Zdravim, Mám vytvořen fulltextový index a záznam který tam 100% je. Bohužel při zadání Match .... Against to ten záznam nenajde. Nevíte v čem může být chyba ? to hledané slovo je 'vlažný'. slovo 'železný' to kupříkladu najde. Díky pp --- Odchozí zpráva neobsahuje viry. Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz). Verze: 6.0.286 / Virová báze: 152 - datum vydání: 9.10.2001 From skim na deltaes.cz Mon Oct 15 13:23:07 2001 From: skim na deltaes.cz (=?iso-8859-2?Q?Michal_=A9pa=E8ek?=) Date: Mon, 15 Oct 2001 13:23:07 +0200 Subject: C, python, perl, ...? In-Reply-To: <20011015114830.C19715@zf.jcu.cz>; from zakkr@zf.jcu.cz on Mon, Oct 15, 2001 at 11:48:30AM +0200 References: <3BCA7E7F.BA338B2D@tmapy.cz> <3BCA897F.6052A4F8@fonet.cz> <20011015105430.A19715@zf.jcu.cz> <20011015112148.A30928@lxserver.deltes.cz> <20011015114830.C19715@zf.jcu.cz> Message-ID: <20011015132307.A1071@lxserver.deltes.cz> On Mon, Oct 15, 2001 at 11:48:30AM +0200, Karel Zak wrote: > Neni duvod proc o tomto debatovat privatne (dovolil jsem si CC do > konference). Je mozne, ze mne nekdo opravi. Souhlasim :o)) Sice jste to postnul do jine konference, ale to je celkem jedno :o)) > Please, bez flame a vecne! oki Jeste to trosku rozsirim, protoze se mi tak trosku zda, ze o tom chybi informace. > IMHO tento jazyk neprinesl nic noveho (a podle meho nazoru nemusel > byt vubec napsan:-). Zajimava na nem byla jen moznost integrace do > apache coz dnes je mozne i u Perlu nebo Pythonu a nevidim duvod > proc z tohoto duvodu psat novy jazyk (stacilo napsat handler k > nejakemu existujicimu jazyku). U Pythonu je dokonce moznost > volat z URL primo objekty a ne jen cely soubor. Asi zacnu zkoumat python. Minimalne tam asi budou nejaka reseni navic oproti Perlu > Dalsi velka vyhoda byla moznost psat kod primo do web stranek. jasne. > Coz je vyhoda, ktera se u vetsich projektu meni na nevyhodu a > pouziva se pak ruznych systemu templates. No nevyhoda to je tehdy, kdyz zacina byt hodne kodu, ktery neni zobrazovan. K systemu templates. php - je asi nejjednodussi. k perlu je jich taky par: pee - http://pee.sourceforge.net/ - navazuje na fastcgi modul pro apache. potom jsou dalsi navazujici na mod-perl modul pro apache. viz http://perl.apache.org/#appservers Vsechny v perlu. O pythonu nevim prakticky nic a privital bych nejake informace, pokud je nekdo zna.. Hlavne ohledne vyvoje web aplikaci a templates {to povazuju za nutnost} > Jedna se o jazyk primo sity na miru webu. Pokud se podivate na > nektere moduly Pythonu tak zjistite, ze prace s generovanim HTML muze > byt i daleko lepsi. hm to by me zajimalo. > Obecne se moc nepouziva moznost psat modul primo v C do apache. Coz > neni zase tak moc tezke a z vlastni zkusenosti vim, ze to muze byt > lepsi nez pouzit PHP na vetsi projekt. Hmm to je docela zajimave reseni. Prakticky nikdo to nedela, protoze to je spousta casu oproti bastleni v perlu apod.. :o))) Mate nejaky priklad? Jinak samozrejme souhlas :o) s pozdravem skim -- --------------------------------------------------- Michal "sKim" Spacek Brno, CZ, Europe E-mail: skim na deltaes.com icq: 66962942 user: debian, TeX ------=[ #!/usr/bin/perl ]=------------------------ From skim na deltaes.cz Mon Oct 15 13:28:34 2001 From: skim na deltaes.cz (=?iso-8859-2?Q?Michal_=A9pa=E8ek?=) Date: Mon, 15 Oct 2001 13:28:34 +0200 Subject: C, python, perl, ...? In-Reply-To: ; from xvalous@pluto.pslib.cz on Mon, Oct 15, 2001 at 12:56:50PM +0200 References: <200110151038.MAA05373@p44u01.plz.pvt.cz> Message-ID: <20011015132834.B1071@lxserver.deltes.cz> On Mon, Oct 15, 2001 at 12:56:50PM +0200, Tomas Valousek wrote: > > To by me zajimalo, zatim setrvavam u C/C++, ale kdybych musel > > sahnout po necem jinem (asi hlavne kvuli webu), tak jsem uvazoval > > o PHP (asi proto ze se o nem nejvice mluvi). Perl jsem nekde > > zahledl a pripadal mi dost necitelny, ale Python neznam vubec, cim > > je zajimavy oproti ostanim? > PERL je podle meho nazoru nejjednodussi(syntaxi) a nejuniverzalnejsi > programovaci jazyk. souhlas. Ma docela velkou volnost ve stylu psani programu. > Jeho jednoznacnou vyhodou oproti PHP je, ze krome toho, ze se v nem > dobre programuje pro web, tak se v nem dobre programuje aplikace pro > temer jakekoliv jine pouziti. jasne > S pouzitim mod_perl dosahuje na webu velmi vysoke rychlosti, v > nekterych oblastech je rychlejsi nez PHP, v nekterych pomalejsi, ale > celkove jsou na tom co se rychlosti tyce zhruba stejne. No u malych aplikaci je php asi rychlejsi, protoze je trosku blize apachi nez perl. Zkousel jste nekdy mod-fastcgi? A porovnani s predchozima dvema? Myslim, ze je to dalsi moznost a porad perl. skim -- --------------------------------------------------- Michal "sKim" Spacek Brno, CZ, Europe E-mail: skim na deltaes.com icq: 66962942 user: debian, TeX ------=[ #!/usr/bin/perl ]=------------------------ From janousek na fonet.cz Mon Oct 15 13:37:40 2001 From: janousek na fonet.cz (Ing. Pavel PaJaSoft Janousek) Date: Mon, 15 Oct 2001 13:37:40 +0200 Subject: C, python, perl, ...? References: <3BCA7E7F.BA338B2D@tmapy.cz> <3BCA897F.6052A4F8@fonet.cz> <20011015105430.A19715@zf.jcu.cz> <20011015112148.A30928@lxserver.deltes.cz> <20011015114830.C19715@zf.jcu.cz> Message-ID: <3BCACA84.BC43A9CF@fonet.cz> > ruznych systemu templates. (Zde by se urcite ozvali uzivatele Javy s > moznosti integrace tohoto jazyka do web stranek). Ja se ozyvam, protoze do toho trosku delam. Ono neni jenom JSP, coby "Javovske-PHP" na strane serveru, ale take treba napr. http://www.hyperqbs.org, ktere se mi osobne libi a resi problemy, ktere coby zarputili CGIckar (v C++) musim slozite resit ve vlastni rezii. Nad javou a zejmena nad J2EE a EJB je vystaveno obrovske mnozstvi veci, ac se to nezda, takze Java na serveru neni jen o JSP. Jinak vsak souhlasim se vsim, co Karel napsal. ----------------------------------------------------------------------- Ing. Pavel Janousek (PaJaSoft) FoNet, spol. s r. o. Vyvoj software, Intranet / Internet Sokolova 67, 619 00 Brno E-mail: mailto:Janousek na FoNet.Cz Tel.: +420 5 4324 4749 SMS: mailto:P.Janousek na SMS.Paegas.Cz Fax.: +420 5 4324 4751 WWW: http://WWW.FoNet.Cz/ E-mail: mailto:Info na FoNet.Cz ----------------------------------------------------------------------- From zakkr na zf.jcu.cz Mon Oct 15 14:16:33 2001 From: zakkr na zf.jcu.cz (Karel Zak) Date: Mon, 15 Oct 2001 14:16:33 +0200 Subject: C, python, perl, ...? In-Reply-To: <20011015132307.A1071@lxserver.deltes.cz>; from skim@deltaes.cz on Mon, Oct 15, 2001 at 01:23:07PM +0200 References: <3BCA7E7F.BA338B2D@tmapy.cz> <3BCA897F.6052A4F8@fonet.cz> <20011015105430.A19715@zf.jcu.cz> <20011015112148.A30928@lxserver.deltes.cz> <20011015114830.C19715@zf.jcu.cz> <20011015132307.A1071@lxserver.deltes.cz> Message-ID: <20011015141633.G19715@zf.jcu.cz> On Mon, Oct 15, 2001 at 01:23:07PM +0200, Michal Špaček wrote: > On Mon, Oct 15, 2001 at 11:48:30AM +0200, Karel Zak wrote: > > Neni duvod proc o tomto debatovat privatne (dovolil jsem si CC do > > konference). Je mozne, ze mne nekdo opravi. > Souhlasim :o)) > Sice jste to postnul do jine konference, ale to je celkem jedno :o)) Sorry, a jeste jednou sorry za OT (i kdyz puvodne to bylo o API k DB). > > Please, bez flame a vecne! > oki > > Jeste to trosku rozsirim, protoze se mi tak trosku zda, ze o tom chybi > informace. > > > IMHO tento jazyk neprinesl nic noveho (a podle meho nazoru nemusel > > byt vubec napsan:-). Zajimava na nem byla jen moznost integrace do > > apache coz dnes je mozne i u Perlu nebo Pythonu a nevidim duvod > > proc z tohoto duvodu psat novy jazyk (stacilo napsat handler k > > nejakemu existujicimu jazyku). U Pythonu je dokonce moznost > > volat z URL primo objekty a ne jen cely soubor. > Asi zacnu zkoumat python. Minimalne tam asi budou nejaka reseni navic > oproti Perlu Ja jsem nikdy nic velkeho v Pythonu nenapsal (narozdil od PHP), asi by se nasel k Pythonu nekdo povolanejsi. Podivejte se na veci okolo projektu Zope -- coz je temer zcela web zalezitost a zcela v Pythonu. > Hlavne ohledne vyvoje web aplikaci a templates {to povazuju za > nutnost} Ohledne sablon ... doba postpoupila k XML. Myslim, ze v linux na linux.cz uz nejake ty debaty o techto resenich zazneli. Problem sablon je jak jednou nekdo (J. Kosek?) poznamenal, ze casem dojdete k nutnosti pouzivat i uvnitr sablony podminky a tim se dostanete k tomu, ze programujete vlastne nejaky "template language" :-) Pravdou je, ze nejake if/else ma jeste daleko k opravdovemu prog. jazyku. Nemyslim, ze napsat nejakou rutinu (pokud to v danem jazyku jeste nikdo neudelal) ktera vam nahradi v nejakem souboru neco-za-neco je tak moc velky problem. > > Obecne se moc nepouziva moznost psat modul primo v C do apache. Coz > > neni zase tak moc tezke a z vlastni zkusenosti vim, ze to muze byt > > lepsi nez pouzit PHP na vetsi projekt. > Hmm to je docela zajimave reseni. Prakticky nikdo to nedela, protoze > to je spousta casu oproti bastleni v perlu apod.. :o))) Ja jsem takto prepisoval nekolik tisic radek PHP do C a jsem rad ze jsem to udelal. Casove je na tom narocne jen to nez si napisete/okopirujete par zakladnich veci (mozna by bylo dobre pokud by existovala libapachemod:-). Dobrou inspiraci jsou treba zdrojaky od PHP. > Mate nejaky priklad? Mam, ale slibil jsem ze to neukazu "treti" strane :-( Nejake priklady drive psal Pavel Janik na linuxworld.cz a i samotne zdrojaky apache obsabuji example. Karel -- Karel Zak http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz From vladimir.naprstek na scplyn.cz Mon Oct 15 15:14:53 2001 From: vladimir.naprstek na scplyn.cz (=?ISO-8859-1?B?VmxhZGlt7XIgTuFwcnN0ZWs=?=) Date: Mon, 15 Oct 2001 14:14:53 +0100 Subject: Mysql a regexp Message-ID: Zdravím, potřebuji z tabulky hovorů vybírat určité záznamy podle volaného čísla. Toto volané číslo je uloženo jako bigint unsigned takto: - nemá úvodní nulu - na začátku může být mezinárodní volací znak 420 takže např. 471212121 (Ústí nad Labem) nebo 420471212121. Ateď potřebuji vybrat hovory na pevnou linku, tj. číslo může začínat 420 a pak pokračuje číslem 0-5 nebo číslicí 6, za níž nesmí pokračovat 0 (42060xxx je mobil, 42069xxx je Ostrava). napsal jsem si dotaz: SELECT .... FROM table WHERE num REGEXP '^(420)?([1-5]|6[^0])'....; jenže MySQL mi vybere i 420604xxxx (jako by prohlásil, že 420 na začátku být nemusí, tak tam prostě není, i když tam je... Poradíte mi... -------------------------------------------------------------------------------------------- Ing. Vladimír Náprstek, mail-to:vladimir.naprstek na scplyn.cz From Vaclav.Ovsik na i.cz Mon Oct 15 15:02:21 2001 From: Vaclav.Ovsik na i.cz (Vaclav Ovsik) Date: Mon, 15 Oct 2001 15:02:21 +0200 Subject: Mysql a regexp In-Reply-To: ; from vladimir.naprstek@scplyn.cz on Mon, Oct 15, 2001 at 02:14:53PM +0100 References: Message-ID: <20011015150221.P624@bobek.i.cz> On Mon, Oct 15, 2001 at 02:14:53PM +0100, Vladimír Náprstek wrote: > Zdravím, > potřebuji z tabulky hovorů vybírat určité záznamy podle volaného čísla. Toto > volané číslo je uloženo jako bigint unsigned takto: > - nemá úvodní nulu > - na začátku může být mezinárodní volací znak 420 > > takže např. 471212121 (Ústí nad Labem) nebo 420471212121. > > Ateď potřebuji vybrat hovory na pevnou linku, tj. číslo může začínat 420 a > pak pokračuje číslem 0-5 nebo číslicí 6, za níž nesmí pokračovat 0 (42060xxx > je mobil, 42069xxx je Ostrava). napsal jsem si dotaz: > > SELECT .... FROM table WHERE num REGEXP '^(420)?([1-5]|6[^0])'....; > > jenže MySQL mi vybere i 420604xxxx (jako by prohlásil, že 420 na začátku být > nemusí, tak tam prostě není, i když tam je... No to se ale chova spravne. Co na to jit obracene, tj hledat zaznamy, ktere nejsou mobil (7xx jsou asi taky mobily ne?) Neznam MySQL, ale asi tedy NOT num REGEXP '^(420)?(60|7)' PS: zajimave uplatneni regex na neznakovou vec :-) Ani by me nenapadlo, ze to tohle sezere. -- Vaclav Ovsik email: Vaclav.Ovsik na i.cz ICZ a.s. phone: +420 19 7488511 fax: +420 19 7488506 From hisaak na mrkvoslav.ascs.muni.cz Mon Oct 15 14:22:43 2001 From: hisaak na mrkvoslav.ascs.muni.cz (David =?ISO-8859-2?Q?Olszy=F1ski?=) Date: Mon, 15 Oct 2001 12:22:43 GMT Subject: C, python, perl, ...? References: <200110151038.MAA05373@p44u01.plz.pvt.cz> <20011015132834.B1071@lxserver.deltes.cz> Message-ID: Michal Špaček wrote: >> S pouzitim mod_perl dosahuje na webu velmi vysoke rychlosti, v >> nekterych oblastech je rychlejsi nez PHP, v nekterych pomalejsi, ale >> celkove jsou na tom co se rychlosti tyce zhruba stejne. > No u malych aplikaci je php asi rychlejsi, protoze je trosku blize > apachi nez perl. > Zkousel jste nekdy mod-fastcgi? A porovnani s predchozima dvema? > Myslim, ze je to dalsi moznost a porad perl. S mod_fastcgi mam velice dobre zkusenosti. Rekl bych, ze rychlosti mod_perlu to asi nedosahuje, ale za to jsou s tim mnohem mensi problemy, zvlaste pri prechodu z cgi aplikace. mod_perl jsem ale zkousel uz pred dlouhou dobou, takze se to mozna zmenilo. Je to tak? hisaak > > skim > From jirka na kosek.cz Mon Oct 15 15:11:14 2001 From: jirka na kosek.cz (Jirka Kosek) Date: Mon, 15 Oct 2001 15:11:14 +0200 Subject: C, python, perl, ...? References: <3BCA7E7F.BA338B2D@tmapy.cz> <20011015114830.C19715@zf.jcu.cz> Message-ID: <3BCAE072.56619772@kosek.cz> Karel Zak wrote: > Podivam-li se na Perl, Python, C/C++ (mozna i Javu) jsem schopen > rict co, ktery jazyk prinesl noveho. U PHP mne nic rozumneho > nenapada. Co se týče schopností samotného jazyka nenabízí PHP opravdu nic převratného, spíš mu mnoho věcí stále chybí - např. zpracování výjimek apod. PHP však bylo původně navrženo jako jazyk pro snadné generování web. stránek a obsluhu dat z formulářů. V PHP jsou tyto dvě věci mnohem jednodušší než v jiných jazycích, protože s nimi rovnou PHP počítá. Formulářová pole jsou načtena do proměnných, můžete míchat HTML a PHP kód. Ve větších projektech typu informační systém s webovým rozhraním vám tyto vlastnosti samozřejmě nijak moc nepomůžou, a napsat to v Perlu nebo Javě je stejná práce (možná třeba ještě menší protože ty jazyky mají lepší podporu pro výjimky, Unicode, OOP, ...). Když si však někdo chce na stránku umístit nějaký dotazník a podobnou legrácku, je pro něj asi nejjednodušší naučit se PHP (pokud zatím neumí jiný jazyk použitelný pro generování stránek). PHP podle mne přineslo "masám" možnost vytvářet dynamické webové stránky. Otázkou zůstává, zda je to dobře. ;)) Jinak PHP nabízí ještě jednu věc, u které si nejsem jistý jestli ji třeba umí Perl. Lze zapnout bufferovaný výstup, kdy se s odesláním vygenerované stránky čeká až na její dogenerování. HTTP hlavičky (včetně cookies) lze pak posílat kdykoliv, v případě chyby lze buffer smazat a vygenerovat chybovou stránku. Navíc lze obsah bufferu kdykoliv přečíst a znovu zpracovat. Buffery jsou navíc rekurzivní - lze je vkládat do sebe. Můžete třeba generovat XML kód a před odesláním na klienta jej z bufferu vytáhnout, zjistit si verzi prohlížeče a pustit na to XSLT transformaci upravenou podle klienta. Buffer se může postarat i o transparentní gzipování stránek pro prohlížeče, které to podporují. ----------------------------------------------------------------- Jirka Kosek e-mail: jirka na kosek.cz http://www.kosek.cz From xvalous na pluto.pslib.cz Mon Oct 15 16:00:36 2001 From: xvalous na pluto.pslib.cz (Tomas Valousek) Date: Mon, 15 Oct 2001 16:00:36 +0200 (CEST) Subject: C, python, perl, ...? In-Reply-To: Message-ID: On Mon, 15 Oct 2001, David Olszyński wrote: > Michal Špaček wrote: > > >> S pouzitim mod_perl dosahuje na webu velmi vysoke rychlosti, v > >> nekterych oblastech je rychlejsi nez PHP, v nekterych pomalejsi, ale > >> celkove jsou na tom co se rychlosti tyce zhruba stejne. > > No u malych aplikaci je php asi rychlejsi, protoze je trosku blize > > apachi nez perl. > > Zkousel jste nekdy mod-fastcgi? A porovnani s predchozima dvema? > > Myslim, ze je to dalsi moznost a porad perl. > > S mod_fastcgi mam velice dobre zkusenosti. Rekl bych, ze rychlosti > mod_perlu to asi nedosahuje, ale za to jsou s tim mnohem mensi problemy, > zvlaste pri prechodu z cgi aplikace. mod_perl jsem ale zkousel uz pred > dlouhou dobou, takze se to mozna zmenilo. Je to tak? Ja jsem fastcgi nezkousel. Muzu tedy pouze rici, ze prechod z beznych cgi v perlu na mod_perl me chvili trval, ale musim rict, ze me mod_perl donutilo pouzivat use Strict; a to me donutilo psat mensi prasarny, takze rychlost mod_perlu neni jedinou vyhodou :-) Pokud tedy chcete programovat neco vetsiho pro web a chcete to delat v Perlu, tak bych rekl ze ani jina varianta nez mod_perl neexistuje. Fast-cgi je skutecne vhodne pokud mate jiz cgi napsane a nechce se vam to prepisovat do tvaru vyhovujiciho mod_perlu. -- Tomas -VALY- Valousek web design, internet projects, linux etc.. email: tomas na valousek.cz www: http://www.spsselib.hiedu.cz/~xvalous (~=ALT+126) From skim na deltaes.cz Mon Oct 15 16:18:00 2001 From: skim na deltaes.cz (=?iso-8859-2?Q?Michal_=A9pa=E8ek?=) Date: Mon, 15 Oct 2001 16:18:00 +0200 Subject: C, python, perl, ...? In-Reply-To: ; from hisaak@mrkvoslav.ascs.muni.cz on Mon, Oct 15, 2001 at 12:22:43PM +0000 References: <200110151038.MAA05373@p44u01.plz.pvt.cz> <20011015132834.B1071@lxserver.deltes.cz> Message-ID: <20011015161800.L1071@lxserver.deltes.cz> On Mon, Oct 15, 2001 at 12:22:43PM +0000, David Olszyński wrote: > Michal Špaček wrote: > >> S pouzitim mod_perl dosahuje na webu velmi vysoke rychlosti, v > >> nekterych oblastech je rychlejsi nez PHP, v nekterych pomalejsi, ale > >> celkove jsou na tom co se rychlosti tyce zhruba stejne. > > No u malych aplikaci je php asi rychlejsi, protoze je trosku blize > > apachi nez perl. > > Zkousel jste nekdy mod-fastcgi? A porovnani s predchozima dvema? > > Myslim, ze je to dalsi moznost a porad perl. > S mod_fastcgi mam velice dobre zkusenosti. Rekl bych, ze rychlosti > mod_perlu to asi nedosahuje, ale za to jsou s tim mnohem mensi problemy, > zvlaste pri prechodu z cgi aplikace. mod_perl jsem ale zkousel uz pred > dlouhou dobou, takze se to mozna zmenilo. Je to tak? ad mod-fastcgi. No kazdopadne si muzete docela pohrat s temi procesy. Pocet pristupu apod. Muzete je hazet na ruzne servery apod. Prave nevim, co umi novy mod-perl. Jestli jde treba nejak skalovat? Chapu, ze bude mozna trosku rychlejsi, ale kdyz chcete udelat nejaky velky engine se spoustou procesu, je podle me jasne lepsi fastcgi. Pokud se mylim, nebo ma nekdo jine zkusenosti, velice rad se to dozvim. skim -- --------------------------------------------------- Michal "sKim" Spacek Brno, CZ, Europe E-mail: skim na deltaes.com icq: 66962942 user: debian, TeX ------=[ #!/usr/bin/perl ]=------------------------ From skim na deltaes.cz Mon Oct 15 16:22:14 2001 From: skim na deltaes.cz (=?iso-8859-2?Q?Michal_=A9pa=E8ek?=) Date: Mon, 15 Oct 2001 16:22:14 +0200 Subject: C, python, perl, ...? In-Reply-To: <3BCAE072.56619772@kosek.cz>; from jirka@kosek.cz on Mon, Oct 15, 2001 at 03:11:14PM +0200 References: <3BCA7E7F.BA338B2D@tmapy.cz> <20011015114830.C19715@zf.jcu.cz> <3BCAE072.56619772@kosek.cz> Message-ID: <20011015162214.M1071@lxserver.deltes.cz> On Mon, Oct 15, 2001 at 03:11:14PM +0200, Jirka Kosek wrote: > PHP však bylo původně navrženo jako jazyk pro snadné generování web. > stránek a obsluhu dat z formulářů. V PHP jsou tyto dvě věci mnohem > jednodušší než v jiných jazycích, protože s nimi rovnou PHP počítá. Takze asi neco to da v rychlosti. Jinak perl ma modul na CGI formulare a ten to umi zpracovat. > Formulářová pole jsou načtena do proměnných, můžete míchat HTML a PHP > kód. Na tohle jsou v perlu dalsi engines. > Ve větších projektech typu informační systém s webovým rozhraním > vám tyto vlastnosti samozřejmě nijak moc nepomůžou, a napsat to v Perlu > nebo Javě je stejná práce (možná třeba ještě menší protože ty jazyky > mají lepší podporu pro výjimky, Unicode, OOP, ...). jasne > Když si však někdo chce na stránku umístit nějaký dotazník a podobnou > legrácku, je pro něj asi nejjednodušší naučit se PHP (pokud zatím neumí > jiný jazyk použitelný pro generování stránek). Jasne - to beru. otazka, co bude v budoucnu, kdyz se tam prida spousta veci. Myslim, ze je dobre mit engine pro jedoduche veci a pro slozite veci a pak pro hodne veci apod. > PHP podle mne přineslo "masám" možnost vytvářet dynamické webové > stránky. Otázkou zůstává, zda je to dobře. ;)) ano > Jinak PHP nabízí ještě jednu věc, u které si nejsem jistý jestli ji > třeba umí Perl. Lze zapnout bufferovaný výstup, kdy se s odesláním > vygenerované stránky čeká až na její dogenerování. HTTP hlavičky (včetně > cookies) lze pak posílat kdykoliv, v případě chyby lze buffer smazat a > vygenerovat chybovou stránku. Navíc lze obsah bufferu kdykoliv přečíst a > znovu zpracovat. Buffery jsou navíc rekurzivní - lze je vkládat do sebe. > Můžete třeba generovat XML kód a před odesláním na klienta jej z bufferu > vytáhnout, zjistit si verzi prohlížeče a pustit na to XSLT transformaci > upravenou podle klienta. Buffer se může postarat i o transparentní > gzipování stránek pro prohlížeče, které to podporují. Tak tohle nevim jestli existuje. skim -- --------------------------------------------------- Michal "sKim" Spacek Brno, CZ, Europe E-mail: skim na deltaes.com icq: 66962942 user: debian, TeX ------=[ #!/usr/bin/perl ]=------------------------ From roubm9am na barbora.ms.mff.cuni.cz Mon Oct 15 16:39:50 2001 From: roubm9am na barbora.ms.mff.cuni.cz (Milan Roubal) Date: Mon, 15 Oct 2001 16:39:50 +0200 Subject: C, python, perl, ...? References: <3BCA7E7F.BA338B2D@tmapy.cz> <20011015114830.C19715@zf.jcu.cz> <3BCAE072.56619772@kosek.cz> <20011015162214.M1071@lxserver.deltes.cz> Message-ID: <028e01c15587$3f1a7910$561b71c3@krlis> tohle je hodne zajimava informace. Jake se pouzvaji funkce pro praci s tema bufferama? Jake jsou vase zkusenosti s pouzivanim teto technologie? Je to nejak poznat v rychlosti, v zatizeni procesoru, v obsazeni pameti? Zdravi Milan Roubal roubm9am na barbora.ms.mff.cuni.cz ----- Original Message ----- From: "Michal Špaček" To: Sent: Monday, October 15, 2001 4:22 PM Subject: Re: C, python, perl, ...? On Mon, Oct 15, 2001 at 03:11:14PM +0200, Jirka Kosek wrote: > PHP však bylo původně navrženo jako jazyk pro snadné generování web. > stránek a obsluhu dat z formulářů. V PHP jsou tyto dvě věci mnohem > jednodušší než v jiných jazycích, protože s nimi rovnou PHP počítá. Takze asi neco to da v rychlosti. Jinak perl ma modul na CGI formulare a ten to umi zpracovat. > Formulářová pole jsou načtena do proměnných, můžete míchat HTML a PHP > kód. Na tohle jsou v perlu dalsi engines. > Ve větších projektech typu informační systém s webovým rozhraním > vám tyto vlastnosti samozřejmě nijak moc nepomůžou, a napsat to v Perlu > nebo Javě je stejná práce (možná třeba ještě menší protože ty jazyky > mají lepší podporu pro výjimky, Unicode, OOP, ...). jasne > Když si však někdo chce na stránku umístit nějaký dotazník a podobnou > legrácku, je pro něj asi nejjednodušší naučit se PHP (pokud zatím neumí > jiný jazyk použitelný pro generování stránek). Jasne - to beru. otazka, co bude v budoucnu, kdyz se tam prida spousta veci. Myslim, ze je dobre mit engine pro jedoduche veci a pro slozite veci a pak pro hodne veci apod. > PHP podle mne přineslo "masám" možnost vytvářet dynamické webové > stránky. Otázkou zůstává, zda je to dobře. ;)) ano > Jinak PHP nabízí ještě jednu věc, u které si nejsem jistý jestli ji > třeba umí Perl. Lze zapnout bufferovaný výstup, kdy se s odesláním > vygenerované stránky čeká až na její dogenerování. HTTP hlavičky (včetně > cookies) lze pak posílat kdykoliv, v případě chyby lze buffer smazat a > vygenerovat chybovou stránku. Navíc lze obsah bufferu kdykoliv přečíst a > znovu zpracovat. Buffery jsou navíc rekurzivní - lze je vkládat do sebe. > Můžete třeba generovat XML kód a před odesláním na klienta jej z bufferu > vytáhnout, zjistit si verzi prohlížeče a pustit na to XSLT transformaci > upravenou podle klienta. Buffer se může postarat i o transparentní > gzipování stránek pro prohlížeče, které to podporují. Tak tohle nevim jestli existuje. skim -- --------------------------------------------------- Michal "sKim" Spacek Brno, CZ, Europe E-mail: skim na deltaes.com icq: 66962942 user: debian, TeX ------=[ #!/usr/bin/perl ]=------------------------ From janousek na fonet.cz Mon Oct 15 16:49:08 2001 From: janousek na fonet.cz (Ing. Pavel PaJaSoft Janousek) Date: Mon, 15 Oct 2001 16:49:08 +0200 Subject: C, python, perl, ...? References: <3BCA7E7F.BA338B2D@tmapy.cz> <20011015114830.C19715@zf.jcu.cz> <3BCAE072.56619772@kosek.cz> Message-ID: <3BCAF764.5433B254@fonet.cz> > Formulářová pole jsou načtena do proměnných, můžete míchat HTML a PHP > kód. Ve větších projektech typu informační systém s webovým rozhraním Michat HTML s PHP povazuji za velmi kontraproduktivni jiz v okamziku, kdy programator != designer. Existuji ruzne pokusy jak resit tuto praci, zadny vsak IMHO neni prilis uspesny. > Můžete třeba generovat XML kód a před odesláním na klienta jej z bufferu > vytáhnout, zjistit si verzi prohlížeče a pustit na to XSLT transformaci > upravenou podle klienta. Buffer se může postarat i o transparentní > gzipování stránek pro prohlížeče, které to podporují. Nechci tu Javu cpat vsude, ale domnivam se, ze podobne technologie nad Javou (mysleno na Webu) jsou vyspele a robustni. Nevim vsak o nich mnoho, z toho co vim na mne tak pusobi... ----------------------------------------------------------------------- Ing. Pavel Janousek (PaJaSoft) FoNet, spol. s r. o. Vyvoj software, Intranet / Internet Sokolova 67, 619 00 Brno E-mail: mailto:Janousek na FoNet.Cz Tel.: +420 5 4324 4749 SMS: mailto:P.Janousek na SMS.Paegas.Cz Fax.: +420 5 4324 4751 WWW: http://WWW.FoNet.Cz/ E-mail: mailto:Info na FoNet.Cz ----------------------------------------------------------------------- From skim na deltaes.cz Mon Oct 15 17:04:41 2001 From: skim na deltaes.cz (=?iso-8859-2?Q?Michal_=A9pa=E8ek?=) Date: Mon, 15 Oct 2001 17:04:41 +0200 Subject: C, python, perl, ...? In-Reply-To: <3BCAF764.5433B254@fonet.cz>; from janousek@fonet.cz on Mon, Oct 15, 2001 at 04:49:08PM +0200 References: <3BCA7E7F.BA338B2D@tmapy.cz> <20011015114830.C19715@zf.jcu.cz> <3BCAE072.56619772@kosek.cz> <3BCAF764.5433B254@fonet.cz> Message-ID: <20011015170441.N1071@lxserver.deltes.cz> On Mon, Oct 15, 2001 at 04:49:08PM +0200, Ing. Pavel PaJaSoft Janousek wrote: > > Formulářová pole jsou načtena do proměnných, můžete míchat HTML a PHP > > kód. Ve větších projektech typu informační systém s webovým rozhraním > Michat HTML s PHP povazuji za velmi kontraproduktivni jiz v okamziku, > kdy programator != designer. Existuji ruzne pokusy jak resit tuto praci, > zadny vsak IMHO neni prilis uspesny. Predpokladam, ze autor mel na mysli nejaky system templatu? PHP a HTML to jsou vlastne template ne? Takze co byste doporucoval? skim -- --------------------------------------------------- Michal "sKim" Spacek Brno, CZ, Europe E-mail: skim na deltaes.com icq: 66962942 user: debian, TeX ------=[ #!/usr/bin/perl ]=------------------------ From janousek na fonet.cz Mon Oct 15 17:06:07 2001 From: janousek na fonet.cz (Ing. Pavel PaJaSoft Janousek) Date: Mon, 15 Oct 2001 17:06:07 +0200 Subject: C, python, perl, ...? References: <3BCA7E7F.BA338B2D@tmapy.cz> <20011015114830.C19715@zf.jcu.cz> <3BCAE072.56619772@kosek.cz> <3BCAF764.5433B254@fonet.cz> <20011015170441.N1071@lxserver.deltes.cz> Message-ID: <3BCAFB5F.C3D0B0CA@fonet.cz> Michal Špaček wrote: > > On Mon, Oct 15, 2001 at 04:49:08PM +0200, Ing. Pavel PaJaSoft Janousek wrote: > > > Formulářová pole jsou načtena do proměnných, můžete míchat HTML a PHP > > > kód. Ve větších projektech typu informační systém s webovým rozhraním > > Michat HTML s PHP povazuji za velmi kontraproduktivni jiz v okamziku, > > kdy programator != designer. Existuji ruzne pokusy jak resit tuto praci, > > zadny vsak IMHO neni prilis uspesny. > Predpokladam, ze autor mel na mysli nejaky system templatu? PHP a HTML > to jsou vlastne template ne? > Takze co byste doporucoval? Jiz jsem zminil, libi se mi a fandim http://www.hyperqbs.org/, resi vse, s cim jsem se zatim kdy na Webu setkal a v mnoha vecech jde jeste dale... ale je to java (jeden z nabizenych parseru je FreeMarker, takze i prog. na urovni designera je mozne a casto ho pouzivam)... co se tyka PHP, v tom nejsem kovany to by museli rici jini... PS: O robustnosti technologie, byt trochu starsiho vydani svedci Weby Bontonu a Aholdu, kde je technologie pouzita... ----------------------------------------------------------------------- Ing. Pavel Janousek (PaJaSoft) FoNet, spol. s r. o. Vyvoj software, Intranet / Internet Sokolova 67, 619 00 Brno E-mail: mailto:Janousek na FoNet.Cz Tel.: +420 5 4324 4749 SMS: mailto:P.Janousek na SMS.Paegas.Cz Fax.: +420 5 4324 4751 WWW: http://WWW.FoNet.Cz/ E-mail: mailto:Info na FoNet.Cz ----------------------------------------------------------------------- From jirka na kosek.cz Mon Oct 15 17:09:07 2001 From: jirka na kosek.cz (Jirka Kosek) Date: Mon, 15 Oct 2001 17:09:07 +0200 Subject: C, python, perl, ...? References: <3BCA7E7F.BA338B2D@tmapy.cz> <028e01c15587$3f1a7910$561b71c3@krlis> Message-ID: <3BCAFC13.80E6901C@kosek.cz> Milan Roubal wrote: > > tohle je hodne zajimava informace. > Jake se pouzvaji funkce pro praci s tema bufferama? Podívejte se do manuálu na funkce začínající na ob_ > Jake jsou vase zkusenosti s pouzivanim teto technologie? Výborné. > Je to nejak poznat v rychlosti, v zatizeni procesoru, v obsazeni pameti? Tak důkladně jsem to netestoval, určitě bude větší spotřeba paměti, ale pro většinu aplikací asi nijak kriticky. ----------------------------------------------------------------- Jirka Kosek e-mail: jirka na kosek.cz http://www.kosek.cz From pavel na templation.net Mon Oct 15 16:45:42 2001 From: pavel na templation.net (Pavel Kolesnikov) Date: Mon, 15 Oct 2001 14:45:42 +0000 (UTC) Subject: C, python, perl, ...? References: <3BCA7E7F.BA338B2D@tmapy.cz> <3BCACA84.BC43A9CF@fonet.cz> Message-ID: <9qesql$4ru$1@news.nextra.cz> Ing. Pavel PaJaSoft Janousek wrote: > > Ja se ozyvam, protoze do toho trosku delam. Ono neni jenom JSP, coby > "Javovske-PHP" na strane serveru, ale take treba napr. > http://www.hyperqbs.org, ktere se mi osobne libi a resi problemy, ktere > coby zarputili CGIckar (v C++) musim slozite resit ve vlastni rezii. Nad Co se HyperQbs tyce, setkal jsem se s nimi jen co do povsechne prezentace, a vzhledem k tomu, ze jako jednu z klicovych vlastnosti uvadeji "write once, view anywhere", prisly mi vzdy trochu podezrele, protoze snaha o oddeleni aplikacni a prezentacni logiky mi prijde spis jako samozrejmost nez nejaka velka dira do sveta. Mohl bys trosku rozvest sve dojmy? Pokud ses setkal s cocoonem, ktery se IMHO snazi velmi dobre o totez, moh bys nastinit lehkce srovnani? Dik Pavel -- Templation, Drtinova 8, Praha 5 tel. +420 2 57 018 433 fax +420 2 57 018 425 email: pavel na templation.net From jirka na kosek.cz Mon Oct 15 17:18:01 2001 From: jirka na kosek.cz (Jirka Kosek) Date: Mon, 15 Oct 2001 17:18:01 +0200 Subject: C, python, perl, ...? References: <3BCA7E7F.BA338B2D@tmapy.cz> <3BCAF764.5433B254@fonet.cz> Message-ID: <3BCAFE29.A3746F87@kosek.cz> "Ing. Pavel PaJaSoft Janousek" wrote: > Michat HTML s PHP povazuji za velmi kontraproduktivni jiz v okamziku, > kdy programator != designer. Existuji ruzne pokusy jak resit tuto praci, > zadny vsak IMHO neni prilis uspesny. Mnoho lidí dnes pracuje jako tripartita = designér + HTML kodér + programátor U velkých projektů to je samozřejmě nesmyslné, ale existuje spoustu malých aplikací, projektů, stránek, kde to nevadí. > > Můžete třeba generovat XML kód a před odesláním na klienta jej z bufferu > > vytáhnout, zjistit si verzi prohlížeče a pustit na to XSLT transformaci > > upravenou podle klienta. Buffer se může postarat i o transparentní > > gzipování stránek pro prohlížeče, které to podporují. > > Nechci tu Javu cpat vsude, ale domnivam se, ze podobne technologie nad > Javou (mysleno na Webu) jsou vyspele a robustni. Nevim vsak o nich > mnoho, z toho co vim na mne tak pusobi... Vyspělé a robustní jsou. Kvůli té robustnosti však máte mnohdy mnohem více práce než třeba v PHP. Když chcete v Javě (servlet/JSP) načíst číslo z HTML formuláře, musíte otestovat jestli je v řetezci něco, co lze chápat jako číslo a pak to teprve převést na číslo. V PHP zkrátka s tou hodnotou rovnou pracujete. Pokud by náhodou neobsahovala číslo, ale nějaký nesmysl, chápe se jako 0. Jistěže to není robustní, ale pro velkou část aplikací to stačí. V těch ostatních ty kontroly můžete udělat i v PHP. Rozdíl je v tom, že v Javě je udělat musíte -> nutí vás to psát robustnější kód. Při představě, že někoho učím principy jednoduché obsluhy webových formulářů na JSP, mě vstávají vlasy hrůzou. Tři čtvrtiny kódu totož nejsou o ničem jiném, než o správném přetypování z textových řetězců na javové typy. ;( Nadruhou stranu taglibraries jsou docela pěkně. ;) Proč jsou ale JSP navrženy tak, že nejsou XML dokument, to tedy nechápu. ;( V tomto ohledu je na tom nakonec nejlépe PHP. ----------------------------------------------------------------- Jirka Kosek e-mail: jirka na kosek.cz http://www.kosek.cz From hisaak na mrkvoslav.ascs.muni.cz Mon Oct 15 18:06:33 2001 From: hisaak na mrkvoslav.ascs.muni.cz (David =?ISO-8859-2?Q?Olszy=F1ski?=) Date: Mon, 15 Oct 2001 16:06:33 GMT Subject: OT: Re: C, python, perl, ...? References: Message-ID: Tomas Valousek wrote: > On Mon, 15 Oct 2001, David Olszyński wrote: > >> Michal Špaček wrote: >> >> >> S pouzitim mod_perl dosahuje na webu velmi vysoke rychlosti, v >> >> nekterych oblastech je rychlejsi nez PHP, v nekterych pomalejsi, ale >> >> celkove jsou na tom co se rychlosti tyce zhruba stejne. >> > No u malych aplikaci je php asi rychlejsi, protoze je trosku blize >> > apachi nez perl. >> > Zkousel jste nekdy mod-fastcgi? A porovnani s predchozima dvema? >> > Myslim, ze je to dalsi moznost a porad perl. >> >> S mod_fastcgi mam velice dobre zkusenosti. Rekl bych, ze rychlosti >> mod_perlu to asi nedosahuje, ale za to jsou s tim mnohem mensi problemy, >> zvlaste pri prechodu z cgi aplikace. mod_perl jsem ale zkousel uz pred >> dlouhou dobou, takze se to mozna zmenilo. Je to tak? > Ja jsem fastcgi nezkousel. Muzu tedy pouze rici, ze prechod z beznych cgi > v perlu na mod_perl me chvili trval, ale musim rict, ze me mod_perl > donutilo pouzivat use Strict; a to me donutilo psat mensi prasarny, takze > rychlost mod_perlu neni jedinou vyhodou :-) Me ten prechod (spise pokus o prechod) trval taky dlouho a presto, ze jsem use strict; pouzival, neslo to. Hodne me tehdy odradily velice prapodivne chyby, ktere jsem pricital nevyzralosti mod_perlu. Jak jsem ale psal, je to uz dlouho a mozna to bylo i rukama. Nemel byste jeste dalsi rady krome obligatniho use strict;, jak rozumne prevest cgi na mod_perl? Nebo nejakou stranecku? http://perl.apache.org/guide/porting.html vypada celkem obsahle. Jde to podle toho? > Pokud tedy chcete programovat neco vetsiho pro web a chcete to delat v > Perlu, tak bych rekl ze ani jina varianta nez mod_perl neexistuje. > Fast-cgi je skutecne vhodne pokud mate jiz cgi napsane a nechce se vam to > prepisovat do tvaru vyhovujiciho mod_perlu. A nebo (jak je obvykle) nemate cas. ;-) hisaak > > From tomas na neo.cz Mon Oct 15 18:47:09 2001 From: tomas na neo.cz (Kouba Tomas) Date: Mon, 15 Oct 2001 18:47:09 +0200 Subject: C, python, perl, ...? In-Reply-To: <3BCAF764.5433B254@fonet.cz> Message-ID: Ano je to tak, delame pro web servlety v Jave a je to podle meho nejrobustnejsi a nejvykonnejsi technologie pro web soucasnosti. PHP i Perl znam a mam rad, ale podle meho to naprosto neni vhodne na proejkty nad cca 10.000 radku kodu. Nezkuseny programator se ztrati jiz < 1.000 radku. -- Tomas Kouba mailto:tomas na neo.cz > > Můžete třeba generovat XML kód a před odesláním na klienta jej z bufferu > > vytáhnout, zjistit si verzi prohlížeče a pustit na to XSLT transformaci > > upravenou podle klienta. Buffer se může postarat i o transparentní > > gzipování stránek pro prohlížeče, které to podporují. > > Nechci tu Javu cpat vsude, ale domnivam se, ze podobne > technologie nad > Javou (mysleno na Webu) jsou vyspele a robustni. Nevim vsak o nich > mnoho, z toho co vim na mne tak pusobi... > From pavel na templation.net Mon Oct 15 18:49:09 2001 From: pavel na templation.net (Pavel Kolesnikov) Date: Mon, 15 Oct 2001 16:49:09 +0000 (UTC) Subject: C, python, perl, ...? References: <3BCA7E7F.BA338B2D@tmapy.cz> <3BCAFB5F.C3D0B0CA@fonet.cz> Message-ID: <9qf424$b2j$1@news.nextra.cz> Ing. Pavel PaJaSoft Janousek wrote: > > Jiz jsem zminil, libi se mi a fandim http://www.hyperqbs.org/, resi > vse, s cim jsem se zatim kdy na Webu setkal a v mnoha vecech jde jeste > dale... ale je to java (jeden z nabizenych parseru je FreeMarker, takze > i prog. na urovni designera je mozne a casto ho pouzivam)... co se tyka > PHP, v tom nejsem kovany to by museli rici jini... > > PS: O robustnosti technologie, byt trochu starsiho vydani svedci Weby > Bontonu a Aholdu, kde je technologie pouzita... Tady bych si dovolil upresneni, webem Bontonu mas jiste na mysli www.bontonland.cz a ne www.bonton.cz. Druhy z uvedenych je spise odstrasujicim prikladem na uziti PHP ;) Pavel Kolesnikov -- Templation, Drtinova 8, Praha 5 tel. +420 2 57 018 433 fax +420 2 57 018 425 email: pavel na templation.net From xvalous na pluto.pslib.cz Mon Oct 15 19:52:27 2001 From: xvalous na pluto.pslib.cz (Tomas Valousek) Date: Mon, 15 Oct 2001 19:52:27 +0200 (CEST) Subject: OT: Re: C, python, perl, ...? In-Reply-To: Message-ID: On Mon, 15 Oct 2001, David Olszyński wrote: > Me ten prechod (spise pokus o prechod) trval taky dlouho a presto, ze jsem > use strict; pouzival, neslo to. Hodne me tehdy odradily velice prapodivne > chyby, ktere jsem pricital nevyzralosti mod_perlu. Jak jsem ale psal, je to > uz dlouho a mozna to bylo i rukama. > Nemel byste jeste dalsi rady krome obligatniho use strict;, jak rozumne > prevest cgi na mod_perl? Nebo nejakou stranecku? > http://perl.apache.org/guide/porting.html vypada celkem obsahle. Jde to > podle toho? Na zakladni pochopeni principu mod_perl a stylu programovani mi stacila cast venovana v knize Webmaster v kostce. Tam jsem se v cestine dozvedel zakladni veci a podle ni udelal prvni funkci kod. Kdyz jsem se v tom neco naucil a napsal par set radku kodu prisla na radu man mod_perl. Zjednodusene se da rict, ze staci pouzivat privatni promene (my $prom), pouzivat perl -w a pak uz si urcite poradite. Z tech chybovych hlasek se velmi snadno da najit chyba. -- Tomas -VALY- Valousek web design, internet projects, linux etc.. email: tomas na valousek.cz www: http://www.spsselib.hiedu.cz/~xvalous (~=ALT+126) From stano-cznews na meduna.org Mon Oct 15 20:02:58 2001 From: stano-cznews na meduna.org (Stanislav Meduna) Date: Mon, 15 Oct 2001 18:02:58 +0000 (UTC) Subject: Objektovy PostgreSQL? References: <3BCAA154.000001.08170@www2.email.atc> <20011015111745.B19715@zf.jcu.cz> Message-ID: <9qf8ci$391$1@meduna.org> On Mon, 15 Oct 2001 09:17:48 +0000 (UTC), Karel Zak wrote: : Ciste OO DB (ODBM) nepouzivaji zadny high-level jazyk jako je SQL, : ale pristupuji k DB jako k objektum a data neukladaji do radek, ale : do objektu. IMHO je todle je mrtva zalezitost na urovni nejakych : obecnych DB, Ani by som nepovedal. Pokial dotycna databaza ponukne jednoduche spojenie s niektorym z OO jazykov a (skoro-) transparentne zaisti perzistenciu objektov, s ktorymi sa pracuje, ma to svoj vyznam a skor je to zatial nedocenene, ako zeby to bolo mrtve. S cim su zatial problemy je rychlost - relacna databaza je z hladiska implementacie jednoduchsia a ma za sebou roky vyvoja, OO databazy su relativne mlade. Jeden znamy pracuje na pomerne velkom projekte vyuzivajucom databazu Versant s bindingom na Javu a je velmi spokojny. : a bude asi vice vyuzivano nejakych komponentovych : technologii (Corba apod.), kde komponenty delaji API k bezne DB. Problem je, ze vysledkom je halda otrockeho kodu, starajuca sa o mapovanie objektov do RDBMS. Sam som to parkrat robil, kolegovia to robili este castejsie a je to riadna otrava, zvlast hierarchicke struktury su potesenim... Zdravi -- Stano From vladimir.naprstek na scplyn.cz Tue Oct 16 09:45:03 2001 From: vladimir.naprstek na scplyn.cz (=?ISO-8859-1?B?VmxhZGlt7XIgTuFwcnN0ZWs=?=) Date: Tue, 16 Oct 2001 08:45:03 +0100 Subject: PostgreSQL a LDAP Message-ID: Zdravím, umí postgre autentifikaci uživatele proti LDAP serveru nebo jsou prostředky jak toho dosáhnout? V dokumentaci se slovo LDAP nenachází... -------------------------------------------------------------------------------------------- Ing. Vladimír Náprstek, mail-to:vladimir.naprstek na scplyn.cz From zakkr na zf.jcu.cz Tue Oct 16 09:06:48 2001 From: zakkr na zf.jcu.cz (Karel Zak) Date: Tue, 16 Oct 2001 09:06:48 +0200 Subject: PostgreSQL a LDAP In-Reply-To: ; from vladimir.naprstek@scplyn.cz on Tue, Oct 16, 2001 at 08:45:03AM +0100 References: Message-ID: <20011016090648.A8517@zf.jcu.cz> On Tue, Oct 16, 2001 at 08:45:03AM +0100, Vladimír Náprstek wrote: > Zdravím, > umí postgre autentifikaci uživatele proti LDAP serveru nebo jsou prostředky jak toho dosáhnout? > V dokumentaci se slovo LDAP nenachází... Nejde to. V 7.2 (zatim jeste neni venku) by mela byt podpora PAM. Karel -- Karel Zak http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz From zakkr na zf.jcu.cz Tue Oct 16 10:43:38 2001 From: zakkr na zf.jcu.cz (Karel Zak) Date: Tue, 16 Oct 2001 10:43:38 +0200 Subject: Objektovy PostgreSQL? In-Reply-To: <9qf8ci$391$1@meduna.org>; from stano-cznews@meduna.org on Mon, Oct 15, 2001 at 06:02:58PM +0000 References: <3BCAA154.000001.08170@www2.email.atc> <20011015111745.B19715@zf.jcu.cz> <9qf8ci$391$1@meduna.org> Message-ID: <20011016104338.D8517@zf.jcu.cz> On Mon, Oct 15, 2001 at 06:02:58PM +0000, Stanislav Meduna wrote: > On Mon, 15 Oct 2001 09:17:48 +0000 (UTC), Karel Zak wrote: > > : Ciste OO DB (ODBM) nepouzivaji zadny high-level jazyk jako je SQL, > : ale pristupuji k DB jako k objektum a data neukladaji do radek, ale > : do objektu. IMHO je todle je mrtva zalezitost na urovni nejakych > : obecnych DB, > > Ani by som nepovedal. Pokial dotycna databaza ponukne jednoduche > spojenie s niektorym z OO jazykov a (skoro-) transparentne > zaisti perzistenciu objektov, s ktorymi sa pracuje, ma to > svoj vyznam a skor je to zatial nedocenene, ako zeby to > bolo mrtve. Neni to pak vice sklad komponent (objektu) nez DB popisujici nejaky problem pomoci definic vazeb mezi tabulkama (apod.)? > S cim su zatial problemy je rychlost - relacna databaza je z hladiska > implementacie jednoduchsia a ma za sebou roky vyvoja, OO databazy > su relativne mlade. Nevim, nejak moc do veci okolo OO nedelam, ale rekl bych, ze vyvoj se uz dost dlouho drzi objektove-relacnich DB. Take tak jsem to myslel. Ted nad tim premyslim a stejne mi neni uplne jasne propojeni tech objektu. Porad my z toho vychazi nejaky model v kterem budou relace (jinak by to byl navrat k nejakemu hierarchickemu nebo sitovemu modelu)... > Jeden znamy pracuje na pomerne velkom projekte vyuzivajucom > databazu Versant s bindingom na Javu a je velmi spokojny. > > : a bude asi vice vyuzivano nejakych komponentovych > : technologii (Corba apod.), kde komponenty delaji API k bezne DB. > > Problem je, ze vysledkom je halda otrockeho kodu, starajuca > sa o mapovanie objektov do RDBMS. Sam som to parkrat robil, > kolegovia to robili este castejsie a je to riadna otrava, zvlast > hierarchicke struktury su potesenim... Ty jsou obecnym problem SQL (= neproceduralni a nerekurzivni jazyk:-) Karel -- Karel Zak http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz From janousek na fonet.cz Tue Oct 16 11:16:37 2001 From: janousek na fonet.cz (Ing. Pavel PaJaSoft Janousek) Date: Tue, 16 Oct 2001 11:16:37 +0200 Subject: Objektovy PostgreSQL? References: <3BCAA154.000001.08170@www2.email.atc> <20011015111745.B19715@zf.jcu.cz> <9qf8ci$391$1@meduna.org> <20011016104338.D8517@zf.jcu.cz> Message-ID: <3BCBFAF5.5579B96B@fonet.cz> > > Problem je, ze vysledkom je halda otrockeho kodu, starajuca > > sa o mapovanie objektov do RDBMS. Sam som to parkrat robil, > > kolegovia to robili este castejsie a je to riadna otrava, zvlast > > hierarchicke struktury su potesenim... > > Ty jsou obecnym problem SQL (= neproceduralni a nerekurzivni jazyk:-) Zive si vzpominam, jak jeden muj kolega, vyborny teoretik mel krasne vymysleny projekt, vse mel v grafovych strukturach. Vsechny veci byly jednoduse implementovatelne diky existenci kvalitnich algoritmu na barveni cesty, detekce cyklu atd., super skalovatelne, protoze tyto algoritmy existuji nejen teoreticky i pro libovolny pocet NODu (a snad pro skoro vsechny usporadani) atd.. proste sama superlativa, jenze ouha, byl hozen do praxe, zacal s MySQL - to jsem ho vyvedl z omylu, at zkusi aspon nejakou poradnou databazi se zamykanim a transakcemi (PostgreSQL:->), ale i tak splakal... Tak mne napada, k cemu tyto veci krome opravdu vedeckotechnickych vypoctu jsou (ne ze by to nestacilo), kdyz alepson 90% veci co pocitace delaji se da shrnout pod polozku hromadne zpracovani dat - tedy vyber a ukladani do datastoru + nejaky data mining... Lze to vubec resit? ----------------------------------------------------------------------- Ing. Pavel Janousek (PaJaSoft) FoNet, spol. s r. o. Vyvoj software, Intranet / Internet Sokolova 67, 619 00 Brno E-mail: mailto:Janousek na FoNet.Cz Tel.: +420 5 4324 4749 SMS: mailto:P.Janousek na SMS.Paegas.Cz Fax.: +420 5 4324 4751 WWW: http://WWW.FoNet.Cz/ E-mail: mailto:Info na FoNet.Cz ----------------------------------------------------------------------- From rk na dat.cz Tue Oct 16 13:48:16 2001 From: rk na dat.cz (Radek Kanovsky) Date: Tue, 16 Oct 2001 13:48:16 +0200 Subject: Objektovy PostgreSQL? In-Reply-To: <20011016104338.D8517@zf.jcu.cz> References: <3BCAA154.000001.08170@www2.email.atc> <20011015111745.B19715@zf.jcu.cz> <9qf8ci$391$1@meduna.org> <20011016104338.D8517@zf.jcu.cz> Message-ID: <20011016134816.C19518@dat.cz> On Tue, Oct 16, 2001 at 10:43:38AM +0200, Karel Zak wrote: > > S cim su zatial problemy je rychlost - relacna databaza je z hladiska > > implementacie jednoduchsia a ma za sebou roky vyvoja, OO databazy > > su relativne mlade. > > Nevim, nejak moc do veci okolo OO nedelam, ale rekl bych, ze > vyvoj se uz dost dlouho drzi objektove-relacnich DB. Take tak > jsem to myslel. Ted nad tim premyslim a stejne mi neni uplne > jasne propojeni tech objektu. Porad my z toho vychazi nejaky > model v kterem budou relace (jinak by to byl navrat k nejakemu > hierarchickemu nebo sitovemu modelu)... Model u OODB je - jak jinak - objektovy. Kazdy objekt ma svoje OID, pres ktere je primo pristupny. OID je vetsinou jednoduse mapovano na misto na disku, kde jsou ulozeny hodnoty atributu. Vztahy mezi objekty v databazi jsou oproti relacnim databazim primocare. Pokud chci v SQL dostat polozky faktury, musim na to jit pres ID faktury a v tabulce polozky_faktury vybrat ze vsech radku ty, ktere maji v polozce ID hodnotu faktura.ID. Naproti tomu v OODB mam u kazde faktury primo pole referenci/pointeru na objekty polozek (referencni integrita je tu teda zarucena jaksi automaticky nebo nema smysl o ni vubec hovorit). Z toho plyne vysoka rychlost u takto strukturovanych dat. Vyhnete se pouzivani indexu pro vyhledani provazanych objektu. OODB se velmi dobre hodi pro aplikace, ktere vyzaduji ukladani slozitych provazanych struktur, stromu, XML dokumentu (ktere jsou svou povahou stromy a velmi spatne se ukladaji do relacnich databazi) apod. Dalsi vyhodou vetsiny OODB je to, ze tridy objektu definuju primo v jazyce, ve kterem se programuje aplikace. ODMG definuje standard pro jazyky Java, C++ a Smalltalk pro praci s OODB. Tim se clovek vyhne obcas schizofrenimu pouzivani dvou jazyku pri vyvoji aplikace (C+SQL apod). S instancemi objektu se potom pracuje temer stejne, jako kdyby byly tyto objekty alokovane v pameti. Tedy zadne mapovani vystupu z SQL na datove typy pouziteho jazyka apod. Vetsina OODB ma i svuj definicni a dotazovaci jazyk (OQL), ktere jsou take myslim standardizovane. Na adrese http://www-2.cs.cmu.edu/People/clamen/OODBMS/Manifesto/ je docela dobry popis vlastnosti OODB. Asi nejvetsim nedostatkem OODB je to, ze neexistuje rozuma open source OODB. Vetsina dostupnych databazi je necim velmi specialni nebo je v rozpracovanem stavu. Pokud by nekdo o nejake vedel, mohl by se tady zminit. Zdravi, RadekK From zakkr na zf.jcu.cz Tue Oct 16 14:32:46 2001 From: zakkr na zf.jcu.cz (Karel Zak) Date: Tue, 16 Oct 2001 14:32:46 +0200 Subject: Objektovy PostgreSQL? In-Reply-To: <20011016134816.C19518@dat.cz>; from rk@dat.cz on Tue, Oct 16, 2001 at 01:48:16PM +0200 References: <3BCAA154.000001.08170@www2.email.atc> <20011015111745.B19715@zf.jcu.cz> <9qf8ci$391$1@meduna.org> <20011016104338.D8517@zf.jcu.cz> <20011016134816.C19518@dat.cz> Message-ID: <20011016143246.I8517@zf.jcu.cz> On Tue, Oct 16, 2001 at 01:48:16PM +0200, Radek Kanovsky wrote: > On Tue, Oct 16, 2001 at 10:43:38AM +0200, Karel Zak wrote: > > > > S cim su zatial problemy je rychlost - relacna databaza je z hladiska > > > implementacie jednoduchsia a ma za sebou roky vyvoja, OO databazy > > > su relativne mlade. > > > > Nevim, nejak moc do veci okolo OO nedelam, ale rekl bych, ze > > vyvoj se uz dost dlouho drzi objektove-relacnich DB. Take tak > > jsem to myslel. Ted nad tim premyslim a stejne mi neni uplne > > jasne propojeni tech objektu. Porad my z toho vychazi nejaky > > model v kterem budou relace (jinak by to byl navrat k nejakemu > > hierarchickemu nebo sitovemu modelu)... > > Model u OODB je - jak jinak - objektovy. Kazdy objekt ma svoje OID, > pres ktere je primo pristupny. OID je vetsinou jednoduse mapovano na > misto na disku, kde jsou ulozeny hodnoty atributu. Vztahy mezi objekty > v databazi jsou oproti relacnim databazim primocare. Pokud chci v SQL > dostat polozky faktury, musim na to jit pres ID faktury a v tabulce > polozky_faktury vybrat ze vsech radku ty, ktere maji v polozce ID > hodnotu faktura.ID. Naproti tomu v OODB mam u kazde faktury primo pole > referenci/pointeru na objekty polozek (referencni integrita je tu > teda zarucena jaksi automaticky nebo nema smysl o ni vubec hovorit). > Z toho plyne vysoka rychlost u takto strukturovanych dat. Vyhnete > se pouzivani indexu pro vyhledani provazanych objektu. OODB se velmi > dobre hodi pro aplikace, ktere vyzaduji ukladani slozitych provazanych > struktur, stromu, XML dokumentu (ktere jsou svou povahou stromy a velmi > spatne se ukladaji do relacnich databazi) apod. Jenze relacni DB byla vytvorena prave pro nevhodnost stromu pro ukladani urcitych typu dat (napr. IMS - information management system od IBM z 60-tych let). Mezi hlavni nedostatky patril jediny existujici vztah rodic<->dite (podobne viz. struktura XML), problematicnost vytvareni vazeb mizi ruznymi urovnemi toho stromu a nasledne problem definovat zakladni mnozinove operace nad daty atd. Vsechno todle prichod relacnich DB vyresil. > Na adrese http://www-2.cs.cmu.edu/People/clamen/OODBMS/Manifesto/ > je docela dobry popis vlastnosti OODB. Dik, urcite se podivam. Karel -- Karel Zak http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz From adelton na informatics.muni.cz Tue Oct 16 14:43:59 2001 From: adelton na informatics.muni.cz (Honza Pazdziora) Date: Tue, 16 Oct 2001 14:43:59 +0200 Subject: spojeni tabulek In-Reply-To: <01100821184900.01720@linux>; from dev@b2bexpander.com on Mon, Oct 08, 2001 at 09:19:10PM +0200 References: <01100821184900.01720@linux> Message-ID: <20011016144359.A22374@anxur.fi.muni.cz> On Mon, Oct 08, 2001 at 09:19:10PM +0200, Jiri Chaloupka wrote: > Omlouvam se, je to ponekud stupidni dotaz, ale asi jsem uz pretazeny ... > > mam 2 tabulky, rekneme tabulku A a B, pricemz tabulka B obsahuje klic na > tabulku A - sloupec A_id. > > Tabulka A obsahuje zaznamy > > id | name > 1 | jmeno1 > 2 | jmeno 2 > 3 | jmeno 3 > > tabulka B obsahuje zaznamy > > id | A_id | text > 1 | 1 | text1 > 2 | 2 | text2 > > a pak mam sql dotaz ve tvaru "select A.id, A.name, B.text from A, B where > A.id = B.A_id" > > a tento dotaz mi vrati vysledek: > id | name | text > 1 | jmeno1 | text 1 > 2 | jmeno 2 | text 2 > 3 | jmeno 3 | text 2 > > nejak nechapu, ten treti radek tam preci nema byt, ale nemohu se ho zbavit > ... Kde mam blbost? Chyba je budto mezi klavesnici a zidli, tedy mate tam jeste nejake jine zaznamy, ktere nevidite / neuvadite, nebo je chyba v tom databazovem systemu, kde se Vam toto deje, a pak by bylo potreba rict jeho jmeno a verzi, aby to treba mohl nekdo zreprodukovat na jinem systemu. Rozhodne to pro uvedene vstupy neni standardni vystup. -- ------------------------------------------------------------------------ Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/ .project: Perl, DBI, Oracle, MySQL, auth. WWW servers, DBD::XBase. ------------------------------------------------------------------------ From Vaclav.Ovsik na i.cz Tue Oct 16 15:33:57 2001 From: Vaclav.Ovsik na i.cz (Vaclav Ovsik) Date: Tue, 16 Oct 2001 15:33:57 +0200 Subject: Objektovy PostgreSQL? In-Reply-To: <20011016134816.C19518@dat.cz>; from rk@dat.cz on Tue, Oct 16, 2001 at 01:48:16PM +0200 References: <3BCAA154.000001.08170@www2.email.atc> <20011015111745.B19715@zf.jcu.cz> <9qf8ci$391$1@meduna.org> <20011016104338.D8517@zf.jcu.cz> <20011016134816.C19518@dat.cz> Message-ID: <20011016153357.A19872@bobek.i.cz> On Tue, Oct 16, 2001 at 01:48:16PM +0200, Radek Kanovsky wrote: > Asi nejvetsim nedostatkem OODB je to, ze neexistuje rozuma open source > OODB. Vetsina dostupnych databazi je necim velmi specialni nebo je v > rozpracovanem stavu. Pokud by nekdo o nejake vedel, mohl by se tady > zminit. Pred casem, jsem tady brecel po necem jako OODB. V teto konferenci jsem dostal odkaz http://www.ispras.ru/~knizhnik/ Zkoumal jsem GOODS, ale uz asi pred rokem. Podle dokumentace to vypadalo namakle. Nicmene neodhodlal jsem se zacit do toho preklapet svuj projekt. Umi to krom toho ukladani objektu plno dalsich veci. Ovsem ve chvili, kdy bych s tim chtel nahradit RDBMS, musel bych si zase udelat nejake dotazovadlo (vyberova kriteria), abych dal moznost uzivateli nahore nejake vybery ... Trochu me zarazily definice trid, ktere jdou umistovat do toho systemu, ale uz nevim presne co ... IMHO budoucnost bude nejaky mix OODB a RDBMS. Mozna, ze zrovna to GOODS je nastartovane spravne. Nejsem ale velky teoretik. Zatim mam plno jine prace, ale hodlam se ke GOODS jeste vratit. -- Vaclav Ovsik email: Vaclav.Ovsik na i.cz ICZ a.s. phone: +420 19 7488511 fax: +420 19 7488506 From bcnvsn na microservice.club24.co.uk Tue Oct 16 21:09:55 2001 From: bcnvsn na microservice.club24.co.uk (bcnvsn na microservice.club24.co.uk) Date: 16 Oct 2001 19:09:55 GMT Subject: Advertise your services to ......... 9623 Message-ID: <3bcc8603$0$8512$ed9e5944@reading.news.pipex.net> 80 Million Fresh email addresses Available NOW with free Mass Mailer and other essential applications. Best prices around. Fantastic Special Offer For more info call UK- 0906 664 2021 All others- 00 44 906 664 2021 Select option 2 from menu when directed. Lines get busy at peak times - keep trying We accept all major credit cards - Delivery normaly 24hrs xekijqptwswvgiheygqzzubzvcfsljlywqupdqerqw From rk na dat.cz Wed Oct 17 10:00:15 2001 From: rk na dat.cz (Radek Kanovsky) Date: Wed, 17 Oct 2001 10:00:15 +0200 Subject: Objektovy PostgreSQL? In-Reply-To: <20011016143246.I8517@zf.jcu.cz> References: <3BCAA154.000001.08170@www2.email.atc> <20011015111745.B19715@zf.jcu.cz> <9qf8ci$391$1@meduna.org> <20011016104338.D8517@zf.jcu.cz> <20011016134816.C19518@dat.cz> <20011016143246.I8517@zf.jcu.cz> Message-ID: <20011017100015.D19518@dat.cz> On Tue, Oct 16, 2001 at 02:32:46PM +0200, Karel Zak wrote: > > se pouzivani indexu pro vyhledani provazanych objektu. OODB se velmi > > dobre hodi pro aplikace, ktere vyzaduji ukladani slozitych provazanych > > struktur, stromu, XML dokumentu (ktere jsou svou povahou stromy a velmi > > spatne se ukladaji do relacnich databazi) apod. > > Jenze relacni DB byla vytvorena prave pro nevhodnost stromu pro ukladani > urcitych typu dat (napr. IMS - information management system od IBM > z 60-tych let). Mezi hlavni nedostatky patril jediny existujici vztah > rodic<->dite (podobne viz. struktura XML), problematicnost vytvareni > vazeb mizi ruznymi urovnemi toho stromu a nasledne problem definovat > zakladni mnozinove operace nad daty atd. Vsechno todle prichod > relacnich DB vyresil. S pomoci referenci lze ale vytvorit jakoukoliv strukturu podobne jako s klasickymi pointery (i treba cyklickou). Jenom s tim by clovek ovsem nevystacil. Programator muze ukladat objekty do kontejneru (list, hash, btree, set, bag...), pricemz tento kontejner je datovy typ stejne jako integer nebo string a muze tedy byt atributem objektu. Pouziti mnoha mnozinovych operaci se lze v OODB vyhnout, protoze model je proste jiny. Ale i tak lze tyto operace provadet pomoci OQL stejne jako v SQL, kteremu je tento jazyk podobny. Toto vsecko je ale jenom teorie. Zatim jsem s zadnou poradnou OODB nedelal a spis testuju volne dostupne implementace. Osobne bych potreboval nejake teple misto pro svoje pythonovske objekty. Zatim jsem nic vhodneho nenasel. Zkousel jsem je ukladat do postgresu, ale neni to proste ono. Ikdyz ma postgres nejaka objektova rozsireni (jako dedicnost tabulek a jednoznacne OID zaznamu), jsou to porad jenom tabulky :-) Zdravi, Radek Kanovsky From rk na dat.cz Wed Oct 17 10:17:43 2001 From: rk na dat.cz (Radek Kanovsky) Date: Wed, 17 Oct 2001 10:17:43 +0200 Subject: Objektovy PostgreSQL? In-Reply-To: <20011016153357.A19872@bobek.i.cz> References: <3BCAA154.000001.08170@www2.email.atc> <20011015111745.B19715@zf.jcu.cz> <9qf8ci$391$1@meduna.org> <20011016104338.D8517@zf.jcu.cz> <20011016134816.C19518@dat.cz> <20011016153357.A19872@bobek.i.cz> Message-ID: <20011017101743.E19518@dat.cz> On Tue, Oct 16, 2001 at 03:33:57PM +0200, Vaclav Ovsik wrote: > Pred casem, jsem tady brecel po necem jako OODB. > V teto konferenci jsem dostal odkaz > > http://www.ispras.ru/~knizhnik/ > > Zkoumal jsem GOODS, ale uz asi pred rokem. Podle dokumentace > to vypadalo namakle. Nicmene neodhodlal jsem se zacit do toho > preklapet svuj projekt. > > Umi to krom toho ukladani objektu plno dalsich veci. > Ovsem ve chvili, kdy bych s tim chtel nahradit RDBMS, > musel bych si zase udelat nejake dotazovadlo (vyberova kriteria), > abych dal moznost uzivateli nahore nejake vybery ... > > Trochu me zarazily definice trid, ktere jdou umistovat do toho > systemu, ale uz nevim presne co ... Kdyz jsem to zkousel, tak defininovani nove tridy znamenalo vytvoreni jeji implementace v C++ a nasledna kompilace, coz mne nevyhovovalo. Ted vidim, ze je tam nova verze a nejake zmeny, tak se na to nekdy mrknu. > IMHO budoucnost bude nejaky mix OODB a RDBMS. Mozna, ze zrovna > to GOODS je nastartovane spravne. Nejsem ale velky teoretik. > Zatim mam plno jine prace, ale hodlam se ke GOODS jeste vratit. Doufam, ze v budoucnosti uz budou pocitace, kde se nebude nic tocit a vsechno bude v pameti a klasickym databazim a teto konferenci odzvoni. Kdyz se ovsem podivam na zpravy, tak mam obcas pocit, ze to mozna skonci ctveratymi hard disky :-) Zdravi, Radek Kaňovský From pepa.svob na worldonline.cz Wed Oct 17 13:16:03 2001 From: pepa.svob na worldonline.cz (Josef Svoboda) Date: Wed, 17 Oct 2001 13:16:03 +0200 Subject: Objektovy PostgreSQL? References: <3BCAA154.000001.08170@www2.email.atc> Message-ID: <9qjpc0$fsv$1@regina.gin.cz> Slysel jsem, ze databaze WinBase602 kombinuje prvky sitove (na ukazatelich zalozene) a relacni databaze. Ma s ni nekdo prakticke zkusenosti? Myslite si, ze je to dobry napad? Josef Svoboda From kas na informatics.muni.cz Fri Oct 19 10:09:58 2001 From: kas na informatics.muni.cz (Jan Kasprzak) Date: Fri, 19 Oct 2001 10:09:58 +0200 Subject: C, python, perl, ...? In-Reply-To: <20011015132834.B1071@lxserver.deltes.cz>; from skim@deltaes.cz on Mon, Oct 15, 2001 at 01:28:34PM +0200 References: <200110151038.MAA05373@p44u01.plz.pvt.cz> <20011015132834.B1071@lxserver.deltes.cz> Message-ID: <20011019100957.G14888@informatics.muni.cz> Michal Špaček wrote: : Zkousel jste nekdy mod-fastcgi? A porovnani s predchozima dvema? : Myslim, ze je to dalsi moznost a porad perl. FastCGI je vyhodne i z jinych duvodu - napriklad pokud mate mod_perl nebo PHP, tak se vam skript kompiluje pro kazdeho potomka Apache zvlast. Zatimco pri mod_fcgi se spusti jeden proces (nebo nekolik malo procesu), takze pri vyssi zatezi mate lepsi lokalitu cache a podobne. Navic FCGI proces[y] nemusi byt potomkem apache, ale vec spoustena uplne samostatne (a tedy s jinymi pravy, pod jinym uzivatelem, chroot()ovane a podobne). Velmi se mi libi to, ze se apache sam stara o spousteni/ukoncovani FCGI procesu v pripade potreby. Pokud mate velmi zatizeny webovsky server, kde se vase aplikace sklada z nekolika malo programu, je FCGI idealni. Pokud ovsem mate takovy web server, kde jsou stovky az tisice skriptu, je lepsi pouzit mod_perl. Jinak co se tyce programovani pro web, idealni mi prijde nejake paradigma, ktere umozni stejnym jazykem psat program, a stejny jazyk v omezene mire pouzit pro doplnovani udaju do sablon HTML stranek. Cili neco jako JSP+Javovske servlety, pripadne embedovany Perl + mod_perl, a podobne. A kdyz ten jazyk bude mozne uplatnit i jinde, tim lepe. -Y. -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ | The kernel is not there to cover up for usermode programmers inability to get things right. It has enough to do covering up for the hardware folk. (Alan Cox) From jchlebec na studiostyle.sk Sun Oct 21 20:05:54 2001 From: jchlebec na studiostyle.sk (Juraj Chlebec) Date: Sun, 21 Oct 2001 20:05:54 +0200 Subject: Cestina v psql pod Cygwin References: Message-ID: <9qv2o8$j5r$1@morticia.kit.vslib.cz> Presne tak - dovodom je ze v Cygwin nie su implementovane locales a v shelli (bash) sa preto diakritika nezobrazi. Cez ineho klienta (browser, pgAdmin) by to nemal byt problem... Akurat ze triedenie a funkcie zavisle od locales nebudu fungovat... Juraj Chlebec From Ales.Zika na pel.br.ds.mfcr.cz Mon Oct 22 06:21:27 2001 From: Ales.Zika na pel.br.ds.mfcr.cz (=?iso-8859-2?Q?=22Z=EDka_Ale=B9=2C_Ing=2E=22?=) Date: Mon, 22 Oct 2001 06:21:27 +0200 Subject: Cestina v psql pod Cygwin Message-ID: <30A3D33A0D99D4119CDD0060084676F61D2D00@fupelnt2.pel.br.ds.mfcr.cz> > Presne tak - dovodom je ze v Cygwin nie su implementovane > locales a v shelli > (bash) sa preto diakritika nezobrazi. Cez ineho klienta Ale to bohuzel tak asi uplne neni, protoze v bashi se po nastavení ruznych set meta-convert off a podobne cestina normalne zobrazuje, sice v CP 1250, ale zobrazuje. Ales Zika Pelhrimov e-mail: Ales.Zika na pel.br.ds.mfcr.cz Ales.Zika na seznam.cz SMS: Ales.Zika na sms.underground.cz From sorm na pef.mendelu.cz Mon Oct 22 20:10:52 2001 From: sorm na pef.mendelu.cz (Milan =?iso-8859-2?Q?=A9orm?=) Date: Mon, 22 Oct 2001 20:10:52 +0200 Subject: Oracle a velky temporary tabelspace Message-ID: <20011022201052.H23969@akela.mendelu.cz> Mam temporary tablespace (a tudiz i datafile) velky 16 GB, coz mi trosicku vadi, neb na 30 GB disku je to skutecne hodne (driv nez jsem stihl prepnout Unlimited, ktere je po instalci 9i nastaveno, tak jsem si tech 16 GB zaplacal). Jak temporary tablespace zmensit ? Uz jsem si zalozil jinej mensi na 4 GB a prepnul ho na default, ale co ted s tim puvodnim ? Jen tak smazat to asi nepujde ? Diky za radu. --milan From roubm9am na barbora.ms.mff.cuni.cz Mon Oct 22 20:42:51 2001 From: roubm9am na barbora.ms.mff.cuni.cz (Milan Roubal) Date: Mon, 22 Oct 2001 20:42:51 +0200 Subject: Oracle a velky temporary tabelspace References: <20011022201052.H23969@akela.mendelu.cz> Message-ID: <00d801c15b29$5ac744c0$561b71c3@krlis> postupne urezavat a jak budou z nej casem odpadavat data tak se tak do mesice dostane do rozumne meze.... Zdravi Milan Roubal roubm9am na barbora.ms.mff.cuni.cz ----- Original Message ----- From: "Milan Šorm" To: Sent: Monday, October 22, 2001 8:10 PM Subject: Oracle a velky temporary tabelspace > Mam temporary tablespace (a tudiz i datafile) velky 16 GB, coz mi trosicku > vadi, neb na 30 GB disku je to skutecne hodne (driv nez jsem stihl prepnout > Unlimited, ktere je po instalci 9i nastaveno, tak jsem si tech 16 GB > zaplacal). Jak temporary tablespace zmensit ? Uz jsem si zalozil jinej mensi > na 4 GB a prepnul ho na default, ale co ted s tim puvodnim ? Jen tak smazat > to asi nepujde ? > > Diky za radu. > > --milan From sherry na pikebo.cz Tue Oct 23 08:20:06 2001 From: sherry na pikebo.cz (Jan Serak) Date: Tue, 23 Oct 2001 08:20:06 +0200 Subject: Oracle a velky temporary tabelspace References: <20011022201052.H23969@akela.mendelu.cz> <00d801c15b29$5ac744c0$561b71c3@krlis> Message-ID: <3BD50C16.7455A8C6@pikebo.cz> Milan Roubal wrote: > > postupne urezavat a jak budou z nej casem odpadavat data tak se tak > do mesice dostane do rozumne meze.... A co je spatneho na: drop tablespace create tablespace Doufam, ze jako temporary neobsahuje persistentni objekty ;-) Jan Serak From xvalous na pluto.pslib.cz Tue Oct 23 17:37:12 2001 From: xvalous na pluto.pslib.cz (Tomas Valousek) Date: Tue, 23 Oct 2001 17:37:12 +0200 (CEST) Subject: psql+large objects+perl Message-ID: Dobry den, zrejmne uz toho mam dost, ale proste nemuzu prijit na to, jak v perlu pomoci modulu Pg naimportovat lo do databaze. Cetl jsem man Pg, ale nejsem schopen pochopit, jak s lo pracovat. Myslel jsem si, ze bude fungovat toto, ale to nefunguje. use Pg; my $pripojeni = Pg::connectdb("dbname=valy"); my $query4 = $pripojeni->exec("INSERT INTO dc VALUES ($notmpx,$sec,lo_import(\'/etc/motd\'))"); V man Pg pisou: $lobjId = $conn->lo_import($filename) Tady ale nachapu, jak mam naspecifikovat, do jake tabulky a do jakeho "sloupce" se ma lo vlozit. Stacilo by mi nejake nakopnuti nebo nejaky priklad. Diky, Tomas Valousek -- Tomas -VALY- Valousek web design, internet projects, linux etc.. email: tomas na valousek.cz www: http://www.spsselib.hiedu.cz/~xvalous (~=ALT+126) From xvalous na pluto.pslib.cz Tue Oct 23 20:03:02 2001 From: xvalous na pluto.pslib.cz (Tomas Valousek) Date: Tue, 23 Oct 2001 20:03:02 +0200 (CEST) Subject: psql+large objects+perl In-Reply-To: Message-ID: On Tue, 23 Oct 2001, Tomas Valousek wrote: > Dobry den, > zrejmne uz toho mam dost, ale proste nemuzu prijit na to, jak v > perlu pomoci modulu Pg naimportovat lo do databaze. Cetl jsem > man Pg, ale nejsem schopen pochopit, jak s lo pracovat. > > Myslel jsem si, ze bude fungovat toto, ale to nefunguje. > use Pg; > my $pripojeni = Pg::connectdb("dbname=valy"); > my $query4 = $pripojeni->exec("INSERT INTO dc VALUES > ($notmpx,$sec,lo_import(\'/etc/motd\'))"); Tak uz si muzu odpovedet sam. Uz sem prisel na to, proc mi to nefungovalo. V psql jsem to zkousel jako uvivatel valy, ktezto v perlu jako uzivatel root. A protoze jsem magor a nenachel jsem si vypisovat zadne errory, tak jsem na to prisel az kdyz jsem se prihlasil jako root do psql a tam mi to napsalo: ERROR: You must have Postgres superuser privilege to use server-side lo_import(). Anyone can use the client-side lo_import() provided by libpq. No nic... priste snad budu otravovat kvuli realnemu problemu :-) Ted du spat, protoze dneska to uz nema zadnej smysl cokoliv delat... Jeste jednou sorry, s pozdravem Tomas Valousek -- Tomas -VALY- Valousek web design, internet projects, linux etc.. email: tomas na valousek.cz www: http://www.spsselib.hiedu.cz/~xvalous (~=ALT+126) From yeti na seznam.cz Wed Oct 24 00:03:48 2001 From: yeti na seznam.cz (mlekar dan) Date: Wed, 24 Oct 2001 00:03:48 +0200 Subject: =?utf-8?q?Fulltextov=C3=BD=20index=20na?= MySQL In-Reply-To: <9qeee7$4gv$1@morticia.kit.vslib.cz> References: <9qeee7$4gv$1@morticia.kit.vslib.cz> Message-ID: <01102400034800.10580@yeti> Mam 3.23.39, tabulku s 1500 zaznamy, fulltext index na varchar a text. Bohuzel se slovem vlažný jsem na tom stejne. Zkousel jsem ruzne dalsi kombinace vlazný (Ok) a vlažny (Ko). Pismenem 'z' uprostred to asi nebude, nežerte bere. Asi vlazny nema vysokou indexovaci hodnotu :-| Dne po 15. říjen 2001 12:40 jste napsal(a): > Mám vytvo?en fulltextový index a záznam který tam 100% je. Bohu?el p?i > zadání Match .... Against to ten záznam nenajde. Nevíte v ?em m??e být > chyba ? to hledané slovo je 'vla?ný'. slovo '?elezný' to kup?íkladu najde. From yeti na seznam.cz Wed Oct 24 00:22:33 2001 From: yeti na seznam.cz (mlekar dan) Date: Wed, 24 Oct 2001 00:22:33 +0200 Subject: =?utf-8?q?Fulltextov=C3=BD=20index=20na?= MySQL In-Reply-To: <9qeee7$4gv$1@morticia.kit.vslib.cz> References: <9qeee7$4gv$1@morticia.kit.vslib.cz> Message-ID: <01102400223302.10580@yeti> Uz to asi mam! Co ti vypisuje mysql> show variables like "char%set"; ??? defaultni --latin1-- ? tak si nastav --czech-- ! (mam na desktopu zkompilovane MySQL 3.23.43 primo s --with-charset=czech a na nem to funguje Ok) > Mám vytvo?en fulltextový index a záznam který tam 100% je. Bohu?el p?i > zadání Match .... Against to ten záznam nenajde. Nevíte v ?em m??e být > chyba ? to hledané slovo je 'vla?ný'. slovo '?elezný' to kup?íkladu najde. From sorm na pef.mendelu.cz Thu Oct 25 20:56:38 2001 From: sorm na pef.mendelu.cz (Milan =?iso-8859-2?Q?=A9orm?=) Date: Thu, 25 Oct 2001 20:56:38 +0200 Subject: Oracle a velky temporary tabelspace In-Reply-To: <00d801c15b29$5ac744c0$561b71c3@krlis> References: <20011022201052.H23969@akela.mendelu.cz> <00d801c15b29$5ac744c0$561b71c3@krlis> Message-ID: <20011025205638.E11931@akela.mendelu.cz> Mon, Oct 22, 2001 ve 08:42:51PM +0200 Milan Roubal napsal(a): # postupne urezavat a jak budou z nej casem odpadavat data tak se tak # do mesice dostane do rozumne meze.... nezmensuje se vubec uz cely mesic. zapomnel jsem rict ze jde o 9i a tam jsou jeste nejake musky. From sorm na pef.mendelu.cz Thu Oct 25 20:57:27 2001 From: sorm na pef.mendelu.cz (Milan =?iso-8859-2?Q?=A9orm?=) Date: Thu, 25 Oct 2001 20:57:27 +0200 Subject: Oracle a velky temporary tabelspace In-Reply-To: <3BD50C16.7455A8C6@pikebo.cz> References: <20011022201052.H23969@akela.mendelu.cz> <00d801c15b29$5ac744c0$561b71c3@krlis> <3BD50C16.7455A8C6@pikebo.cz> Message-ID: <20011025205727.F11931@akela.mendelu.cz> Tue, Oct 23, 2001 ve 08:20:06AM +0200 Jan Serak napsal(a): # Milan Roubal wrote: # > # > postupne urezavat a jak budou z nej casem odpadavat data tak se tak # > do mesice dostane do rozumne meze.... # # A co je spatneho na: # # drop tablespace # create tablespace # # Doufam, ze jako temporary neobsahuje persistentni objekty ;-) # # # Jan Serak pomohlo to. akorat nechapu, proc si ty objekty po case neprepisuje. k cemu je tam skladuje ? docasne chapu ze k vypoctu nekterych typu SLECTu, ale trvale ? --milan From sherry na pikebo.cz Fri Oct 26 13:10:55 2001 From: sherry na pikebo.cz (Jan Serak) Date: Fri, 26 Oct 2001 13:10:55 +0200 Subject: Oracle a velky temporary tabelspace References: <20011022201052.H23969@akela.mendelu.cz> <00d801c15b29$5ac744c0$561b71c3@krlis> <3BD50C16.7455A8C6@pikebo.cz> <20011025205727.F11931@akela.mendelu.cz> Message-ID: <3BD944BF.CFA19EAF@pikebo.cz> Milan Šorm wrote: > pomohlo to. akorat nechapu, proc si ty objekty po case neprepisuje. k cemu > je tam skladuje ? docasne chapu ze k vypoctu nekterych typu SLECTu, ale > trvale ? Pro nektere operace (order by, create index,...) Oracle rve docasna data do temporary segmentu, ktere vidi jen ta session, ktera je vytvorila. Jakmile prestanou byt k pouziti (shora omezeno existenci session), Oracle je zrusi. Vas problem byl jinde. Mel jste tablespace, ktery byl pouzivan pro temporary segmenty, nastaven na automaticke zvetsovani podle potreby. O smrstovani takoveho tablespace podle potreby nic nevim, takze pred- pokladam, ze po uvolneni temporary segmentu zustal tablespace v takove velikosti (suma zabraneho mista na disku), do jake se mu podarilo vyrust, akorat byl temer prazdny. Jan Serak From adelton na informatics.muni.cz Fri Oct 26 13:11:17 2001 From: adelton na informatics.muni.cz (Honza Pazdziora) Date: Fri, 26 Oct 2001 13:11:17 +0200 Subject: Oracle a velky temporary tabelspace In-Reply-To: <3BD944BF.CFA19EAF@pikebo.cz>; from sherry@pikebo.cz on Fri, Oct 26, 2001 at 01:10:55PM +0200 References: <20011022201052.H23969@akela.mendelu.cz> <00d801c15b29$5ac744c0$561b71c3@krlis> <3BD50C16.7455A8C6@pikebo.cz> <20011025205727.F11931@akela.mendelu.cz> <3BD944BF.CFA19EAF@pikebo.cz> Message-ID: <20011026131117.M18593@anxur.fi.muni.cz> On Fri, Oct 26, 2001 at 01:10:55PM +0200, Jan Serak wrote: > > Vas problem byl jinde. Mel jste tablespace, ktery byl pouzivan pro > temporary segmenty, nastaven na automaticke zvetsovani podle potreby. > O smrstovani takoveho tablespace podle potreby nic nevim, takze pred- > pokladam, ze po uvolneni temporary segmentu zustal tablespace v takove > velikosti (suma zabraneho mista na disku), do jake se mu podarilo > vyrust, akorat byl temer prazdny. No, tam slo pry o to, ze i kdyz se na to clovek dival pres OEM, tak ten tablespace byl zobrazen plny a ani resize nepomohlo (predpokladam, ze hlasilo, ze jsou bloky za pozadovanym koncem). -- ------------------------------------------------------------------------ Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/ .project: Perl, DBI, Oracle, MySQL, auth. WWW servers, DBD::XBase. ------------------------------------------------------------------------ From sorm na pef.mendelu.cz Sat Oct 27 13:32:31 2001 From: sorm na pef.mendelu.cz (Milan =?iso-8859-2?Q?=A9orm?=) Date: Sat, 27 Oct 2001 13:32:31 +0200 Subject: Oracle a velky temporary tabelspace In-Reply-To: <20011026131117.M18593@anxur.fi.muni.cz> References: <20011022201052.H23969@akela.mendelu.cz> <00d801c15b29$5ac744c0$561b71c3@krlis> <3BD50C16.7455A8C6@pikebo.cz> <20011025205727.F11931@akela.mendelu.cz> <3BD944BF.CFA19EAF@pikebo.cz> <20011026131117.M18593@anxur.fi.muni.cz> Message-ID: <20011027133231.A21545@akela.mendelu.cz> Fri, Oct 26, 2001 ve 01:11:17PM +0200 Honza Pazdziora napsal(a): # On Fri, Oct 26, 2001 at 01:10:55PM +0200, Jan Serak wrote: # > # > Vas problem byl jinde. Mel jste tablespace, ktery byl pouzivan pro # > temporary segmenty, nastaven na automaticke zvetsovani podle potreby. # > O smrstovani takoveho tablespace podle potreby nic nevim, takze pred- # > pokladam, ze po uvolneni temporary segmentu zustal tablespace v takove # > velikosti (suma zabraneho mista na disku), do jake se mu podarilo # > vyrust, akorat byl temer prazdny. # # No, tam slo pry o to, ze i kdyz se na to clovek dival pres OEM, tak # ten tablespace byl zobrazen plny a ani resize nepomohlo (predpokladam, # ze hlasilo, ze jsou bloky za pozadovanym koncem). presne jak rika adelton. ale drop a create nakonec zabralo a nic se nestalo (tedy neprisel jsem o zadna data nebo alespon doufam :)) From kleps na avonet.cz Tue Oct 30 16:13:58 2001 From: kleps na avonet.cz (Otakar Kleps) Date: Tue, 30 Oct 2001 16:13:58 +0100 Subject: Problemy s REFERENCES a RULE u Postgresu Message-ID: <3BDEC3B6.4020507@avonet.cz> Problem se tyka Postgresu 7.1.3. Mam napr. tabulku: CREATE TABLE tbl_test( id INTEGERE PRIMARY KEY, ... _parent INTEGER REFERENCES tbl_test ON DELETE CASCADE, ... ) Dale potrebuji provest jednoduchy SQL dotaz po smazani zaznamu z tabulky tbl_test. K tomuto ucelu definuji RULE na event ON DELETE: CREATE RULE rule_test AS ON DELETE TO tbl_test DO INSERT INTO ... atd... ; Vsechno funguje v poradku az do chvile, kdy se zacne provadet 'REFERENCES tbl_text ON DELETE CASCADE' - RULE se spusti pouze u radku, ktery mazu dotazem DELETE, ovsem uz se nespousti v okamziku, kdy v mazani pokracuje ona 'vazba' 'REFERENCES tbl_text ON DELETE CASCADE'. Kombinace trigeru a funkce mi prijde jako zbytecny luxus(a ani nevim, zda by to v uvedenem pripade fungovalo). Co stim? Dekuji Ota Kleps From fc282 na email.com Wed Oct 31 14:05:34 2001 From: fc282 na email.com (Cyril Franko) Date: Wed, 31 Oct 2001 14:05:34 +0100 Subject: prevod text na inet References: <3BDEC3B6.4020507@avonet.cz> Message-ID: <009701c1620c$bb9ea330$10c03ac1@euroweb.sk> zdravim, poradi niekto ako previest typ text na inet v postgre ? v systemovych funkciach som taku funkciu nenasiel ..... nap. mam tabulku create table test (ip text); a v nej riadky ip 193.128.12.2 a potrebujem ip skonvertovat na typ inet. select ip::inet from test nezbehne a ani select inet(ip) from test ma niekto riesenie ? cYro From chocholaty na gncz.cz Wed Oct 31 14:05:35 2001 From: chocholaty na gncz.cz (Libor Chocholaty) Date: Wed, 31 Oct 2001 14:05:35 +0100 Subject: Interbase + cestina v ISO-8859-2 Message-ID: <3BDFF71F.8D1A7841@gncz.cz> Dobry den, povedlo se vam rozchodit tuto kombinaci na Linuxove Interbase? V manualu se pise, ze podporovane kodovani cestiny je windows-1250. Jak resite tenhle problem? Diky, Libor