Stepan
xko...@vse.cz
Pokud to bezi nad jednim databazovym strojem, tak si myslim, ze z
hlediska vykonu je to jedno (nebo spise rozdily budou pranepatrne).
Ovsem az se k aplikaci budete za nejaky cas vracet nebo dale rozvijet,
urcite Vam udela radost logicke usporadani a prehlednost. Ovsem zalezi
spise na aplikaci a na Vasem vkusu...
--
Vladimír Náprstek e-mail: vladimir...@prodeco.cz
mam takovy problem a nevim si s nim rady.
Mam tabulku
categories:
id int(10) auto_increment
parent int(10)
name char(50)
kde pole "parent" vzdy ukazuje na "id" nadrizeneho zaznamu ve stejne tabulce
a ted na svuj nadrizeny zaznam a ten na svuj az na ten ktery nema nic
nadrizeneneho.
Potrebuji polozit dotaz, ktery mi vrati celou tuto posloupnost rodicu a
jejich potomku. V podstate jde o problem jaky resi kazdy katalogovy seznam,
napr. www.seznam.cz .
Muze mi nekdo pomoci? Jde to vubec?
P.S. Pouzivam MySQL.
-------------------------------
Tomas Kouba
mailto:to...@neo.cz
Pokud je my znamo tak mysql nic takoveho neumy musite zkratka rekurzivne
prochazet celej seznam
vzdycky musite vyhledat potomky , vypsat je a potomkum vyhledat jejich
potomky....
Stromovy prochazeni snad udajne umy ORACLE ale nikdy jsem stim nedelal.
S pozdravem Jan Vrana
--
PS: Doufam, ze jste se pobavili nad moji gramatikou, ale nekamenujte me, ja
lip psat neumim :-))
"Kouba Tomas" <to...@neo.cz> píąe v diskusním příspěvku
news:NCBBJLACFPFKJGDJK...@neo.cz...
V Oracle lze pouzit klauzuli CONNECT BY a START WITH pro vytvoreni
hierarchickeho seznamu. V MySQL nevim zda neco podobneho existuje.
Lukas
Toto resi tzv. hierarchicke dotazy, ktere v soucasnosti MySQL neumi, ale
podle "Things that must be done in the real near future"
(http://www.mysql.com/doc/T/O/TODO_future.html) je bod: Oracle like
CONNECT BY PRIOR ... to search hierarchy structures.
A jit na to jen s dotazem asi nepujde. Budete si muset stvorit
proceduru, ktera bude rekurzivne (nebo opakovane) projizdet data a
vracet rodice od daneho potomka...
Klasicky strom reprezentovany relaci v relacnim databazovem modelu.
Klasicky
model relacni databaze neni uplny, nebot nedefinuje rekurzi. Proto ani
klasicke
SQL neumoznuje takovy "pruchod" tabulkou.
>
> Potrebuji polozit dotaz, ktery mi vrati celou tuto posloupnost rodicu a
> jejich potomku. V podstate jde o problem jaky resi kazdy katalogovy seznam,
> napr. www.seznam.cz .
>
> Muze mi nekdo pomoci? Jde to vubec?
>
> P.S. Pouzivam MySQL.
Vyrobci SQL enginu jakyms takyms zpusobem shora popsany nedostatek
"napravuji", ale
dela to kazdy jinak. Sjednoceni patrne v nedohlednu. MySQL to IMHO
neresi vubec,
takze Vam nezbyva, nez to oprogramovat do iterace v nejakem
proceduralnim prostredi
(PHP, Perl,...) nad MySQL.
No pokud je databaze navrzena takto, pak uplne jednoduse to nepujde,
prvni dotaz by mel znit select * from table where parent=0 (null ci jiny
identifikator, ze jde o Root). Tim mame main kategorie no a nyni select
* from table where parent = main (kolik main kategorii, tolik techto
dotazu) atd...
> P.S. Pouzivam MySQL.
No a co? SQL jazyk tu neni quli serverum, ale servery tu jsou quli SQL
jazyku.
-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft) FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet Anenska 11, 602 00 Brno
E-mail: mailto:Jano...@FoNet.Cz Tel.: +420 5 4324 4749
SMS: mailto:P.Jan...@SMS.Paegas.Cz Fax.: +420 5 4324 4751
WWW: http://WWW.FoNet.Cz/ E-mail: mailto:In...@FoNet.Cz
-----------------------------------------------------------------------
> id int(10) auto_increment
> parent int(10)
> name char(50)
..
>
> Potrebuji polozit dotaz, ktery mi vrati celou tuto posloupnost rodicu a
> jejich potomku. V podstate jde o problem jaky resi kazdy katalogovy seznam,
> napr. www.seznam.cz .
>
..
> P.S. Pouzivam MySQL.
Dobry den,
pokud mate takto nadefinovanou tabulku, pak se domnivam ze budete vec
muset resit na aplikacni urovni, t.j. udelat si treba nejakou funkci ktera
bude rekurzivne volat sama sebe a SELECTovat vzdy parent kategorii, dokud
se nedostane do rootu a pote vam vrati celou cestu vsemi kategoriemi.
S MySQL to 1 SELECTem nezvladnete. Pokud to nebude hodne navstevovany sajt,
myslim ze to je pouzitelne.
S pozdravem
--
Jan Bernard, Network Media Service s.r.o., http://www.nms.cz/
Radlicka 2, 150 00, Praha 5, tel. 57313110, fax. 51564618
Myslim, ze zrovna v teto veci je to dost dulezita informace. Pokud by
slo
napr. o Oracle, lze to jedinym selectem :-)
Jan Serak
> podle "Things that must be done in the real near future"
> (http://www.mysql.com/doc/T/O/TODO_future.html) je bod: Oracle like
> CONNECT BY PRIOR ... to search hierarchy structures.
hoho. dival jsem se do tohoto seznamu chystanych ficur a vypada to velice
slibne. Mate nekdo nejaky odhad za jak dlouho se da cekat, ze
v tomto dokumentu slibovana vylepseni se dostanou do nejaky bety a za jak
dlouho do stabilni verze?
diky
btw mate nekdo zkusenosti s full-text_ovym vyhledavanim v mysql?
co jsem zkousel tak mi prijde vysoce experimentalni (3.23.37.).
nejak se mi nezda to indexovani. casto to nevraci spravne.
slova typu mysql ale indexuje perfektne, to ano ;)
Mrzi mne, ze lide si stale nezvykli na to, ze aplikace nemusi vzdy
bezet pouze pod jednim software (zejmena pod software jednoho vendora =>
proprietalni a neprenositelna (casto mizerne dokumentovana) rozsireni
standardu) a tak ze svych zadavatelu se jiz apriori chystaji tahat dalsi
penize...:-(
Skutecne, proc se zadavatelum (zakaznikum) na zacatku rikaji
marketingove keci a ne pravda a realna skutecnost (s hlavnimi aspekty i
z financniho hlediska) jsem do dneska nepochopil.
dalsi srovnani je na strankach mysql.
http://www.mysql.com/information/crash-me.php
http://www.mysql.com/information/benchmarks.html
nicmene jsem srovnaval mysql, pgsql 7, interbase 6, ms sql 8, ale je to prilis dlouhe psani, pokud chces vedet neco konkretniho...
jinak te asi zajima mysql api, viz dokumentace.
Nepachat workaroundy neceho, co prostredi podporuje, jeste neznamena
vyrabet pupecni snuru s timto prostredim. Jinymi slovy z A => B
rozhodne nevyplyva A <=> B, coz mnozi lide stale nechapou a me to velmi
mrzi.
>
> Skutecne, proc se zadavatelum (zakaznikum) na zacatku rikaji
> marketingove keci a ne pravda a realna skutecnost (s hlavnimi aspekty i
> z financniho hlediska) jsem do dneska nepochopil.
To jsem radeji vubec nepochopil. Nemusi se mi libit, ze kampelicka, do
niz
jsem nastrkal sve zivotni uspory, nesplnila sve sliby vysokych vynosu,
a pritom me svou marketingovou propagandou presvedcila, abych se stal
jejim
klientem. Ale proc by to melo zajimat ucastniky data...@linux.cz?
Jan Serak
dekuji vsem za zajem i kdyz to dobre nenapadlo a jednoduchy zpusob zrejme
neexistuje. Jak by jste mi prosim navrhli zmenit strukturu tabulky, aby
davala stejny vysledek a stacilo pouzit jeden SQL dotaz?
-------------------------------
Tomas Kouba
mailto:to...@neo.cz
> Kouba Tomas wrote:
Obavam se, ze to nepujde. Resp. muzete si rict, ze dana struktura ma dve
(tri, ctyri...) urovne (a nikdy jinak) a pak udelat pro kazdou uroven
jednu tabulku a zkusit to pres nejakou variantu join spojeni. Tak ale
dostanete pro kazdou uroven jiny dotaz. Predem rikam, ze je to hnus...
Navhrhuji Vam - jdete do programovani. Myslim, ze jedna smycka by to
mohla spravit.
>Krasny den,
>mel bych takovy teoreticky dotaz. Je lepsi (z hlediska rychlosti zpracovani
>dat) mit jednu databazi o nekolika spolu nesouvisejicich tabulkach, nebo
>tabulky poskladat do nekolika databazi???
Bacha třeba na tohle:
Jak jsem slyšel tak u Oracle platí že jedna databáze = jedna instance
databázového stroje => nároky na paměť.
(bez záruky)
--
Jiří Lisický ČD KMŽP Olomouc
e-mail: lis...@datis.cdrail.cz Vídeňská 15
phone: +420-068-472-2272 Olomouc, Czech Republic
>>> čeština ISO-8859-2 Compatible <<<
Asi si nerozumime, workaround neceho, co je normovane rozhodne nehodlam
delat... to co popisujete Vy je proprietalni rozsireni ANSI SQL 92
(pripadne navrhu SQL98) implementovane pouze a jen Oraclem... chcete-li
mit na poli SQL databazi uplne stejny bordel jako na poli HTML
prohlizecu, vesele v tomto trendu pokracujte... - tim vsak nerikam, ze
MS IE pro IS ci Oracle pro IS neni dobra varianta, rozhodne to vsak neni
dobra varianta pro nahled na obecne reseni urciteho problemu.
> > Skutecne, proc se zadavatelum (zakaznikum) na zacatku rikaji
> > marketingove keci a ne pravda a realna skutecnost (s hlavnimi aspekty i
> > z financniho hlediska) jsem do dneska nepochopil.
>
> To jsem radeji vubec nepochopil. Nemusi se mi libit, ze kampelicka, do
> niz
> jsem nastrkal sve zivotni uspory, nesplnila sve sliby vysokych vynosu,
> a pritom me svou marketingovou propagandou presvedcila, abych se stal
> jejim
> klientem. Ale proc by to melo zajimat ucastniky data...@linux.cz?
Co sem proboha pletete kampelicky? Jak to s tim souvisi, mluvim o tom,
ze kdyz zanalyzuji problem urcitym zpusobem, je dobre sdelit aspekty
zadavateli, TEN a ne ja coby dodavatel se mam rozhodovat o tom, do
jakeho datastore strci penize a na kterem zalozi svuj projekt... - a
pripadne jako jsou interoperabilni moznosti... pravda, pred jeste 5 lety
by se mi s timto pristupem mnoho lidi vysmalo, stejne jako se 'kazdy'
smal Linuxu, nastesti je dneska situace jina a zakaznika tento pristup
zacina silne zajimat...
IMHO nelze, SQL je prevazne o relacich, proto relacni databaze, ackoli
se z toho nekolik vyrobcu snazi delat i neco vice, bohuzel z
principielniho hlediska to vic byt nemuze, jeste ze mame matematicky
zaklad, kterym to lze dokazat (ten dukaz vsak nechtejte ode mne,
algebristi by Vam ho smahem vytahli).
Nekdy drive se to tu jiz debatovalo -- tehda jsem nadhodil sice funkcni,
ale ne dobre reseni pomoci retezcu ktere v sobe nesou ten strom (01.01.05).
Jak tu zaznelo tak to asi v soucasne dobe resi jen Oracle a obavam se,
ze to stejne vnitrne bude vice selectu...
Otazkou je proc na to pouzivat relacni DB a ne neco co je vice "stromove"
(ldap?).
Pro PostgreSQL se to pokousel resit projekt Opeacs, tady jsou nejake
odkazy:
http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0000eC&topic_id=11&
topic=+OpenACS
http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0000j6&topic_id=12&
topic=OpenACS%204%2e0%20Design
IMHO zadani tohoto ukolu jde mimo SQL, pokud by to melo byt to primarni co
by dotycny nastroj delal, tak by stalo za to se podivat nekam jinam (nebo
si to naprogramovat:-).
Karel
--
Karel Zak <za...@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
Mozna jsem to nenapsal dost jasne. Neni to problem definice tabulky, ale
problem neexistence REKURZE v SQL, kterou pro jakykoli pruchod jakymkoli
stromem proste potrebujete (maximalne ji muzete nahradit iteraci, ale to
mate taky smulu). A plati to pro _jakoukoli_ rekurzivni strukturu, at je
to strom, seznam, graf, cokoli.
Jan Serak
Proc vam vadi rozsireni SQL standardu firmou Oracle ? Standard jazyka SQL by
mel byt podmnozinou konkretni implementace. To si myslim Oracle vcelku
splnuje. Pokud nekomu vadi rozsireni (nevim absolutne proc ?) a zajima ho
hlavne prenositelnost databaze (resp. SQL dotazu a nevim ceho jeste..), tak
tyto rozsireni nemusi POUZIVAT !!!
Pokud pisu konkretni aplikaci na zakazku pro jednoho zakaznika (a vim, ze ji
znovu asi jinam neprodam), tak se nebudu drbat s tim jak vytvorit strom
pomoci pochybnych procedur (ktery beze zmeny kodu navic na jinym SQL enginu
stejne asi fungovat nebudou) a v klidku pouziju CONNECT BY.
Lukas
Ahoj,
zalezi co se rozumi pojmem databaze ? Na jednom stroji muze bezet vice
instanci (nekdo to pouziva - nekdo ne a ma jenom 1 instanci). V jedne
instanci muze byt libovolny pocet uzivatelu (schemat ?), tablespacu, ORA
datovych souboru atd.
Lukas
Souhlasim.
> workaround neceho, co je normovane rozhodne nehodlam
> delat...
Taky souhlasim.
> to co popisujete Vy je proprietalni rozsireni ANSI SQL 92
> (pripadne navrhu SQL98) implementovane pouze a jen Oraclem...
Opet souhlasim. (fakt si nerozumime? ;-)
> chcete-li
> mit na poli SQL databazi uplne stejny bordel jako na poli HTML
> prohlizecu, vesele v tomto trendu pokracujte
Rozhodne se mi nelibi, ze Oracle tim svym START WITH a CONNECT BY
znecistili SQL, meli to dat do doplnku SQL v ramci DML. Takze
vlastne zase souhlasim =:-0
> ... - tim vsak nerikam, ze
> MS IE pro IS ci Oracle pro IS neni dobra varianta, rozhodne to vsak neni
> dobra varianta pro nahled na obecne reseni urciteho problemu.
Uz vim, proc si nerozumime. Pan Kouba (doufam, ze mi pamet slouzi
a ze to nepletu) pise vec, ktera si necini narok byt obecnym
resenim rekurzivniho pruchodu stromovou strukturou v relacni databazi.
Pokud chce mit svoji aplikaci portabilni, neni duvod to oprogramovat
tak, aby se v pripade behu na Oracle pouzilo jeho rozsireni a v pripade
MySQL a jinych kod, ktery to proleze na urovni aplikace.
>
> Co sem proboha pletete kampelicky? Jak to s tim souvisi
Souvisi: kecy pouzivane marketingem jsou v tomto listu off-topic
stejne jako kampelicky.
---------------------------- O F F T O P I C --------------
> , mluvim o tom,
> ze kdyz zanalyzuji problem urcitym zpusobem, je dobre sdelit aspekty
> zadavateli, TEN a ne ja coby dodavatel se mam rozhodovat o tom, do
> jakeho datastore strci penize a na kterem zalozi svuj projekt...
Hmmmm, hezka teorie, i ja bych to bral vsema deseti, a to jsem se
na strane zadavatele jeste nevyskytl. Bohuzel, praxe, alespon v Cesku,
je takova, ze zadavatel se bud tohoto rozhodovani predem vzda, nebo
stanoveni konkretni platformy je primo v jeho zadani (i kdyz je to
mnohdy z realizacniho hlediska naprosta blbost) nebo je schopen
rozhodovat
jen na zaklade velmi plitkych informaci, ktere takove detaily
nepostihnou,
nebot podrobnejsi (a tim padem delsi) rozbory odmita studovat.
Za svuj profesionalni zivot v komercni sfere jsem se jeste nesetkal
s zadnym dalsim pristupem. Je to k placi, ale ze sve pozice to nejsem
schopen zmenit.
Klidne si o tom muzeme povidat dal, ale nejlepe mimo tento list.
Jan Serak
- a
> pripadne jako jsou interoperabilni moznosti... pravda, pred jeste 5 lety
> by se mi s timto pristupem mnoho lidi vysmalo, stejne jako se 'kazdy'
> smal Linuxu, nastesti je dneska situace jina a zakaznika tento pristup
> zacina silne zajimat...
>
> -----------------------------------------------------------------------
> Ing. Pavel Janousek (PaJaSoft) FoNet, spol. s r. o.
> Vyvoj software, Intranet / Internet Anenska 11, 602 00 Brno
> E-mail: mailto:Jano...@FoNet.Cz Tel.: +420 5 4324 4749
> SMS: mailto:P.Jan...@SMS.Paegas.Cz Fax.: +420 5 4324 4751
> WWW: http://WWW.FoNet.Cz/ E-mail: mailto:In...@FoNet.Cz
> -----------------------------------------------------------------------
--
Mgr. Jan Šerák PIKE ELECTRONIC, s. r. o.
mailto:jan....@pikebo.cz IBC, Příkop 6
http://www.pikebo.cz Brno, 602 00
phone:+420-5-45175879 Czech republic, Europe
SMS: mailto:sherry.@sms.paegas.cz
veřejný klíč: pgpk -a hkp://pks.pgp.cz/jan....@pikebo.cz
Fingerprint20 = 2FDB FDB0 2299 DA21 289F 6656 67C4 D4CC 1C82 60FA
Luck, that's when preparation and opportunity meet.
-- P.E. Trudeau
SQL99 definuje "recursive union", coz umozni "pruchod stromem" v jednom
SELECTu. Pokud jsem to ovsem dobre pochopil. PostgreSQL to ma v TODO
jako "exotic feature". Jinde to nebude asi o nic lepsi.
Dan
Na rozsireni nic, firma Oracle ma svate pravo vyvijet a prodavat cokoli
co neni protipravni.
> mel byt podmnozinou konkretni implementace. To si myslim Oracle vcelku
> splnuje. Pokud nekomu vadi rozsireni (nevim absolutne proc ?) a zajima ho
> hlavne prenositelnost databaze (resp. SQL dotazu a nevim ceho jeste..), tak
> tyto rozsireni nemusi POUZIVAT !!!
'-) to same jsme porad slyseli u HTML a jak to je dneska? Nasi firemni
prezentaci mam 100% overenou na validator.w3c.org - jak HTML 4.0, tak
CSS, muzete mi rici, proc si porad nekdo stezuje, ze ji nema dobre
zobrazenou (soucasna verejna podoba jeste neni 100%, nicmene ta aktualni
u mne v adresari je 100% a presto si stezujou - to pro rypaly)? A
bohuzel ani Mozilla 0.9 neni nejlepsi...:-(
> Pokud pisu konkretni aplikaci na zakazku pro jednoho zakaznika (a vim, ze ji
> znovu asi jinam neprodam), tak se nebudu drbat s tim jak vytvorit strom
> pomoci pochybnych procedur (ktery beze zmeny kodu navic na jinym SQL enginu
> stejne asi fungovat nebudou) a v klidku pouziju CONNECT BY.
Samozrejme, stejne jako ActiveX pouziju pro nejaky veci na firemnim IS
a komunikace s okolim mne nezajima. Ale jak jsme se s kolegou shodli,
obecny nahled na urcity problem resit proprietalnim rozsirenim kdyz
problem lze resit principielne jen oklikou (at uz proprietalnim
rozsirenim, ktere interne musi delat to same nebo to udelam ve vlastni
rezii) by pri vykladu melo byt uprednostneni standardni a normovane
reseni.
Kdyz uz jsme u toho, tak implementace by mela byt nadmnozinou, jakoze
radeji
tlacit implementace do vlastnosti "byt nadmnozinou", nez vyrabet
standard
jako podmnozinu implementaci :-)))
Me nijak nevadi, naopak. Ale mohlo byt udelano v tomto pripade jinak.
Napr.
oraclovy ANALYZE je taky svym zpusobem rozsireni, tj. je DML a neni SQL.
Takze to stacilo jen vyclenit, napr.:
RECURSIVE SELECT ... START WITH... CONNECT BY
a bylo by to presne podle meho gusta. SELECT ... START WITH by rval v
Oracle
stejne jako v jine databazi.
Jan Serak
: Proc vam vadi rozsireni SQL standardu firmou Oracle ? Standard jazyka SQL by
: mel byt podmnozinou konkretni implementace. To si myslim Oracle vcelku
: splnuje. Pokud nekomu vadi rozsireni (nevim absolutne proc ?)
Pretoze ked ho pouzijete, predpisete tym pouzitu databazu na veky
vekov. Ak sa za rok objavi nieco lepsieho/lacnejsieho/..., nebude
to mozne pouzit bez noveho programovania a ladenia. Fajn pre vas ako
programatora, na porazenie pre zakaznika.
Nie som nijaky databazovy expert, ale som nuteny pisat nieco,
co si uklada data do viac-menej vseobecnej SQL databanky.
Zatial som skusal Access, Oracle, MSDE a PostgreSQL. Za tu
"kompatibilitu", co vyrobcovia vyprodukovali, by som
strielal :-(((
: a zajima ho hlavne prenositelnost databaze (resp. SQL dotazu
: a nevim ceho jeste..), tak tyto rozsireni nemusi POUZIVAT !!!
Bohuzial do znacnej miery musi. Skuste si vo vyssie uvedenych
databazach naprogramovat nieco typu "pre kazdy riadok tabulky
Foo vyhovujuci danej podmienke najdi zodpovedajuci riadok
v tabulke Bar a updatuj niekolko jeho poli na hodnoty
z dotycneho riadku Foo". Bud palite na server jeden jednotlivy
update za druhym s prislusnym dopadom na vykonnost, alebo to
pisete pre kazdu jednu databanku osobitne.
Nehovoriac o radostiach, ked potrebujem na jednej strane
counter generujuci jednoznacnu hodnotu, na strane druhej
by som ale tu tabulku rad niekam zabackupoval (inak ako
prostriedkami danej databazy, napr. do XML) a neskor 1:1
zase obnovil.
Zdravi
--
Stano
Prinejmensim pres ODBC. Doporucuji take pohledat na www.mysql.com
JT
--
Jan Tichy
e-mail: jan....@webbie.cz
-------------------------------
Webbie - webdesign & webhosting
e-mail: in...@webbie.cz
web: http://www.webbie.cz/
>> Bacha t?eba na tohle:
>> Jak jsem sly?el tak u Oracle platí ?e jedna databáze = jedna instance
>> databázového stroje => nároky na pam?».
>> (bez záruky)
>> --
>> Ji?í Lisický ?D KM®P Olomouc
>Ahoj,
>zalezi co se rozumi pojmem databaze ? Na jednom stroji muze bezet vice
>instanci (nekdo to pouziva - nekdo ne a ma jenom 1 instanci). V jedne
>instanci muze byt libovolny pocet uzivatelu (schemat ?), tablespacu, ORA
>datovych souboru atd.
>Lukas
O oracle to mam jen z doslechu, ja znam hlavne informix.
Pokud mam dve tabulky stejneho jmena, musim je mit ve dvou
databazich. Na informixu muzu pod jednou instanci databazoveho stroje
mit nekolik databazi.
Jak je to přesně v oracle nevím.
--
Jiří Lisický ČD KMŽP Olomouc
e-mail: lis...@datis.cdrail.cz Vídeňská 15
phone: +420-068-472-2272 Olomouc, Czech Republic
>>> čeština ISO-8859-2 Compatible <<<
Myslim, ze rozsireni nad standard neni nijak zavrzeni hodne,
protoze je veci kazdeho co z mnoziny SQL daneho serveru pouzije,
aneb "kazdy strujcem sveho stesti".
Jsou specializovane servery jejichz vlastnosti asi tezko nekdy
budou v nejake norme -- napr. Miriposa (klon PG) a jeji replikace)
apod.
Daleko dulezitejsi je jak moc jsou dodrzovany veci, ktere standard
jiz obsahuje (alespon na urovni SQL92). Bohuzel i v zakladnich vecech
lze najit ruznost a to casto i naprosto zbytecne napr. MySQL:
SELECT "aaa" || "bbb";
ODBC Samozrejmne ale podle mne je to dost mizerna moznost (a pomala)
co se tyce VC++ jsou pro win32 k dispozici 2 knihovny , jedna obyc. druha
obektova obe vyzaduji mysqllib.dll (pokud by se vam povedlo ji prilinkovat k
programu staticky dejte vedet prosim !)
Beha velmi dobra !
pro Borlandy podpora samozrejmne existuje take.
PS : Premyslim o moznosti napsat pro Mysql plnohodnotny ovladac OLE DB.
Cos by umoznilo nahradit Mysql-kem v podstate libovolny server bez zmeny v
aplikaci.
Pokud by se chtel nekdo pridat .... ji...@liten.cz
Neresil jsem, ale obecne tezko DLLko staticky prilinkujete, potrebujete
totiz jeho statickou podobu... - tedy nejaky mysqllib.lib, ktery se
'nainkluduje' do EXE...
Naprosto souhlasim ! Zda konkretni server podporuje SQL92 nebo ne zalezi
predevsim na jeho vyrobci. My s tim asi moc neudelame, krom toho, ze to
nebudem pouzivat. Pokud ma dany konretni server urcita vylepseni, ktera mi
usnadni vyvoj aplikace a vim, ze nebudu aplikaci portovat na jiny server,
klidne a rad toto rozsireni pouziju. Pokud budu planovat prenos aplikace na
jiny engine, asi trochu popremyslim zda pouzit pouze standardni sql nebo i
rozsireni dane implementace.
A jeste jeden dotaz. Na MySQL je nekolik odkazu na komponenty pro pripojeni
DB do Delphi, mate nekdo konkretni zkusenosti s komponentami do
Delphi ?
Dik Lukas
Na Oracle samozrejme taky. Pokud tabulku vlastni jiny user, tak se muze
jmenovat take stejne.
Lukas
> klidne a rad toto rozsireni pouziju. Pokud budu planovat prenos aplikace na
> jiny engine, asi trochu popremyslim zda pouzit pouze standardni sql nebo i
> rozsireni dane implementace.
Karel
Jeste jedno upozorneni, produkty nebudu jmenovat, bohuzel se jedna i o
ty vehlasne... Jedna vec je co za normu SQL podporuje samotny server,
druha (a daleko podstatnejsi), jakou normu podporuji interfaces... -
takze se napr. muze stat, ze server sam o sobe skoro podporuje SQL98,
ale JDBC je na urovni SQL89...neverite?
>> Pokud mam dve tabulky stejneho jmena, musim je mit ve dvou
>> databazich. Na informixu muzu pod jednou instanci databazoveho stroje
>> mit nekolik databazi.
>>
>> Jak je to p?esn? v oracle nevím.
>
>Na Oracle samozrejme taky. Pokud tabulku vlastni jiny user, tak se muze
>jmenovat take stejne.
To na informixu neplati (urcite u 7.30, u novejsich asi taky). V jedne
databazi musi byt unikatni nazev tabulky a nezalezi na jejim
vlastnikovi. Vlastnik je dulezity pouze pro prava.
Mel bych tu jeden _pouze hypoteticky_ priklad.
Mam databazovou aplikaci - nejake firemni ucetnictvi (rekneme 30
tabulek), ktere je naprogramovane tak blbe, ze pocita pouze s jednou
pobockou. A ja mam tech pobocek pet. Musim to u informixu dat do peti
databazi.
U Oracle pokud bych to dal do peti databazi musel bych udelat pet
instanci. Ale muzu vytvorit pet uzivatelu, pod kterymi vytvorim
petkrat tech 30 tabulek v jedne databazi.
Je to tak jak si myslim?
--
Jiří Lisický ČD KMŽP Olomouc
e-mail: lis...@datis.cdrail.cz Vídeňská 15
phone: +420-068-472-2272 Olomouc, Czech Republic
>>> čeština ISO-8859-2 Compatible <<<
Jo,
kdyz se pak nagrantujou prava, muze si uzivatel1 provest napriklad select
tabulky z uzivatele2 napr. takto:
SELECT * FROM UZIVATEL2.TABULKA
Lukas
vzhledem k tomu ze se toho nikdo nechytl, jsem to pak dal tady neresil.
co jsem pozdeji vyzkousel, tak je ZNACNA pravda, co je zmineno v dokumentaci, ze na male tabulky neni efektivni.
Zkusil jsem to na tabulku s cca 500 radku * 5 indexovanych sloupcu na radku a kvalita indexovani se VELMI zlepsila.
pokud neco bezi nad mysql tak bych rekl, ze takovyto fulltext odpovida narokum takove aplikace, rekl bych dokonce, ze je docela
DOBRY.
btw mysql ted zacina delat i do transakci...
Na urovni testu, nikoli produckni.
> co jsem zkousel tak mi prijde vysoce experimentalni (3.23.37.).
> nejak se mi nezda to indexovani. casto to nevraci spravne.
> slova typu mysql ale indexuje perfektne, to ano ;)
Funguje rozumne, v mezich zamyslene funkcionality; tedy pro moje
potreby to pouzitelne nebylo, nicmene dokazu si predstavit, ze to
nekdo muze shledat presne tim, co potrebuje.
--
------------------------------------------------------------------------
Honza Pazdziora | ade...@fi.muni.cz | http://www.fi.muni.cz/~adelton/
.project: Perl, DBI, Oracle, MySQL, auth. WWW servers, DBD::XBase.
Clearing mailbox after being off-line for a month, sorry for delayed replies.