[ Brkic @ 26.10.2007. 11:45 ] @
Uporedjivanje se sastoji u sledecem,
svoj stariji program radjen u Paradox-u bez SQL-a sam prepravio za Firebird i rezultati programa su porazavajuci sto se tice brzine.
Program se sastoji iz sledecih aktivnosti, treba da uporedi podatke iz 2 tabele koje imaju 6000 linija,znaci da nadje iste podatke,razlicite i pocenu su razlicite i kojih nema u jednoj a ima u drugoj i obrnuto.
Paradoks to bez SQL-a uporedjujuci liniju po liniju zavrsi za 20 secundi
Firebird sa SQL-om zavrsi za 2 minuta i resenja su ista.Na upit pronalazenja podataka kojih ima u jednoj a nema u drugoj i obrnuto jako puno vremena treba bar 1.5 min.
Pricao sam sa drugarom koji malo ozbiljnije programira i kaze da je verovatno problem kod algoritama u Firebird-u koji su spori jer i on kada je presao na SQL server 2002 dobio ubrzanje do 10x nego kada je korisio neku drugu bazu koja podrzava SQL ali bila je spora.

Kakva su vasa iskustva i misljenja ???
[ schild @ 26.10.2007. 12:26 ] @
Rezultati su loši verovatno zbog BDE-a. Moraš dati konkretan primer ako hoćeš neki koristan odgovor, ovako ćemo se samo upustiti u prazan divan.
[ Mr. Rejn @ 26.10.2007. 12:36 ] @
Ako je SQL server 2002 ubrzao stvari 10x pod hitno pređi na SQL server..
ali pre toga pokušaj sa IBX ili .NET konektorom za FB,BDE je za penziju.
[ dogriz @ 26.10.2007. 12:58 ] @
Prvo, nisam baš siguran u to što taj drug kaže...
Drugo, nekada davno sam koristio Paradox, pa Interbase i već dugo Firebird. Ne znam kakvi su upiti i struktura same baze kad Firebird radi sporije od Paradoxa, nešto tu nije dobro isprojektovano.
Moje iskustvo vezano za Firebird je apsolutno pozitivno, izuzetno dobro mi odrađuje sav posao. U pitanju su dosta velike baze - 500 MB do preko GB, sa tabelama koje sadrže i preko 1.500.000 zapisa.

Jedina mana po meni je nedostatak enkripcije baze, već moraju da se koriste externa rešenja (pošto nemaju svi adekvatan server "pod ključem").
[ Brkic @ 26.10.2007. 16:41 ] @
Dejan Schild nemam konkretan primer,taj koji imam naveo sam, vec sam samo hteo da cujem vasa misljenja i iskustva ako ste koristili vise servera,baza... koje su razlike,brzine... nista ironicno ni napadacki.
Posto sam pocetnik ne kazem da nisam nesto dobro isprojektovao sto kaze dogriz, da nema boljeg resenja koji ce se pokazati u brzini jer i sa ovim dobijem sta treba ali sporije.

Znaci tema je pokrenuta radi price,saveta i vaseg iskistva.
[ savkic @ 26.10.2007. 19:50 ] @
> Paradoks to bez SQL-a uporedjujuci liniju po liniju zavrsi za 20 secundi
> Firebird sa SQL-om zavrsi za 2 minuta i resenja su ista.Na upit pronalazenja podataka kojih ima u jednoj a nema u drugoj i obrnuto jako
> puno vremena treba bar 1.5 min.

Ključ je kako ti radiš upoređivanje. Ako obe tabele učitaš u Table kompoenente ideš kroz jednu a u drugoj lociraš slog pomoću Locate, nije iznenađujuće. Koliko se sećam TTable.Locate koristi indekse kod Paradox baza dok kod FB to ne može. Drugo je pitanje da li koristiš direktni pristup FB bazi ili TCP/IP.
Rad sa RDBMS preko Table komponenti je traćenje resursa, lepo napisani SQL upiti su neuporedivo brži.

> Pricao sam sa drugarom koji malo ozbiljnije programira i kaze da je verovatno problem kod algoritama u Firebird-u koji su spori jer

Netačno.

> i on kada je presao na SQL server 2002 dobio ubrzanje do 10x nego kada je korisio neku drugu bazu koja podrzava SQL ali bila je spora.

