Search  
Thursday, October 22, 2020 ..:: Forum ::.. Register  Login
 Forum Minimize
Pentru a putea posta mesaje trebuie să vă înregistraţi.
Notă: Mesajele cu conţinut jignitor sau ilegal (inclusiv cereri de soft piratat) nu sunt acceptate şi vor fi şterse imediat .

Pentru a primi raspunsuri rapide si corecte, scrieti in mesaj ce intentionati sa faceti, ce mesaj de eroare primiti, in ce context si in urma caror actiuni. De asemenea, mentionati versiunea de FoxPro in care lucrati!
Dacă nu specificați versiunea, se consideră VFP 9.0 SP2.

SearchForum Home
  Visual FoxPro  Client/Server  VFP mai rapid d...
 VFP mai rapid decit SQL Server?
 
 9/11/2006 1:28:02 PM
User is offlineaflorin
840 posts
1st


VFP mai rapid decit SQL Server?
 (Romania)
Am facut o serie de teste de viteza, in paralel pe VFP si SQL Server. Tabelele au o structura relativ asemanatoare si un numar identic de inregistrari.
In principiu, fac un set de 10.000 de Update, 10.000 de Insert si 10.000 de Delete.

Spre marea mea surpriza, VFP bate net SQL, cu un raport de aprox 10:1. Daca pe local ma asteptam cumva la aceasta, pe tabele prin retea chiar m-a surprins rezultatul.

Acuma:
- fie testul meu este (cumva) gresit
- fie VFP este intr-adevar mai rapid decit SQL Server si atunci intreb: ce avantaje as avea din portarea aplicatiei pe SQL Server?

Florin Aparaschivei - Iasi
 9/11/2006 1:40:28 PM
User is offlineanonymous
0 posts


Re: VFP mai rapid decit SQL Server?
 (Romania)
Un avantaj de necontestat este ca este server si asta inseamna ca nu se aduce prin retea decat ce trebuie si este mai putin expus la coruperea datelor.
 9/11/2006 2:32:48 PM
User is offlineaflorin
840 posts
1st


Re: VFP mai rapid decit SQL Server?
 (Romania) Modified By aflorin  on 9/11/2006 2:33:18 PM)
La partea de corupere a datelor sunt totalmente de acord. Pentru aducerea datelor prin retea, treaba nu mai este la fel de simpla.
Din cate am observat eu, la un SELECT efectuat pe o tabela VFP prin retea, operatorul de selectie se face acolo unde este BD, doar proiectia facandu-se pe local.
Altfel spus, daca numarul total de campuri al unei tabele nu este cu mult mai mare decit numarul de campuri al cursorului rezultat, cantitatea de date "carata" prin retea nu va diferi foarte mult, indiferent daca am server ori ba.

Florin Aparaschivei - Iasi
 9/11/2006 2:43:22 PM
User is offlinenae racaru
716 posts
www.rarom.ro
1st




Re: VFP mai rapid decit SQL Server?
 (Romania)
La un server adevarat comanda este prelucrata de procesorul serverului, spre deosebire de file sharing unde comanda este prelucrata de procesorul statiei de lucru. Cred ca la asta se referea Cristi.

VFP 6 si 9 + Oracle
 9/11/2006 2:52:12 PM
User is offlineTibisan
269 posts
4th


Re: VFP mai rapid decit SQL Server?
 (Romania) Modified By Tibisan  on 9/11/2006 2:53:12 PM)

[edit: raspunsul este pentru aflorin; comentariul antecedent a fost postat in timp ce scriam]

stai, stai, stai... pierzi din vedere motivul pentru care exista servere de baze de date: siguranta tranzactiilor in medii multi-user si coruperea _mult_ mai rara a datelor, intr-un fel sau altul (date scrise aiurea sau chiar corupere de tabele). in vfp daca a cazut curentul se corupe cate o tabela. nu mereu, dar in cel putin 30-40% din ocazii, din propria experienta. _mai ales_ in mediu multi-user cu tabele deschise direct. daca se lucreaza prin odbc, lucrurile se imbunatatesc un pic ptr vfp, dar oricum, nu e cea mai buna abordare. eu zic sa nu cauti atata nod in papura serverelor de baze de date, pentru ca nu au fost inventate degeaba. cauta sa le intelegi sensul, nu inutilitatea.

 9/11/2006 3:40:32 PM
User is offlineaflorin
840 posts
1st


