Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Sta ce po vama bolje i brze raditi?

[es] :: C/C++ programiranje :: Sta ce po vama bolje i brze raditi?

[ Pregleda: 1628 | Odgovora: 11 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

IDE

Član broj: 53403
Poruke: 586
*.crnagora.net.



Profil

icon Sta ce po vama bolje i brze raditi?31.07.2006. u 22:03 - pre 215 meseci
evo ovako...ovo je podosta i teorijsko pitanje a naravno i prakticno...

recimo da imamo neku tabelu koja ima PUNO kolona i PUNO zapisa(vrsta)....

i stavljena je ADOTable1 na Active=false; kako se pri kreiranju prozora na kojem se ADOTable1 nalazi ne bi ucitavala tabela predugo i tako crpila sistemske resurse (ako se uopste i uspije ucitati jer tabela moze biti velika i 1-2 GB najmanje...)

Recimo da klikom na dugme trebamo unijeti neki novi zapis u bazu.
Da li ce brze raditi ovaj slucaj:

Code:

ADOTable1->Active=true;
ADOTable1->Insert();
ADOTable1->FieldByName("podatak1")->AsString=Edit1->Text;
ADOTable1->FieldByName("podatak2")->AsString=Edit2->Text;
.
.
.
ADOTable1->Post();


ili da stavimo prvo filter koji je neka nebuloza i koji *nikada* ne moze biti tacan npr:

Code:

ADOTable1->Filter="podatak1 = #$%#@^&%fdhu*";
ADOTable1->Filtered=true;
ADOTable1->Active=true;
ADOTable1->Insert();
ADOTable1->FieldByName("podatak1")->AsString=Edit1->Text;
ADOTable1->FieldByName("podatak2")->AsString=Edit2->Text;
.
.
.
ADOTable1->Post();

Kako se ne bi ucitavala citava tabela (koja je OGROMNA)

ja nemam ni jednu tabelu veliku 1-2 GB najmanje, pa ne mogu ovo probati..
Sta vi mislite koji je nacin bolji? Ili je mozda svejedno?
kako bi se vi zastitili od ovakvih stvari??
there's something out there
waiting for us,
and it ain't no man...
 
Odgovor na temu

kiklop74
Darko Miletić
Buenos Aires

Član broj: 78422
Poruke: 569
*.fibertel.com.ar.

Sajt: ar.linkedin.com/pub/darko..


+13 Profil

icon Re: Sta ce po vama bolje i brze raditi?01.08.2006. u 03:01 - pre 215 meseci
I jedan i drugi nachin su bez veze.

Mnogo je bolje i vrlo verovatno brze koristiti insert sql. Dakle nesto kao (pseudo kod je u pitanju):

ADOCommand->Execute("insert into <tabla> (polje1,polje2,polje3,poljeN) values(1,2,3,'test')");

Sa ovime se ne ucitava nista vec se ceo proces prebacuje na DB engine.

I uvek je bolje sachiniti SQL kad god se moze nego raditi na takav neprirodan nacin sa bazom.


Tko leti vrijedi
 
Odgovor na temu

X Files
Vladimir Stefanovic
Pozarevac

SuperModerator
Član broj: 15100
Poruke: 4902
*.nat-pool.po.sbb.co.yu.

Jabber: xfiles@elitesecurity.org


+638 Profil

icon Re: Sta ce po vama bolje i brze raditi?01.08.2006. u 06:04 - pre 215 meseci
Kao prvo, ma kolika bila baza ona se nece ucitati cela u memoriju tek tako. Jedino poneki
slozen SQL upit (minus, intersect, ...) moze naterati bazu da zatrpava RAM ili barem virtuelnu
memoriju. Cak i kada vidis u DBGridu podatke, posebnim tehnikama keširanja se podaci biti
ravnomerno uzimani i vracani, pa ce RAM ostati u logicnim granicama.

Kod bilo koje operacije sa bazom, najveci uticaj na brzinu imaju Indexi, tj. da li ih ima, da li su
postavljeni na pravom mestu, i da li ih neka tehnika uopste i uzima u obzir. Sto se tice INSERT-a,
jedino test moze da pokaze sta je brze, jer veliko je pitanje kako to BCB interno radi. Takodje
mislim da postoji razlika izmedju ADO i BDE.
 
Odgovor na temu

itf
Zagreb

Član broj: 59794
Poruke: 993
161.53.55.*



+9 Profil

icon Re: Sta ce po vama bolje i brze raditi?01.08.2006. u 07:57 - pre 215 meseci
Code:
void MojUpdate(TADOTable *Tablica, TADOConnection* Konekcija)
{
    try{    
        Konekcija->Open();
    }
    catch(...){
        ShowMessage("Ne mogu se spojiti na bazu podataka!");
        return;
    } 
    Tablica->Connection = Konekcija;
    Tablica->Open();

    try
    {
        Tablica->UpdateBatch(arAll);
    }
    catch(...)
    {
        Tablica->Connection = NULL;
        Konekcija->Close();

        ShowMessage("Greška pri spremanju podataka! Ponovo učitajte podatke iz baze!");
        Tablica->CancelBatch(arCurrent);
        return;
    }
    Tablica->Connection = NULL;
    Konekcija->Close();
}

Probaj nešto ovakvog. Ovu funkciju sam napisao još za svoje potrebe kad sam radio jedan poprilično zapetljan višeklijentski sustav. Ovo je samo skraćeni oblik, dok je ona cijela puno glomaznija od ovoga. Prethodno otvori bazu u BatchOptimistic modu, učitaj podatke iz baze u dataset, a kada želiš spremiti promjene nad zapisima pozoveš ovu funkciju.

Poanta je da su konekcije stalno zatvorene i da ne opterećuješ sistem, već samo kad ti treba obrada zahtjeva se spajaš na bazu. Ovo sam probao na oko 200 000 zapisa koji se sastoje od 48 kolona i sve se rješava u djeliću sekunde.
 
Odgovor na temu

IDE

Član broj: 53403
Poruke: 586
*.crnagora.net.



Profil

icon Re: Sta ce po vama bolje i brze raditi?01.08.2006. u 09:17 - pre 215 meseci
Citat:

I jedan i drugi nachin su bez veze.

Mnogo je bolje i vrlo verovatno brze koristiti insert sql. Dakle nesto kao (pseudo kod je u pitanju):

ADOCommand->Execute("insert into <tabla> (polje1,polje2,polje3,poljeN) values(1,2,3,'test')");


u redu je to, i ja vise volim raditi to ovako.
Moje pitanje je bilo kada se radi sa ADOTable-om, koji je nacin (od onih) najbolji....

@X-files:

jednom sam imao bazu u kojoj je bilo nekoliko stotina MB slika. Kad sam stavio ADOTable i stavio (ADOTable1->Active=false;) prozor koji ju je sadrzao se nije mogao otvoriti nekoliko minuta....sistem je maksimalno usporio bio...naravno, kada se ugasi prozor i "otpusti" sva memorija zauzeta njime sistem je "zivnuo"...Isto se desilo i kada sam naknadno,u toku rada programa aktivirao ADOTable...
Prema tome, pretpostavljam da ipak ima velikog opterecenja za memoriju u ovakvim slucajevima...
Zato gledam kako je najbolje nesto odraditi kada je u pitanju ADOTable a imamo slucaj OGROMNE tabele..

Citat:

Poanta je da su konekcije stalno zatvorene i da ne opterećuješ sistem, već samo kad ti treba obrada zahtjeva se spajaš na bazu


Znam, i u redu je to, ali procitaj ono sto sam rekao X-files-u...
there's something out there
waiting for us,
and it ain't no man...
 
Odgovor na temu

itf
Zagreb

Član broj: 59794
Poruke: 993
161.53.55.*



+9 Profil

icon Re: Sta ce po vama bolje i brze raditi?01.08.2006. u 09:54 - pre 215 meseci
Citat:
fucking voodoo: jednom sam imao bazu u kojoj je bilo nekoliko stotina MB slika. Kad sam stavio ADOTable i stavio (ADOTable1->Active=false;) prozor koji ju je sadrzao se nije mogao otvoriti nekoliko minuta....sistem je maksimalno usporio bio...naravno, kada se ugasi prozor i "otpusti" sva memorija zauzeta njime sistem je "zivnuo"...Isto se desilo i kada sam naknadno,u toku rada programa aktivirao ADOTable...
Prema tome, pretpostavljam da ipak ima velikog opterecenja za memoriju u ovakvim slucajevima...
Zato gledam kako je najbolje nesto odraditi kada je u pitanju ADOTable a imamo slucaj OGROMNE tabele..

Ti onda ne trebaš optimizaciju u programu, već u bazi.

1. Svatko tko stavlja slike u bazu je u 99% slučajeva osoba koja nema pojma o bazama podataka i optimizaciji. To su uglavnom samouki "stručnjaci". To nije inžinjerski pristup zbog niza razloga, a najveći od njih su i sama brzina rada sa bazom tj. rad sa podacima, dok velik faktor je i veličina baze što također doprinosi padu performansi. Nije ni čudo da se sve tada uspori. Umjesto slike, stavi se putanja do nje.

2. Pretpostavljam da je riječ o Access bazi. Ako jest, tada promjeni bazu jer ne možeš od Access-a očekivati čuda ako koristiš slike u tablicama. Probaj SQL server pa ćeš osjetiti razliku i sam ćeš uvidjeti da tvoj problem nema nikakve veze sa memorijom i programom, već samo sa bazom.
 
Odgovor na temu

X Files
Vladimir Stefanovic
Pozarevac

SuperModerator
Član broj: 15100
Poruke: 4902
*.nat-pool.po.sbb.co.yu.

Jabber: xfiles@elitesecurity.org


+638 Profil

icon Re: Sta ce po vama bolje i brze raditi?01.08.2006. u 09:57 - pre 215 meseci
Cuvanje slika u bazi nije dobra ideja iz razloga koji si i sam naveo, i retko se radi. Najbolje
je imati obicno tekst polje koje ce zapravo biti putanja (apsolutna ili relativna) do slike.

Resenje jeste zaobilazno, ali je jedino pametno ako zelis da imas resenje koje 'radi dobro',
i znaj da ga koriste i profesionalci.

 
Odgovor na temu

IDE

Član broj: 53403
Poruke: 586
*.crnagora.net.



Profil

icon Re: Sta ce po vama bolje i brze raditi?01.08.2006. u 14:41 - pre 215 meseci
Kao prvo, ZNAM da se u bazu, radi optimizacije same baze , stavlja putanja do neke slike a ne slika sama...

Kao drugo, nekada se MORA u bazu staviti slika jer program to zahtjeva, i ne moze se nesto uraditi osim tako. Znate : ima razlicitih programa i slucajeva.Neki su mi i zahtjevali da im slike umetnem u bazu. Prema tome otkud vam pravo da sudite koliko ja znam baze podataka kada me ni ne poznajete?
Uostalom, ja vam nisam ni postavio pitanje u vezi optimizacije baze, vec sam na pocetku rekao da bih zelio da prodiskutujem s nekim ko je raspolozen o tome kako je u odredjenom slucaju najbolje koristiti ADOTable...
Prvenstveno sam mislio na bazu sa tabelom u kojoj ima MNOGO kolona i MNOGO MNOGO teksta (npr 1-2 GB) ali eto, recimo da cak imamo i slika puno...
Dakle, NE kako cu osmisliti bazu , NE da li ja znam sto o bazama nego samo o ADOTable-u...

ADOQuery, naravno , i ja sam skoro uvijek koristim jer tada sam sve kontrolisem, ali sada pricamo o ADOTable-u...

Ako neko zeli diskutovati o tome a ne o mom znanju, mom stepenu obrazovanja i teoriji kreiranja baza podataka: izvolite....
Nemojte se ljutiti sto ovako odgovaram , niti cu se ja ljutiti sto ste vi meni rekli, ali vi pricate o necemu sto ja vec znam a sto vas nisam ni pitao...

Dakle, u onom slucaju,sta mislite koji bi kod bio brzi i bolji i zasto...??I ima li uopste razlike koja bi se osjecala pri radu sa ova 2 koda...?



there's something out there
waiting for us,
and it ain't no man...
 
Odgovor na temu

kiklop74
Darko Miletić
Buenos Aires

Član broj: 78422
Poruke: 569
*.fibertel.com.ar.

Sajt: ar.linkedin.com/pub/darko..


+13 Profil

icon Re: Sta ce po vama bolje i brze raditi?01.08.2006. u 16:18 - pre 215 meseci
Citat:
fucking voodoo:
Dakle, u onom slucaju,sta mislite koji bi kod bio brzi i bolji i zasto...??I ima li uopste razlike koja bi se osjecala pri radu sa ova 2 koda...?


Kad tako pitas onda postoji samo jedan odgovor:

Izmeri razliku pa ces videti, na primer ovako:

Code:

DWORD start = GetTickCount();
//Ovde ide kod za insert
DWORD end = GetTickCount();
int secs = (end - start)/1000;
ShowMessage(IntToStr(secs));


Licno mislim da nema neke prevelike razlike.



[Ovu poruku je menjao X Files dana 01.08.2006. u 17:46 GMT+1]
Tko leti vrijedi
 
Odgovor na temu

IDE

Član broj: 53403
Poruke: 586
*.crnagora.net.



Profil

icon Re: Sta ce po vama bolje i brze raditi?01.08.2006. u 20:17 - pre 215 meseci

pa dobro, mogu i izmjeriti...

samo sam htio i ovako teoretski da kazete zasto mislite da je neki nacin sigurniji i brzi....

Hvala vam svima na odgovorima...


there's something out there
waiting for us,
and it ain't no man...
 
Odgovor na temu

itf
Zagreb

Član broj: 59794
Poruke: 993
161.53.55.*



+9 Profil

icon Re: Sta ce po vama bolje i brze raditi?02.08.2006. u 07:41 - pre 215 meseci
Citat:
fucking voodoo: Kao prvo, ZNAM da se u bazu, radi optimizacije same baze , stavlja putanja do neke slike a ne slika sama...

Kao drugo, nekada se MORA u bazu staviti slika jer program to zahtjeva, i ne moze se nesto uraditi osim tako. Znate : ima razlicitih programa i slucajeva.Neki su mi i zahtjevali da im slike umetnem u bazu. Prema tome otkud vam pravo da sudite koliko ja znam baze podataka kada me ni ne poznajete?

Ja nigdje nisam lično tebe spomenuo, već okvirno sve one koji svojom slobodom izbora koriste takav pristup. Ako ti je već naloženo da tako radiš onda to i nije tvoj propust i stoga se nemaš šta ljutiti.
 
Odgovor na temu

IDE

Član broj: 53403
Poruke: 586
*.crnagora.net.



Profil

icon Re: Sta ce po vama bolje i brze raditi?02.08.2006. u 15:28 - pre 215 meseci
U redu je... osjecao sam se prozvanim, ali sad je ok...
there's something out there
waiting for us,
and it ain't no man...
 
Odgovor na temu

[es] :: C/C++ programiranje :: Sta ce po vama bolje i brze raditi?

[ Pregleda: 1628 | Odgovora: 11 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.