Može da bude tačno ako je ta struktura druge baze loše projektovana i koriste se loši upiti. Nije teško napisati primer koji će raditi u FB 10 puta brže nego u MS SQLu. Svi RDBMS mogu pružiti slične performanse ako se upiti lepo napiši i očajne performanse ako se loše napišu.

Dakle, gotovo sigurno je je greška u tvom kodu, ako budeš dao više detalja o načinu rada, verovatno ćemo moći da ti pomognemo.
[ Brkic @ 26.10.2007. 21:21 ] @
da u Paradoxu sam obe tabele učitao u Table kompoenente i idem kroz jednu a u drugoj lociram slog pomoću Locate i to radi brzo,sve završi za 20-30 sekundi

FB-u pristupan direktno,pronalaženja istih i različitih podataka ide ok ali problem nastaje pronalaženjem podataka kojih nema u 1 a ima u 2 za to sam koristio upit
SELECT * FROM promene WHERE Ime not in (SELECT Ime FROM ulaz)
za ovaj upit treba oko 1.5 min,u obe tabele ima 6000 zapisa


sada sam prepravio program da funcionise kao kod paradox-a,obe tabele učitao u Table kompoenente i idem kroz jednu a u drugoj lociram slog pomoću Locate i oped traje oko 2min. Verovatno sto FB ne koristi indeke kao Paradox.