Re: VFP mai rapid decit SQL Server?
 (Romania)
cu sigurantza tranzactiilor si coruperea mult mai rara sunt perfect de acord, cum am mai spus.
eu facusem doar niste teste pe partea de viteza (intrucit am niste clienti cu f.f. multe date si care maraie pe partea asta) si eram cumva contrariat, intrucat ma asteptam la altceva.

nu caut nod in papura SGBD-urilor, vreau doar sa gasesc cea mai buna abordare. Iar la partea de viteza m-am impotmolit.

Florin Aparaschivei - Iasi
 9/11/2006 3:55:19 PM
User is offlineAdrian Vari
138 posts
5th




Re: VFP mai rapid decit SQL Server?
 (Romania)
Nici chestia cu viteza nu este chiar asa.
Tot ceea ce inseamna insa MODIFICARE de date se efectueaza mai greu pe server deoarece acesta logheaza orice modifcare petru a putea face ROLLBACK in cazul in care tranzactia nu reuseste. Asa ca un simplu replace pe 10000 de inregistrari din VFP ar trebui sa il vezi la modul urmator: am gasit inregistrarea, o citesc, o scriu cu totul in log, ma intorc la fisierul initial si fac modificarea. Daca tranzactia se incheie aici ii dau ok si fac checkpoint.
In principiu pe SQL Server orice modificare (insert, update, delete) se face cu tranzactii (implicit sau nu).
Poti insa la import de date sa folosesti BULK LOGGED pentru SQL Server si atuncti va loga doar operatiunea => crestere de viteza.

Cu cat numarul de inregistrari dintr-o tabela creste raspunsul lui SQL Server devine mai rapid decat al lui VFP.
Iar daca teava pe care lucrezi se ingusteaza si ea atunci comparatia de viteza devine si mai in avantajul serverelor.



Adrian Vari
 9/11/2006 4:00:19 PM
User is offlineAdrian Vari
138 posts
5th




Re: VFP mai rapid decit SQL Server?
 (Romania)
+ partea de securitate
+ cand ajunge la 2G foxul zice halt iar SQL Server abia s-a "incalzit"
+ faptul ca ai nevoie de 1 masina putenica nu cate una pentru fiecare user etc.

Iar daca vrei viteza pe partea de exploatare a datelor incearca cuburile. Sa vezi acolo viteza de raspuns.

Adrian Vari
 9/11/2006 4:06:58 PM
User is offlineAdrianTufă
310 posts
3rd


Re: VFP mai rapid decit SQL Server?
 (Romania)

 Adrian Vari wrote
Cu cat numarul de inregistrari dintr-o tabela creste raspunsul lui SQL Server devine mai rapid decat al lui VFP.
Iar daca teava pe care lucrezi se ingusteaza si ea atunci comparatia de viteza devine si mai in avantajul serverelor.

Asa este, aici Adrian a pus punctul pe i ! Si extrapoland in aceiasi nota:
De ce sa folosesc Oracle daca e mai rapid SQL Server ?
Raspunsul se vede la cateva zeci de conectari simultane. ;)

 9/11/2006 4:24:51 PM
User is offlineDorin Vasilescu
1369 posts
1st




Re: VFP mai rapid decit SQL Server?
 (N/A)
Oare, si acum?
Ca parca au implementat MGA (snapshot isolation), existenta in Oracle,PostgreSQL,Interbase,Firebird



 9/11/2006 7:10:33 PM
User is offlinePetre Popescu
253 posts
4th


Re: VFP mai rapid decit SQL Server?
 (N/A)

 aflorin27 wrote
eu facusem doar niste teste pe partea de viteza (intrucit am niste clienti cu f.f. multe date si care maraie pe partea asta) si eram cumva contrariat, intrucat ma asteptam la altceva.
nu caut nod in papura SGBD-urilor, vreau doar sa gasesc cea mai buna abordare. Iar la partea de viteza m-am impotmolit.

Ok, vfp este mai rapid, .....dar... daca clientii au f.f. multe date, atunci incearca testele de viteze si pe tabele cu f.f. multe date.

Optimizeaza selecturile catre server, poti folosi proceduri stocate in alte cazuri ...... s-ar putea sa ai surprize placute din partea serverului.

 9/11/2006 7:35:01 PM
User is offlineDorin Vasilescu
1369 posts
1st




Re: VFP mai rapid decit SQL Server?
 (N/A)
 aflorin27 wrote