i ovaj upit traje oko 2.5min
select * from ulaz where ime in (SELECT ime FROM ulaz GROUP BY ime HAVING ( COUNT(ime) > 1 ))order by ime
izlistava sva imena redom koja se ponavljaju
posebno upit (SELECT ime FROM ulaz GROUP BY ime HAVING ( COUNT(ime) > 1 ) odradi za 2 sec ali kada ubacim ceo upit postaje vecnost

ima li neko resenje da traje krace jer 2.5 min je stvarno puno,vec mislim da je blokirao samo za taj upit,gde su jos ostali kao taj od gore ... ???



[Ovu poruku je menjao Brkic dana 27.10.2007. u 09:53 GMT+1]
[ savkic @ 27.10.2007. 13:27 ] @
> SELECT * FROM promene WHERE Ime not in (SELECT Ime FROM ulaz)
> za ovaj upit treba oko 1.5 min,u obe tabele ima 6000 zapisa

Da li je IME indeksirano? I koji je njegov tip CHAR/VARCHAR ili INTEGER?
NOT IN je loša konstrukcija bolje je koristiti:
SELECT FROM * A WHERE NOT EXISTS (SELECT 1 FROM B WHERE B.ID = A.ID)

> slog pomoću Locate i oped traje oko 2min. Verovatno sto FB ne koristi indeke kao Paradox.

FB naravno ima indekse ali Table komponenta ih ne može koristiti kao što je to slučaj sa Paradox Table.

> select * from ulaz where ime in (SELECT ime FROM ulaz GROUP BY ime HAVING ( COUNT(ime) > 1 ))order by ime
> izlistava sva imena redom koja se ponavljaju

Hoćeš da dobiješ sve slogove iz jedne tabele gde se jedno polje pojavljuje više puta?
Code:

SELECT
  P1.*
FROM
  PARTNERI P1
WHERE
  NOT SINGULAR(
    SELECT
      1
    FROM
      PARTNERI P2
    WHERE
      P2.GRAD_ID = P1.GRAD_ID)
[ Brkic @ 27.10.2007. 14:00 ] @
> Da li je IME indeksirano? I koji je njegov tip CHAR/VARCHAR ili INTEGER?

ime je tipa char. Ali sta znaci indeksirano?To me vec neko pitao ali ne znam sta je to ??
PRIMARY KEY je ID.

za sve iste slogove iz jedne tabele @chachka je dao slicno resenje skoro isto koje se izvrsava za 45sec u odnosu na stari upit kojem treba 3min
SELECT u1.* FROM ulaz u1 WHERE EXISTS (SELECT u2.ime FROM ulaz u2 WHERE u2.ime = u1.ime GROUP BY u2.ime HAVING COUNT(u2.ime) > 1) ORDER BY u1.ime
[ savkic @ 27.10.2007. 14:29 ] @
> ime je tipa char. Ali sta znaci indeksirano?To me vec neko pitao ali ne znam sta je to ??

Imaš jednu knjigu i hoćeš da pronađeš neki pojam u njoj, jedan način je da ideš od prve strane pa do poslednje dok ne nađeš ili da okreneš Indeks i pogledaš gde se taj pojam nalazi. E to je indeks. DDL komanda je CREATE INDEX NAZIV on TABLE (LISTA_POLJA). Ako koristiš neki GUI alat onda se to tamo može završiti i sa klikanjem miša.
Ne znam strukturu tvoje baze ali ovako na prvi pogled deluje da tabele nisu normalizovane. Spajanje više tabela treba uglavnom raditi preko INTEGERA, ne sa CHAR.

> za sve iste slogove iz jedne tabele @chachka je dao slicno resenje skoro isto koje se izvrsava za 45sec u odnosu na stari upit
> kojem treba 3min SELECT u1.* FROM ulaz u1 WHERE EXISTS (SELECT u2.ime FROM ulaz u2 WHERE u2.ime = u1.ime GROUP BY u2.ime
> HAVING COUNT(u2.ime) > 1) ORDER BY u1.ime

Bolje je (treba da bude i brže) sa NOT SINGULAR.
[ Brkic @ 27.10.2007. 14:49 ] @
@savkic hvala na objasnjenju za index-e,pogledacu kako se pravi i radi.

probao sam selekciju sa EXISTS i NOT SINGULAR i brzina je podjednaka,oko 40-45sec

probao sam i
SELECT * FROM akcie WHERE Ime not in (SELECT Ime FROM ulaz) i
SELECT * FROM akcie WHERE NOT EXISTS (SELECT ime FROM ulaz WHERE ulaz.ime = akcie.ime)
rezultati su isti oko 25sec
[ Brkic @ 27.10.2007. 16:36 ] @
Nasao sam sta su indexi,kreirao sam index 'ime' posle kreiranja tabele i nikakve promene u brzini nema,svi se pomenuti upiti izvrsavaju za isto vreme kao i bez indexa a trebalo bi biti brze,bar tako pise da za to sluze index-i.

Procitao sam da se indexi trebaju preindexirati,da li to znaci da kada se tabela cela izbrise treba je preindexirati ili se to radi automacki...ili posle svakog veceg upisa u tabelu (par hiljada zapisa) treba je preideksirati ???

[Ovu poruku je menjao Brkic dana 27.10.2007. u 18:06 GMT+1]
[ Mr. Rejn @ 27.10.2007. 21:39 ] @
Ako je samo do upoređivanja IBExpert ima opcije za to u meniju: Tools.Table Data Comparer i Database
Comparer,alisam zaboravio da li ih Personal izdanje ima.

Inače indexi mogu da budu kreirani,ali ne i aktivni.Takođe bolje je kad su UNIQUE (index odgovara
tačno jednom zapisu u tabeli).

Takođe sam video da postoji neki slabo dokumentovani "sirovi identifikator" redova u tabeli nazvan
rdb$db_key (nedokumentovana kolona nalik na primarni ključ,samo još brži u nalaženju recorda u tabeli,
kao ROWID u Oracle),ako su indexi neaktivni ovo je jedini način za identifikaciju zapisa u tabeli.
Znači možeš probati nešto u stilu:

Code:

SELECT * FROM akcie WHERE NOT EXISTS (SELECT ime FROM ulaz WHERE ulaz.ime = akcie.ime and
ulaz.rdb$db_key = akcie.rdb$db_key)

ili tako nešto.Možda je neko radio sa ovom rdb$ stvari pa može bolje to da napiše.
[ Brkic @ 27.10.2007. 22:58 ] @
kako inda da se aktiviraju index-i

moze li neko napisati malo vise o indexima,kako i kada ih praviti,aktivirati...preba li ih reindexirati pri brisanju tabele ili pri vecem upisu ...
[ Mr. Rejn @ 27.10.2007. 23:24 ] @
Pravljenje indexa nad kolonom ti je objasnio savkic.
Aktiviranje indexa: ALTER INDEX idx_tabela ACTIVE;
Deaktiviranje indexa: ALTER INDEX idx_tabela INACTIVE;

Mislim da je ipak stvar u tim BDE komponentama koje koristis,probaj
da napravis to sa IBX ili IBO.

Kada se prave: pri pravljenju tabele PK je obicno indexiran,pri pravljenju
relacije FK je obicno indexiran,ostale kolone se indexiraju po po potrebi
(nepotrebno indexiranje usporava sistem).
Ne postoji "reindexiranje pri brisanju tabele", jer se pri tome i oni uklanjaju,
veci upis nema veze,ako se upis vrsi u kolonu koja je oznacena kao indexirana
i te nove vrednosti ce biti takve.
[ savkic @ 28.10.2007. 01:14 ] @
> ili tako nešto.Možda je neko radio sa ovom rdb$ stvari pa može bolje to da napiše.

RDB$DBKEY je fizički pointer na slog u bazi. Pravu snagu iskazuje u PSQL (stored procedurama), dobici u brzini mogu biti fantastični. Sledeći linkovi su osnova.

http://www.cvalde.net/document/mysteriousDbKey.htm
http://www.cvalde.net/document/practical_use_of_the_rdb.htm
[ savkic @ 28.10.2007. 01:27 ] @
> veci upis nema veze,ako se upis vrsi u kolonu koja je oznacena kao indexirana i te nove vrednosti ce biti takve.

Uz svaki indeks se čuva i statistika tj. jedinstvenost indeksa, izračunava se posle pravljenja/aktiviranja indeksa ili na izričit zahtev. Statistika se kasnije koristi u optimizeru prilikom izbora najboljeg plana. Statistike indeksa se ne updejtuju zajeno sa slogovima, zato je moguće da postanu neaužurne. Ako se rade masovne promene u tabeli (dodavanje, brisanje, izmene), najbolje (najbrže) je deaktivirati indekse i na kraju ih ponovo aktivirati, druga varijanta je da se izvrši SET STATISTICS komanda koja će updejtovati statistiku za dati indeks. Dobra je praksa ubaciti i SET STATISTICS kao deo redovnog održavanja baze.
[ Mr. Rejn @ 28.10.2007. 13:14 ] @
Da odemo malo OT,kada pomenusmo Oracle-ov ROWID (koji ima istu ulogu kao ovaj
rdb$db_key),Oracle je od verzije 8.0 omogućio upotrebu ovih pointera
kao sredstva za formiranje relacija izmedju objekata,uvodeći objektno-relacioni
model i nasleđjivanje objekata od verzije 8.2 (gde spada u korisnički definisane
tipove podataka):

Citat:

The ability to store row IDs inside a relational table extends the traditional relational model and enhances the
capacity of an object/relational database to establish relationships between tables. Pointer data types allow you to:

* Reference sets of related rows in other tables.
It is possible to violate first normal form and have a cell in a table that contains a pointer to repeating
table values. For example, an employee table could contain a pointer called job_history_set, which in turn contains
pointers to all the relevant rows in a job_history table. This would also allow for aggregate objects to be prebuilt
so that all the specific rows in the aggregate table could be predefined.
* Include pointers to nondatabase objects in a flat file.
For example, a table cell could contain a pointer to a flat file that contains an object such as a picture in
GIF or JPEG format.
* Establish pointers to repeating groups.
Database designers can violate first normal form and create a table column that has pointers to an array of row
pointers. For example, you might create a column called order_history in a customer table. The column could contain a
pointer to a reference table containing pointers to the specific rows that represent prior orders for that customer.
* Establish one-to-many and many-to-many data relationships without relational foreign keys.
This capability alleviates the need for relational JOIN operations, since table columns can contain references
to rows in other tables. By de-referencing these pointers, rows from other tables can be retrieved without ever using
the expensive SQL JOIN operator.

uzeto iz: http://www.dba-oracle.com/art_oracle_obj.htm

Relacija se ne bi formirala preko FK-a,ne koristi se JOIN itd., međutim evo šta jedan od managera
Firebird projekta kaže za uvođenje objektno-relacionih mogućnosti u Firebird:
http://tracker.firebirdsql.org/browse/CORE-744

Zanimljivo je da se u IBExpertu moze iskoristiti ovaj rdb$db_key umesto PK za
menjanje i brisanje zapisa:

[ Brkic @ 28.10.2007. 18:02 ] @
stalno mi izbacuje gresku kod ALTER INDEX
SQL error: unsuccessful metadata update Index not found. Error code -607. This is not defined for system table.

q.SQL.Clear;
q.SQL.Add('CREATE INDEX prom_ime on promene(ime)');
q.Open;
//prodje bez problema
q.SQL.Clear;
q.SQL.Add('ALTER INDEX prom_ime ACTIVE');
q.Open; ili q.ExecSQL; svejedno je ista greska
//izbaci gresku

Pogledao sam po internetu i svuda je sintaksa kako ste rekli i ja napisao ali nece da radi.
Gde gresim ili nesto fali jos ???
[ savkic @ 28.10.2007. 18:25 ] @
> stalno mi izbacuje gresku kod ALTER INDEX
> SQL error: unsuccessful metadata update Index not found. Error code -607. This is not defined for system table.

> q.SQL.Clear;
> q.SQL.Add('CREATE INDEX prom_ime on promene(ime)');
> q.Open;

Kada se izvršava neka komanda ili nešto drugo što ne vraća resultset koristi se ExecSQL.

//prodje bez problema
> q.SQL.Clear;
> q.SQL.Add('ALTER INDEX prom_ime ACTIVE');
> q.Open; ili q.ExecSQL; svejedno je ista greska

Moguće je da nisi komitovao transakciju pa zato indeks ne postoji ili uopšte nije uspelo kreiranje indeksa. Inače, indeks koji se kreira je automatski i aktivan, dakle nema potrebe da ga izričito aktiviraš.
[ darko_sudarov @ 29.10.2007. 15:46 ] @
Mislim da je tema otisla previse daleko.
Poslusaj Savkica-napravi proceduru ,ne da ces resiti stvari nego ces biti vise nego zadovoljan brzinom.
6000 rekorda pa da bude problem ? To mi je malo smesno.
[ Brkic @ 29.10.2007. 22:49 ] @
@darko_sudarov
Napravio sam proceduru,ne izbacuje gresku,pogresio sam sa q.open i q.ExecSQL jer sam imao 'try except' ali napretka nema.Vreme izvrsavanja je isto,pomirio sam se da ne moze brze mada je smesno sa 6.000 rekorda,koliko ce vremena trebati sa 100.000 rekorda.

q.SQL.Clear;
q.SQL.Add('CREATE INDEX prom_ime on promene(ime)');
q.ExecSQL;

i jos jedno pitanje u veze selekcije
SELECT P1.ime,p1.br FROM ulaz P1 WHERE SINGULAR( SELECT ime,br FROM prom P2 WHERE P2.ime = P1.ime and p2.br<>p1.br)

radi OK,izbaci sve koji imaju razlicit 'br' ali trebalo bi mi i da izbaci vrednost p2.br za to ime, probavao sam drugacije ali ne ide,nece.
SELECT P1.ime,p1.br,p2.br FROM ulaz P1,p2 ...
znaci trebalo bi mi da izbaci ista imena sa razlicitim brojevima iz 2 tabele formata ime,br1,br2

moze li pomoc
[ schild @ 30.10.2007. 07:17 ] @
Citat:
Brkic: @darko_sudarov
Napravio sam proceduru,ne izbacuje gresku,pogresio sam sa q.open i q.ExecSQL jer sam imao 'try except' ali napretka nema.Vreme izvrsavanja je isto,pomirio sam se da ne moze brze mada je smesno sa 6.000 rekorda,koliko ce vremena trebati sa 100.000 rekorda.

q.SQL.Clear;
q.SQL.Add('CREATE INDEX prom_ime on promene(ime)');
q.ExecSQL;

Mislim da je Savkić mislio na Stored procedure, a ne na proceduru u Delphiju?! Inače, mislim da je malo bezveze kreirati bazu kroz Delphi kod, pogotovo dok experimentišemo. Uzmi lepo neki alat, IBExpert personal na primer koji je džaba, i onda lepo u njemu kreiraš tabele i indexe, i testiraš brzinu upita. Ako to radimo sve iz Delphija, onda nismo načisto da li je greška u brzini upita, ili u načinu na koji koristiš komponente!

Baza ti nije normalizovana, imena treba da su ti u posebnoj tabeli, a u ove dve tabele (ulaz i prom) da imaš samo ključ te tabele.
Proveri da li si napravio index na polje IME u obe tabele, a treba ti i index na polje BR u obe tabele.

Citat:

i jos jedno pitanje u veze selekcije
SELECT P1.ime,p1.br FROM ulaz P1 WHERE SINGULAR( SELECT ime,br FROM prom P2 WHERE P2.ime = P1.ime and p2.br<>p1.br)
radi OK,izbaci sve koji imaju razlicit 'br' ali trebalo bi mi i da izbaci vrednost p2.br za to ime, probavao sam drugacije ali ne ide,nece.

A kako da ti izbaci p2.br kad to nisi naveo u selectu?

Citat:

SELECT P1.ime,p1.br,p2.br FROM ulaz P1,p2 ...
znaci trebalo bi mi da izbaci ista imena sa razlicitim brojevima iz 2 tabele formata ime,br1,br2
moze li pomoc

Probaj ovako nešto:
Code:

select p1.ime, p1.br, p2.br
from ulaz p1
inner join prom p2 on (p2.ime=p1.ime and p2.br<>p1.br)

Sa sledećim podacima u tabeli:
Table ULAZ
IME BR
----------
tito 1
tito 2

Table PROM
IME BR
----------
tito 1
tito 10
tito 11

Dobiješ ovaj rezultat:
IME BR BR1
-------------
tito 1 10
tito 1 11
tito 2 1
tito 2 10
tito 2 11

Ako to nije rezultat, onda molim te napiši koji rezultat očekuješ na ove podatke.
[ schild @ 30.10.2007. 07:40 ] @
BTW, nije mi dao vrag mira i isprobao sam tvoj prvi primer:
Code:
select * from ulaz where ime in (SELECT ime FROM ulaz GROUP BY ime HAVING ( COUNT(ime) > 1 ))order by ime

sa onim tabelama koje sam gore naveo. Generisao sam 10000 slucajnih vrednosti u obe tabele.
Bez indexa je trajalo oko 4 minuta, a nakon indexiranja oba polja u obe tabele (znaci 4 indexa) upit se izvrsava za 90 ms!!

Sad nas lepo sve vodiš na pivo, jer nas zamajavaš, a ne slušaš savete!
[ Brkic @ 30.10.2007. 08:33 ] @
@schild nasao sam IBExpert personal i isti je kao i IBOConsole,bazu i tabele sam kreirao iz njega i isto je kao iz Delphi coda,e sada tu ima pitanja: sta je 'Domains' i 'Stored Procedures' ?? Video sam sa u primeru EMPLOYEE da vrednosti iz tabele veze sa vrednostim iz 'Domains'

sta znaci biti normalizovana , moze li neko dati neki primer kako treba napraviti bazu i tabele da bude normalizovano ,bilo bi od velike pomoci nego ovako nabadati sta ima sta nema sta je dobro sta nije, ako ima neko raspolozen da pomogne ?? ili neki PDF o bravljenju baza i tabela,podesavanja...


@schild, sto se tice upita,primer koji si dao je OK i to sam probavao ranije ali to nije resenje.
Resenje treba da izgleda ovako
tab1
-------
pera 10
dura 17
tito 8

tab2
-------
pera 15
dura 12
tito 8

resenje
-----------
pera 10 15
dura 17 12
[ Brkic @ 30.10.2007. 08:50 ] @
@schild hvala puno na trudu ali KAKO ??
vodim vas na 2 pivo samo da proradi kod mene.
sto si indexirao i ime i br kada radis samo sa imenima ??
jesi li indexirao i delphia ili alata ??
moje tabele imaju po 5-6 polja znaci li da ih trebam sve indexirati ??

moze li primer
ili source i fajl baze na mail [email protected] da vidim kako treba da izgleda ???
bilo sta

[Ovu poruku je menjao Brkic dana 30.10.2007. u 10:02 GMT+1]
[ savkic @ 30.10.2007. 09:04 ] @
> vodim vas na 2 pivo samo da proradi kod mene.

Držimo te za reč :) Vreme izvršavanje koje ti dobijaš je stvarno mnogo, na mojim test podacima je manje od 2s. Možeš li da napraviš test bazu, samo te dve tabele i podaci i pošalješ mi je pa ću pogledati gde grešiš.

> sto si indexirao i ime i br kada radis samo sa imenima ??
> jesi li indexirao i delphia ili alata ??
> moje tabele imaju po 5-6 polja znaci li da ih trebam sve indexirati ??

Polja se indeksiraju kada to donosi poboljšanje u izvršavanju upita. Npr. ako tabela ima 50 slogova, indeksiranje je nepotrebno, ali ako ima 50000 to je već druga stvar. Za normalizaciju možeš naći dosta linkova na netu, npr.
http://en.wikipedia.org/wiki/Database_normalization
http://magazin.krstarica.com/l...m-normalizacije-baza-podataka/
http://office.microsoft.com/hr-hr/access/HA012242471050.aspx

Ako ozbiljnije planiraš da se baviš programiranjem obavezno nabavi i neku literaturu.
[ chachka @ 30.10.2007. 09:52 ] @
Brkic uopšte nije naveo koju verziju FB servera koristi.
[ schild @ 30.10.2007. 11:37 ] @
Citat:
Brkic: @schild nasao sam IBExpert personal i isti je kao i IBOConsole,bazu i tabele sam kreirao iz njega i isto je kao iz Delphi coda,e sada tu ima pitanja: sta je 'Domains' i 'Stored Procedures' ?? Video sam sa u primeru EMPLOYEE da vrednosti iz tabele veze sa vrednostim iz 'Domains'