In principiu, fac un set de 10.000 de Update, 10.000 de Insert si 10.000 de Delete.


Incearca cu SQLSETPROP(0,"Transactions",2) si cu un SQLCOMMIT() dupa fiecare 1000 de SQLEXEC(). Mai fa si  SQLPREPARE() inainte.

 Spune-ne ce ai obtinut in acele conditii.

Un aspect deloc de neglijat ar fi protejarea la coruperea bazelor de date. La noi in firma avem un program vechi de conta cu DBF-uri la care trebuie rebuild la indecsi destul de des, desi fisierele sunt pe server care merge 24 din 24 (Daca as avea timp, l-as reface in C/S).
Mai avem si baze de date Firebird, la tot felul de aplicatii interne realizate in decursul timpului + cateva pe SQL Server de la ERP. Nici macar la una, in toti acesti ani (ale pe MSSQL sunt mai noi) , nu am avut nici macar un caz de baza de date corupta.

 9/11/2006 8:29:16 PM
User is offlineneagu_laurentiu
107 posts
5th


Re: VFP mai rapid decit SQL Server?
 (N/A)

 faptul ca ai nevoie de 1 masina putenica nu cate una pentru fiecare user etc.
...spre deosebire de file sharing unde comanda este prelucrata de procesorul statiei de lucru

Si VFP-ul poate fi transformat in adevart client/server prin construirea unui obiect (D)COM ce expune motorul SQL si instantiat de catre toti clientii pe server. Astfel instantele de pe server vor duce "greul" iar prin retea circula doar rezultatele...

 9/12/2006 8:56:15 AM
User is offlineTibisan
269 posts
4th


Re: VFP mai rapid decit SQL Server?
 (Romania)
 neagu_laurentiu wrote

Si VFP-ul poate fi transformat in adevarat client/server prin construirea unui obiect (D)COM ce expune motorul SQL si instantiat de catre toti clientii pe server. Astfel instantele de pe server vor duce "greul" iar prin retea circula doar rezultatele...

cred ca solutia este viabila doar daca in spatele obiectului este tot un SGBD, altfel ramane problema tranzactiilor care trebuie sa o rezolvi personal (adica obiectul COM sa devina server. ori nu asta a fost motivul pentru care a fost creeat).... iar daca nu ti-ai propus sa-ti faci o interfata care sa te scuteasca de trecerea de la un tip de server la altul fara modificari in aplicatie, sau sa creezi un bussiness object intre aplicatie si SGBD, atunci nici nu mai are rost sa te complici cu comunicarea intre aplicatie si SGBD prin COM, cand ai putea sa comunici direct cu SGBD-ul.

eu zic ca solutiile home-made bagate in locul tehnologiei testate si creeate special pentru asa ceva rapesc din avantajele incontestabile pomenite mai sus care constituie de fapt un server (dupa parerea mea foarte greu de duplicat in vfp, decat prin creearea altui server... ori inca nu s-a putut creea unul de clasa unui oracle/firebird/mssql/etc in VFP, nici dupa atatia ani...). acum ca ma gandesc la chestia asta, realizez de ce a ramas driver-ul odbc pentru DBC-uri la versiunea 6.... erau prea multe de bagat in el si trebuia sa ajunga la nivelul unui server (chiar daca eventual mai mic), si ar fi intrat in competitie cu produsul deja existent, mssql...

 9/12/2006 2:21:41 PM
User is offlineneagu_laurentiu
107 posts
5th


Re: VFP mai rapid decit SQL Server?
 (N/A) Modified By neagu_laurentiu  on 9/12/2006 2:21:57 PM)

 Tibisan wrote
...altfel ramane problema tranzactiilor care trebuie sa o rezolvi personal ...cand ai putea sa comunici direct cu SGBD-ul.

Nu vad cum te incurca tranzactiile in povestea asta. Daca vrei le lasi pe cele implicite sau daca nu le folosesti pe cele explicite. Pe server sunt mai multe instante care actioneaza "local" dar "shared" totusi. Sau poti realiza un server TCP/IP ce asculata pe un port si lanseaza singur instantele (atit .exe sau .dll ale obiectului COM).

E o alternativa mai buna decat modelul clasic cu plimbarea prin retea a datelor si in acelasai timp nu necesita o rescriere majora a procedurilor. Server-ele SQL au punctul lor forte, sintaxa mult imbunatatita, etc.

 9/12/2006 4:55:21 PM