sta znaci biti normalizovana , moze li neko dati neki primer kako treba napraviti bazu i tabele da bude normalizovano ,bilo bi od velike pomoci nego ovako nabadati sta ima sta nema sta je dobro sta nije, ako ima neko raspolozen da pomogne ?? ili neki PDF o bravljenju baza i tabela,podesavanja...

Daklem, baze podataka su dosta kompleksna tema da bi te mi mogli naučiti preko foruma. Znači, malo knjiga, puno interneta, puno rada, itd...

Citat:
@schild, sto se tice upita,primer koji si dao je OK i to sam probavao ranije ali to nije resenje.
Resenje treba da izgleda ovako
tab1
-------
pera 10
dura 17
tito 8

tab2
-------
pera 15
dura 12
tito 8

resenje
-----------
pera 10 15
dura 17 12

Pa onaj upit što sam ti poslao vraća baš to, i to jako brzo, čak i bez indexa!

select p1.ime, p1.br, p2.br
from ulaz p1
inner join prom p2 on (p2.ime=p1.ime and p2.br<>p1.br)


Ja koristim FB2, kao što reče Chachka, nije svejedno ni koju verziju koristiš, starije verzije uglavnom rade lošiju optimizaciju (...) pa se sporije izvršavaju upiti.
[ Brkic @ 30.10.2007. 13:24 ] @
korisim FB2

Ok,savkicu poslacu ti veceras na mail

@schild upit je OK,radi sta treba.Hvala na pomoci

[Ovu poruku je menjao Brkic dana 30.10.2007. u 16:21 GMT+1]
[ Brkic @ 30.10.2007. 17:19 ] @
Evo resio sam problem sa indexima, kada sam napravio savkicu bazu i pre nego sto cu mu poslati ubacim je u IBOconsole,pregledavam tabelu i naletim na indexe gde stoji da su indexi samo ID koji su i Primary Key,nigde nema IME kao index a kreirao sam ga iz delphija pri pravljenju baze i tabela. Ubazim rucno jos IME kao index, isprobam u programu i stvarno sve leti,resenje za 1sec. Ogromna radost.
Sada se pitam zasto se Indexi nisu napravili,ne znam. Kada sam pravljenje indeksa prebacio na drugo mesto,tj ispod pravljenja svih tabela onda se lepo naprave i sve funkcionise.Sto nije htelo a sada hoce ne znam ali radi.

E sada posto sam uspeo napraviti indexe i sve leti svima koji su se trudili dugujem izvinjnje sto sam smarao i po 2 piva od 2litre,proizvodjaca birajte po ukusu.
Sta da radim kada tek pocinjem sa FB.