User is offlineTibisan
269 posts
4th


Re: VFP mai rapid decit SQL Server?
 (Romania)
 neagu_laurentiu wrote

Nu vad cum te incurca tranzactiile in povestea asta. Daca vrei le lasi pe cele implicite sau daca nu le folosesti pe cele explicite. Pe server sunt mai multe instante care actioneaza "local" dar "shared" totusi. [...]

E o alternativa mai buna decat modelul clasic cu plimbarea prin retea a datelor si in acelasai timp nu necesita o rescriere majora a procedurilor. Server-ele SQL au punctul lor forte, sintaxa mult imbunatatita, etc.

Sunt de acord ca serverul COM este o varianta mai buna decat modelul clasic. Mai ales ca prin serverele COM se poate implementa si o politica mult mai stricta de acces. Dar nu cred ca pot fi un surogat pentru serverele sql. Pot fi cel mult considerate o varianta "ultra light"...

Cat despre tranzactii, pot sa spun, asa scurt, ca in fox te poti pomeni ca un user a ramas "agatzat" cu un lock pe o inregistrare, daca folosesti acces direct si tabele native in serverul COM, sau ca niste inregistrari sterse de un user sunt rechemate de un altul ce edita acelasi document in acelasi timp dar a dat tableupdate mai tarziu, in cazul in care folosesti buffering 5 si force la tableupdate in respectivul COM. Sunt multe de discutat la capitolul asta, si nu vreau sa ma dau eu mare ca stiu eu mai bine. Nu vad insa rostul pentru care sa ma invart in jurul degetului pentru a-mi creea propriul server cand exista unele f. bune, si free pe deasupra.

Serverele COM insa sunt un bun exercitiu, iar cine are timp ar trebui sa le incerce, macar de curiozitate.

 9/13/2006 9:09:34 PM
User is offlineaflorin
840 posts
1st


Re: VFP mai rapid decit SQL Server?
 (N/A) Modified By aflorin  on 9/13/2006 9:11:19 PM)
Din motive tehnice am lipsit citeva zile de pe forum, dar observ cu placere ca subiectul a suscitat interes. Am sa incerc sa mai punctez succint citeva chestii:
- intre timp am mai facut unele teste, de data aceasta aducind de pe MsSql NUMAI cimpurile care ma interesau la un moment dat, iar treburile s-au mai schimbat putin ca viteza
- utilitatea lui SqlPrepare() nu am testat-o inca, ca nu am observat nimic deosebit in documentatie despre ea
- SqlCommit() dat dupa un calup de INSERT-uri si nu dupa fiecare am testat, dar mie mi-au iesit timpi mai mari si am banuit ca ar fi din cauza bufferelor care cresc
- treaba cu servere COM/DCOM/COM+ m-a bintuit cu ceva timp in urma, dar am abandonat-o din doua motive foarte clare:
1. nu am gasit un sistem prin care serverul COM sa-mi returneze un cursor, ci numai XML/tabela DBF pe server --> timpi destul de mari
2. pe Windows XP (majoritar acuma) am avut probleme (din cauza securitatii) la folosirea prin retea, iar pe Linux sare din schema

Oricum, intentionez sa folosesc MsSql dar vreau sa scriu in asa fel clasele pentru conexiune si aducere/scriere date incat sa poata fi usor configurabile, adica: daca clientul nu vrea MsSql, il trec pe dbf-uri VFP, dar nu acces direct pe tabele, ci prin cursoare.

Florin Aparaschivei - Iasi
 9/14/2006 10:09:46 AM
User is offlineaflorin
840 posts
1st


Re: VFP mai rapid decit SQL Server?
 (N/A)
 Dorin Vasilescu wrote
 aflorin27 wrote
In principiu, fac un set de 10.000 de Update, 10.000 de Insert si 10.000 de Delete.


Incearca cu SQLSETPROP(0,"Transactions",2) si cu un SQLCOMMIT() dupa fiecare 1000 de SQLEXEC(). Mai fa si  SQLPREPARE() inainte.

 Spune-ne ce ai obtinut in acele conditii.


Foarte corect. Timpii se reduc semnificativ in aceste conditii. Doar ca nu stiu cum pot face acest fel de Commit intr-un mediu multiuser.

Florin Aparaschivei - Iasi
 9/14/2006 3:30:17 PM
User is offlineDorin Vasilescu
1369 posts
1st




Re: VFP mai rapid decit SQL Server?
 (Romania)
Nu o sa fie nevoie tot timpul de bulk insert-uri.

Eu am vrut sa-ti ofer o varianta in care serverul nu scrie pe hard paginile de date  dupa fiecare comanda, sa vezi diferenta. Oricum nu poate fi mai rapid ca VFP , pentru ca exista comunicarea VFP->ODBC->SQL Server, cu pierderi de timp la comunicatie in retea, conversii, etc.

Daca vrei sa vezi de ce e in stare un SQL Server, fa o procedura stocata care executa comenzile alea. Sa vezi "la el acasa" de ce in stare :)

 9/14/2006 3:53:00 PM
User is offlineAdrian Vari
138 posts
5th




Re: VFP mai rapid decit SQL Server?
 (Romania)
Am facut si eu import de date in SQL prin INSERT din VFP si apoi printr-un DTS (ce lua datele direct dintr-un DBF). Diferenta de timp este enorma ...

Adrian Vari
 9/14/2006 9:12:55 PM
User is offlineneagu_laurentiu
107 posts
5th


Re: VFP mai rapid decit SQL Server?
 (N/A)

 aflorin27 wrote
1. nu am gasit un sistem prin care serverul COM sa-mi returneze un cursor, ci numai XML/tabela DBF pe server --> timpi destul de mari
2. pe Windows XP (majoritar acuma) am avut probleme (din cauza securitatii) la folosirea prin retea, iar pe Linux sare din schema

Strict la aceasta chestiune, eu folosesc un astfel de "client/server" si nu am nici o problema de securitate. Exceptind parametrii functiilor, cea mai rapida comunicare de date are loc prin scrierea/citirea de catre "server" direct pe calculatorul client a unui .dbf.

Asta nu inlocuieste un server SQL, ci doar transforma puterea VFP-ului intr-un sistem client/server, mai eficient decat modelul clasic cu plimbarea tuturor datelor prin retea.

 9/3/2011 4:56:34 PM
User is offlinedorelH
15 posts


Re: VFP mai rapid decit SQL Server?
 (N/A)
Ce ati dorit sa spuneti prin "cuburi"?
Va multumesc
 9/3/2011 7:25:18 PM
User is offlinegldesign
406 posts
2nd


Re: VFP mai rapid decit SQL Server?
 (N/A)
 dorelH wrote
Ce ati dorit sa spuneti prin "cuburi"?
Va multumesc


Uite o explicatie luata dintr-un curs SQL

Operatorul CUBE
Operatorul CUBE grupează liniile selectate pe baza valorilor tuturor combinaţiilor posibile ale expresiilor specificate şi returnează câte o linie totalizatoare pentru fiecare grup. El produce subtotaluri pentru toate combinaţiile posibile de grupări specificate în GROUP BY, precum şi un total general.
Daca exista n coloane sau expresii in clauza GROUP BY, vor exista combinatii posibile superagregat. Matematic, aceste combinatii formeaza un cub n-dimensional.
Pentru producerea de subtotaluri fara ajutorul operatorului CUBE ar fi necesare instructiuni SELECT legate prin UNION ALL.
Exemplu:
Să se afişeze valoarea totală a operelor de artă ale unui autor, expuse în cadrul fiecărei galerii având codul mai mic decât 50. De asemenea, să se afişeze valoarea totală a operelor din fiecare galerie având codul mai mic decât 50, valoarea totală a operelor fiecărui autor indiferent de galerie şi valoarea totală a operelor din galeriile având codul mai mic decât 50.
SELECT cod_galerie, cod_artist, SUM(valoare)
FROM opera
WHERE cod_galerie < 50
GROUP BY CUBE(cod_galerie, cod_artist);

COD_GALERIE COD_ARTIST SUM(VALOARE)
10 50 14000
10 60 10000
10 24000
40 50 8080
40 8080
50 22080
60 10000
32080
 9/3/2011 7:28:59 PM
User is offlinegldesign
406 posts
2nd


Re: VFP mai rapid decit SQL Server?
 (N/A)
Am luat cu copy paste si lipseste ceva

... vor exista 2 la puterea n combinatii ...

.... ar fi necesare 2 la puterea n instructiuni ...
  Visual FoxPro  Client/Server  VFP mai rapid d...

Search  Forum Home         

 Google Ads Minimize

    

Copyright 2002-2013 Profox   Terms Of Use  Privacy Statement