Firebird Procedury Skladowane - wydajnosc
e.cys...@wp.pl
FireBird 2.1 i wywoływałem go za pomoca ADO a nastepnie utworzylem
procedure skladowana w bazie Firebird i za pomoca tego samego ADO
wywolywalem ta procedurke. Procedurka wywolywala oczywiscie
identycznego SQL'a. Znowu jest zauwazalne spowolnienie przy
wywolywaniu procedurki, ale nie chce w kliencie uzywac SQL, wole zeby
wszystko było w bazie. Czy to normalne, że procedurka wykonuje sie
wolniej niz SQL przesłany bezposrednio do bazy? Czy to mozna zmienic?
czy jest jakas opcja kompilowania procedurek czy cos ?
pozdrawiam
CYSTERNA
Marcin
Sprawdź jaki jest czas wykonywania zapytania i procedury w isql
(set stats on), bo może różnice czasu wynikają
z innych przyczyn, niż serwer bazy.
M.
wloochacz
> FireBird 2.1 i wywoływałem go za pomoca ADO a nastepnie utworzylem
> procedure skladowana w bazie Firebird i za pomoca tego samego ADO
> wywolywalem ta procedurke. Procedurka wywolywala oczywiscie
> identycznego SQL'a. Znowu jest zauwazalne spowolnienie przy
> wywolywaniu procedurki,
> ale nie chce w kliencie uzywac SQL, wole zeby
> wszystko było w bazie. Czy to normalne, że procedurka wykonuje sie
> wolniej niz SQL przesłany bezposrednio do bazy?
Możliwe.
> Czy to mozna zmienic?
Można.
> czy jest jakas opcja kompilowania procedurek czy cos ?
Procedura z definicji jest kompilowana czy coś. Polecam jaką książkę o
podstawach SZBD.
KOD!
Podaj kod procedury i SQL w app.
A także kod procedury w app, którą wykorzystujesz do "testowania".
--
wloochacz
e.cys...@wp.pl
> > Mam male pytanie, zrobilem test ze wykonywalem pewnego SQL'a na
> > FireBird 2.1 i wywoływałem go za pomoca ADO a nastepnie utworzylem
> > procedure skladowana w bazie Firebird i za pomoca tego samego ADO
> > wywolywalem ta procedurke. Procedurka wywolywala oczywiscie
> > identycznego SQL'a. Znowu jest zauwazalne spowolnienie przy
> > wywolywaniu procedurki,
>
> Znowu?
Niestety. Zanim zaczne przenosic wszystko musze byc pewnym ze po calej
robocie efekt bedzie lepszy. Na chwile obecna do moich zastosowan
Access jest nr 1 i wymiekaja firebirdy i inne SQL SERVERY.
Znawcy Accessa polecili mi aby rozbic baze na kilka baz. Wiem ze to
chore ale i tak w takim przypadku logiką i panowaniem na poprawnoscia
danych zajmuje sie program klient.
> > ale nie chce w kliencie uzywac SQL, wole zeby
> > wszystko było w bazie. Czy to normalne, że procedurka wykonuje sie
> > wolniej niz SQL przesłany bezposrednio do bazy?
>
> Możliwe.
Nie możliwe tylko pewne. moze na maszynie 8 procesorowej byłoby lepiej
ale ja mam 1 procek.
> > Czy to mozna zmienic?
>
> Można.
Jak ?
> > czy jest jakas opcja kompilowania procedurek czy cos ?
>
> Procedura z definicji jest kompilowana czy coś. Polecam jaką książkę o
> podstawach SZBD.
Znam teorię i mnóstwo czytam, pisze rozne programiki testujące bo jak
sie zdecyduje to mam pol roku klepania i wole byc pewien ze to cos da
a nie ze bedzie gorzej niz jest/
> KOD!
> Podaj kod procedury i SQL w app.
> A także kod procedury w app, którą wykorzystujesz do "testowania".
Procedurki sa dwie, ale takie same, tylko ze jedna generuje ID
uzywajac generatora (cholernie spowalnia ) i bez generatora bo to
klient wysyła do procedurki parametr ID :
begin
/* ADD_FIRMA_WITHOUT_GENERATOR */
/* to dziala tylko jak tabeli juz sa dane, jak jest pusta tabela to
MAX_ID jest null i nie mozna inkrementowac*/
BEGIN
SELECT MAX(ID) FROM firmy INTO :MAX_ID;
INSERT INTO FIRMY (ID, nazwa_firmy) values (:MAX_ID+1 ,:NAZWA);
END
suspend;
end
begin
/* ADD_FIRMA_WITH_GENERATOR */
BEGIN
INSERT INTO FIRMY (ID, nazwa_firmy) values (gen_id(gen_firmy_id,
1) ,:NAZWA);
END
suspend;
end
Wywoluje procedurke przez Ado :
oCmd.CommandText = "ADD_FIRMA_WITH_GENERATOR"
oCmd.CommandType = adCmdStoredProc
Set oParam = oCmd.CreateParameter("NAZWA", adLongVarChar,
adParamInput, 255, "TEST" & Format(CStr(i + 100), "00000"))
oCmd.Parameters.Append oParam
oCmd.Execute , , adExecuteNoRecords
Jezeli chodzi o accessa to robie tio tak :
Set oDB = DAO.OpenDatabase("db2.mdb")
sLine = "TEST" & Format(CStr(i + 100), "00000")
sSql = "INSERT INTO CTB_FIRMY (ID, NAZWA_FIRMY) VALUES (" & i &
", '" & sLine & "' )"
oDB.Execute sSql
PS. Nie chce byc niegrzeczny ale moge sie założyc z ekspertem ze przy
tej wielkosci bazy i przy tym obciążeniu oraz przy jednym procesorze
ze zrobie baze w access i klienta w VB6 ktory bedzie o wiele bardziej
wydajny.
To chyba jest jedyny sposo zey dowiedziec sie czy to mozliwe o jak na
razie to Access wali na łe te wszystkie serwery.
pozdrawiam
CYSTERNA
Przemyslaw Osmanski
> Niestety. Zanim zaczne przenosic wszystko musze byc pewnym ze po calej
> robocie efekt bedzie lepszy. Na chwile obecna do moich zastosowan
> Access jest nr 1 i wymiekaja firebirdy i inne SQL SERVERY.
Lokalny dysk twardy zawsze bedzie szybszy od dysku na ftp.
Zrob w tym accesie baze wielkosci rzedu powiedzmy >4GB i wtedy
porozmawiamy o szybkosci... :)
> Znawcy Accessa polecili mi aby rozbic baze na kilka baz. Wiem ze to
> chore ale i tak w takim przypadku logiką i panowaniem na poprawnoscia
> danych zajmuje sie program klient.
Tia, rozwiązanie w stylu accessa, określa jakosc i mozliwosci :/
> Nie możliwe tylko pewne. moze na maszynie 8 procesorowej byłoby lepiej
> ale ja mam 1 procek.
Wlasnie ze nie pewne. Porownaj sobie czasy wykonania sql'a wpisanego z
linii oraz z wywolanej procedury jakims SQL monitorem, to zobaczysz co
robi sie szybciej, a co wolniej. Dodatkowo bedziesz od razu wiedzial co
jest problemem.
> Znam teorię i mnóstwo czytam, pisze rozne programiki testujące bo jak
> sie zdecyduje to mam pol roku klepania i wole byc pewien ze to cos da
> a nie ze bedzie gorzej niz jest/
To poczytaj jeszcze jak sie testuje wydajnosc serwerow baz danych, bo z
tego co czytam (caloksztalt Twoich postow), to robisz parodie a nie test
wydajności. Co zreszta juz wiele osob Tobie napisalo.
> begin
> /* ADD_FIRMA_WITHOUT_GENERATOR */
>
> /* to dziala tylko jak tabeli juz sa dane, jak jest pusta tabela to
> MAX_ID jest null i nie mozna inkrementowac*/
> BEGIN
> SELECT MAX(ID) FROM firmy INTO :MAX_ID;
> INSERT INTO FIRMY (ID, nazwa_firmy) values (:MAX_ID+1 ,:NAZWA);
> END
> suspend;
> end
To sprawdz czy Max_ID jest null i jesli jest to podstaw pod niego 0 i
procedura bedzie dzialac...
Po drugie, po co ten suspend na koncu? Radze naprawde poczytac najpierw
dokumentacje serwera bazy danych ktorego chcesz uzyc.
SUSPEND Only for SELECT procedures which return tables: Waits for the
client to request the next line. Returns the next line to the client.
> Wywoluje procedurke przez Ado :
ADO jest strasznie szybkie... :/
> PS. Nie chce byc niegrzeczny ale moge sie założyc z ekspertem ze przy
> tej wielkosci bazy i przy tym obciążeniu oraz przy jednym procesorze
> ze zrobie baze w access i klienta w VB6 ktory bedzie o wiele bardziej
> wydajny.
> To chyba jest jedyny sposo zey dowiedziec sie czy to mozliwe o jak na
> razie to Access wali na łe te wszystkie serwery.
Spokojnie, kazdy moze miec wlasny swiat :) A powaznie, jesli szybkosc
dla Ciebie jest jedynym wyznacznikiem jakości, to proponuje MySQL z
tabelami MyISAM :)
pozdrawiam,
Przemek O.
wloochacz
>>> Mam male pytanie, zrobilem test ze wykonywalem pewnego SQL'a na
>>> FireBird 2.1 i wywoływałem go za pomoca ADO a nastepnie utworzylem
>>> procedure skladowana w bazie Firebird i za pomoca tego samego ADO
>>> wywolywalem ta procedurke. Procedurka wywolywala oczywiscie
>>> identycznego SQL'a. Znowu jest zauwazalne spowolnienie przy
>>> wywolywaniu procedurki,
>> Znowu?
>
> Niestety. Zanim zaczne przenosic wszystko musze byc pewnym ze po calej
> robocie efekt bedzie lepszy. Na chwile obecna do moich zastosowan
> Access jest nr 1 i wymiekaja firebirdy i inne SQL SERVERY.
Znaczy tak - jeśli idzie o bazę lokalną, to Access będzie prawdopodobnie
szybszy. Ale, jeśli tę samą bazę umieścimy w sieci i podłączymy do tego
kilku klientów - to każdy Access wymięknie.
A że jestem dziś lekko wk... to mogę to udowodnić.
Potrzebna mi ta baza FB, coby ją poprawić...
> Znawcy Accessa polecili mi aby rozbic baze na kilka baz. Wiem ze to
> chore ale i tak w takim przypadku logiką i panowaniem na poprawnoscia
> danych zajmuje sie program klient.
Grzej jak się klient rypnie...
>>> ale nie chce w kliencie uzywac SQL, wole zeby
>>> wszystko było w bazie. Czy to normalne, że procedurka wykonuje sie
>>> wolniej niz SQL przesłany bezposrednio do bazy?
>> Możliwe.
>
> Nie możliwe tylko pewne. moze na maszynie 8 procesorowej byłoby lepiej
> ale ja mam 1 procek.
Bzdura.
>>> Czy to mozna zmienic?
>> Można.
>
> Jak ?
Trzeba wiedzieć co się pisze. A nie klepać cokolwiek byleby nie było
błędów składniowych.
>>> czy jest jakas opcja kompilowania procedurek czy cos ?
>> Procedura z definicji jest kompilowana czy coś. Polecam jaką książkę o
>> podstawach SZBD.
>
> Znam teorię i mnóstwo czytam, pisze rozne programiki testujące bo jak
> sie zdecyduje to mam pol roku klepania i wole byc pewien ze to cos da
> a nie ze bedzie gorzej niz jest/
No to słabo znasz teorię i/lub brakuje Ci praktyki.
>> KOD!
>> Podaj kod procedury i SQL w app.
>> A także kod procedury w app, którą wykorzystujesz do "testowania".
>
>
> Procedurki sa dwie, ale takie same, tylko ze jedna generuje ID
> uzywajac generatora (cholernie spowalnia ) i bez generatora bo to
Użycie generatora spowalnia??
Przecież odczytanie wartości z generatora to czas pomijalny!
> klient wysyła do procedurki parametr ID :
> begin
> /* ADD_FIRMA_WITHOUT_GENERATOR */
>
> /* to dziala tylko jak tabeli juz sa dane, jak jest pusta tabela to
> MAX_ID jest null i nie mozna inkrementowac*/
A podobno znasz teorię...
SELECT coalesce(MAX(ID), 0) FROM firmy INTO :MAX_ID;
Poza tym, aby pobranie wartości MAX z pola było szybkie (czytaj: aby
można użyć indeksu), trzeba założyć indeks odwrotny (descending) na polu ID.
A tak w ogóle, to takie pisanie jest lekko bez sensu...
SUSPEND w tej procedurze jest nie potrzebne, bo nic nie zwracasz na
zewnątrz - usuń to.
Dobra.
Tylko musimy ustalić dokładne warunki zakładu.
Moje propozycje:
taka sama struktura bazy danych
robimy insert, update, delete, select? (ilość operacji - definiowalna)
testujemy pracę w sieci, zdalnym serwerem
odpalamy procedurę w wątkach (ilość wątków definiowalna), co by
symulować jednoczesną pracę.
No i co się założymy?
Bo o pietruszkę to ja za stary jestem :)
> To chyba jest jedyny sposo zey dowiedziec sie czy to mozliwe o jak na
> razie to Access wali na łe te wszystkie serwery.
Tu mój programik z bazą, który robi inserty tak jak podałeś.
10 000 na sekundę to nie jest tragicznie, nieprawdaż?
Myślę, że mogę jeszcze coś do tego dodać...
--
wloochacz
wloochacz
>>> Mam male pytanie, zrobilem test ze wykonywalem pewnego SQL'a na
>>> FireBird 2.1 i wywoływałem go za pomoca ADO a nastepnie utworzylem
>>> procedure skladowana w bazie Firebird i za pomoca tego samego ADO
>>> wywolywalem ta procedurke. Procedurka wywolywala oczywiscie
>>> identycznego SQL'a. Znowu jest zauwazalne spowolnienie przy
>>> wywolywaniu procedurki,
>> Znowu?
>
> Niestety. Zanim zaczne przenosic wszystko musze byc pewnym ze po calej
> robocie efekt bedzie lepszy. Na chwile obecna do moich zastosowan
> Access jest nr 1 i wymiekaja firebirdy i inne SQL SERVERY.
szybszy. Ale, jeśli tę samą bazę umieścimy w sieci i podłączymy do tego
kilku klientów - to każdy Access wymięknie.
A że jestem dziś lekko wk... to mogę to udowodnić.
Potrzebna mi ta baza FB, coby ją poprawić...
> Znawcy Accessa polecili mi aby rozbic baze na kilka baz. Wiem ze to
> chore ale i tak w takim przypadku logiką i panowaniem na poprawnoscia
> danych zajmuje sie program klient.
Grzej jak się klient rypnie...
>>> ale nie chce w kliencie uzywac SQL, wole zeby
>>> wszystko było w bazie. Czy to normalne, że procedurka wykonuje sie
>>> wolniej niz SQL przesłany bezposrednio do bazy?
>> Możliwe.
>
> Nie możliwe tylko pewne. moze na maszynie 8 procesorowej byłoby lepiej
> ale ja mam 1 procek.
Nie wydaje mi się.
>>> Czy to mozna zmienic?
>> Można.
>
> Jak ?
Trzeba wiedzieć co się pisze. A nie klepać cokolwiek byleby nie było
błędów składniowych.
>>> czy jest jakas opcja kompilowania procedurek czy cos ?
>> Procedura z definicji jest kompilowana czy coś. Polecam jaką książkę o
>> podstawach SZBD.
>
> Znam teorię i mnóstwo czytam, pisze rozne programiki testujące bo jak
> sie zdecyduje to mam pol roku klepania i wole byc pewien ze to cos da
> a nie ze bedzie gorzej niz jest/
No to słabo znasz teorię i/lub brakuje Ci praktyki.
>> KOD!
>> Podaj kod procedury i SQL w app.
>> A także kod procedury w app, którą wykorzystujesz do "testowania".
>
>
> Procedurki sa dwie, ale takie same, tylko ze jedna generuje ID
> uzywajac generatora (cholernie spowalnia ) i bez generatora bo to
Użycie generatora spowalnia??
Przecież odczytanie wartości z generatora to czas pomijalny!
> klient wysyła do procedurki parametr ID :
> begin
> /* ADD_FIRMA_WITHOUT_GENERATOR */
>
> /* to dziala tylko jak tabeli juz sa dane, jak jest pusta tabela to
> MAX_ID jest null i nie mozna inkrementowac*/
A podobno znasz teorię...
SELECT coalesce(MAX(ID), 0)+1 FROM firmy INTO :MAX_ID;
Poza tym, aby pobranie wartości MAX z pola było szybkie (czytaj: aby
można użyć indeksu), trzeba założyć indeks odwrotny (descending) na polu ID.
A tak w ogóle, to takie pisanie jest lekko bez sensu...
SUSPEND w tej procedurze jest nie potrzebne, bo nic nie zwracasz na
zewnątrz - usuń to.
> begin
Dobra.
Tylko musimy ustalić dokładne warunki zakładu.
Moje propozycje:
taka sama struktura bazy danych
robimy insert, update, delete, select? (ilość operacji - definiowalna)
testujemy pracę w sieci, zdalnym serwerem
odpalamy procedurę w wątkach (ilość wątków definiowalna), co by
symulować jednoczesną pracę.
No i co się założymy?
Bo o pietruszkę to ja za stary jestem :)
> To chyba jest jedyny sposo zey dowiedziec sie czy to mozliwe o jak na
> razie to Access wali na łe te wszystkie serwery.
http://www.dgbit.pl/files/cysterna.zip
Andrzej Dąbrowski
> Tylko musimy ustalić dokładne warunki zakładu.
> Moje propozycje:
> taka sama struktura bazy danych
> robimy insert, update, delete, select? (ilość operacji - definiowalna)
> testujemy pracę w sieci, zdalnym serwerem
> odpalamy procedurę w wątkach (ilość wątków definiowalna), co by
> symulować jednoczesną pracę.
>
> No i co się założymy?
> Bo o pietruszkę to ja za stary jestem :)
Wloochacz daj sobie spokój, jak wynika z kilku wypowiedzi z różnych
wątków Cysterna jest wszechwiedzącym specjalista ds. informatyki (dużo
czyta itp.) i nie ma sensu na siłę mu nic tłumaczyć. Niech zrobi jak
uważa, a jak mu nie zadziała tak jak sobie życzył to albo zamieni się w
fanatyka, który wyciśnie z Accessa ile się da, a nawet 10% więcej, albo
zrozumie, że porady innych ludzi (skoro żyją z tego, więc zapewne
fachowców) miały sens.
Jeśli ktoś nie rozumie (pomimo tłumaczeń wielu ludzi) jaka jest różnica
pomiędzy bazą danych na komputerze lokalnym, a łączeniem się po sieci,
ani dlaczego 5000 insertów i commit, to nie to samo co (insert i commit)
*5000 to musi się sparzyć, aby zaczął słuchać uważnie rad, a nie tylko
szukał potwierdzenia swoich teorii.
Cysterna zanim zaproponujesz jakiś zakład, to najpierw musisz mieć choć
podstawową wiedzę o tym czego ten zakład dotyczy. Jeżeli nie zdajesz
sobie sprawy to warunki zaproponowane przez Wlochacza to standardowe
warunki pracy bazy danych (o ile o jakimś standardzie można mówić),
czyli równoczesne podłączenia i praca sieciową. Access nie ma żadnej
szansy w takim boju z normalną bazą danych, po prostu jego typowe
zastosowanie jest inne.
--
Andrzej Dąbrowski
Technical Team (Poland)
Embarcadero Partner,
phone +48 (22) 864 14 65
Szymon
> On 14 Lip, 10:09, wloochacz <nospam.wlooch...@nospam.dgbit.pl> wrote:
>>> Mam male pytanie, zrobilem test ze wykonywalem pewnego SQL'a na
>>> FireBird 2.1 i wywoływałem go za pomoca ADO a nastepnie utworzylem
>>> procedure skladowana w bazie Firebird i za pomoca tego samego ADO
>>> wywolywalem ta procedurke. Procedurka wywolywala oczywiscie
>>> identycznego SQL'a. Znowu jest zauwazalne spowolnienie przy
>>> wywolywaniu procedurki,
>> Znowu?
>
> Niestety. Zanim zaczne przenosic wszystko musze byc pewnym ze po calej
> robocie efekt bedzie lepszy. Na chwile obecna do moich zastosowan
> Access jest nr 1 i wymiekaja firebirdy i inne SQL SERVERY.
> Znawcy Accessa polecili mi aby rozbic baze na kilka baz. Wiem ze to
> chore ale i tak w takim przypadku logiką i panowaniem na poprawnoscia
> danych zajmuje sie program klient.
>
Tak, masz rację, to chore. Jak program ma dbać o poprawność danych to
przyjmuję zakłady kiedy wszystko się rozjedzie.
e.cys...@wp.pl
> [ciach]
Wiem ze moje testy moga wydac wam sie dziwne. Piszecie ze bzdura albo
bez sensu a przeciez testy robi sie pod katem konkretnego
zastosowania. Jezeli napisałem ze userzy robia inserty i update'y na
polach poindeksowanych i trwa to długo to szukam czegos co to
przyspieszy. Mam doswiadczenie z accessem i umiem w nim zrobic bardzo
duzo ale do profesjonalnej bazy to mu daleko.
Wiem ze te wszystkie servery są lepsze ale dla mnie lepsza baza to
taka, ktora nie bedzie wolniejsza od accessa. Nie potrzebuje triggerow
czy nawet procedur skladowanych, potrzebuje wiekszego speeda na
normalnym PC a nie serwerze dedykowanym pod konkretny RDBMS.
Nie bede zglebial tajników FB czy innych baz bo nie mam na to czasu,
che poznac podstawy i zobaczyc co to warte. Jak sie przekonam to bede
robil migracje. Problem w tym ze baza Access to tylko dane a klient to
setki regul i innych dziwnych funkcji sprawdzajacych poprawnosc i sens
operacji na bazie. Prawdziwy system powinien dzialac tak ze klient to
100 linijek kodu (uproszczenie) a baza to cała reszta.
Ze wzgledu na brak czasu nie wgłębiam sie w szczegóły i nie poswiecam
setek godzin na sprawdzanie i optymalizacje tylko pytam Was drodzy
koledzy.
Moja baza nie mieli sie 24h na dobe tylko 8 godzin dziennie w dni
robocze. Userzy sa wylacznie w sieci lokalnej a jak chca zdalnie to
maja zdalne pulpity i inne usługi terminalowe.
Dziekuje za opinie ze ADO jest szybkie. Na razie proponuje zamknac
watek. Bede reanimowal accessa jeszcze przez jakis czas.
pozdr
CYSTERNA
e.cys...@wp.pl
> 10 000 na sekundę to nie jest tragicznie, nieprawdaż?
widzialem baze i mam 2 uwagi:
1. nie ma unikatowego indeksu na polu NazwaFirmy (nie ma koniecznosci
odbudowywania)
2. programik dodaje rekordy w 1 transakcji a to nie o to chodzi,
chodzi o to zeby udowodniz ze indeks odbudowywuje sie szybciej tu niz
w Access.
poza tym nie napisales jak laczysz sie z baza, ja napisalem w moich
testach
PS. Dziekuje CI za aktywnosc, nie chce Cie denerwowac ale postaraj sie
zrozumiec innego czlowieka.
CYSTERNA
pozdrawiam
CYSTERNA
wloochacz
>> Tu mój programik z bazą, który robi inserty tak jak podałeś.
>> 10 000 na sekundę to nie jest tragicznie, nieprawdaż?
>
> widzialem baze i mam 2 uwagi:
> 1. nie ma unikatowego indeksu na polu NazwaFirmy (nie ma koniecznosci
> odbudowywania)
Dodam i zobaczymy ;>
> 2. programik dodaje rekordy w 1 transakcji a to nie o to chodzi,
> chodzi o to zeby udowodniz ze indeks odbudowywuje sie szybciej tu niz
> w Access.
A ja byłem przekonany, aby szybko dodać rekordy...
Ale ok, zrobię że każdy insert jest w jednej transakcji.
> poza tym nie napisales jak laczysz sie z baza, ja napisalem w moich
> testach
Jest napisane w Caption formy -> Delphi + AnyDAC 2.x
> PS. Dziekuje CI za aktywnosc, nie chce Cie denerwowac ale postaraj sie
> zrozumiec innego czlowieka.
Tak?
To jak mam rozumieć, tu cytat z Twojej wypowiedzi:
"PS. Nie chce byc niegrzeczny ale moge sie założyc z ekspertem ze przy
tej wielkosci bazy i przy tym obciążeniu oraz przy jednym procesorze
ze zrobie baze w access i klienta w VB6 ktory bedzie o wiele bardziej
wydajny.
To chyba jest jedyny sposo zey dowiedziec sie czy to mozliwe o jak na
razie to Access wali na łe te wszystkie serwery."
Chętnie przyjmę wyzwanie, to jak będzie?
BTW - dla tych co nie chcą uruchamiać programiku...
http://www.dgbit.pl/files/cysterna.png
Cysterna robi to w najgorszy możliwy sposób, a mógłby przyspieszyć
operację ok 150 razy...
A tu jest nowa wersja bazy i programiku:
http://www.dgbit.pl/files/cysterna1.zip
--
wloochacz
wloochacz
> Wiem ze moje testy moga wydac wam sie dziwne. Piszecie ze bzdura albo
> bez sensu a przeciez testy robi sie pod katem konkretnego
> zastosowania.
np. taki select max aby pobrać ostatnią wartość ID jest strzałem w
stopę; nie dość że coraz wolniej (bo zależy od ilości danych) to i
wrażliwy na pracę w środowisku wielodostępowym.
> Jezeli napisałem ze userzy robia inserty i update'y na
> polach poindeksowanych i trwa to długo to szukam czegos co to
> przyspieszy. Mam doswiadczenie z accessem i umiem w nim zrobic bardzo
> duzo ale do profesjonalnej bazy to mu daleko.
Może i tak, ale Access to nie jest baza danych, tylko aplikacja do
zarządzania danymi ;-)
> Wiem ze te wszystkie servery są lepsze ale dla mnie lepsza baza to
> taka, ktora nie bedzie wolniejsza od accessa.
Czyli, de-facto każda.
> Nie potrzebuje triggerow
> czy nawet procedur skladowanych, potrzebuje wiekszego speeda na
> normalnym PC a nie serwerze dedykowanym pod konkretny RDBMS.
No to weź sobie zainstaluj MySQL bez obsługi transakcji, procedur i
będziesz miał speeda.
> Nie bede zglebial tajników FB czy innych baz bo nie mam na to czasu,
To może zajmij się czymś innym?
> che poznac podstawy i zobaczyc co to warte.
Przecież już wiesz - nic nie warte.
Tylko jak Ci ludzie piszą że pitolisz głupoty trzy po trzy to do Ciebie
nie dociera. Mam nadzieję, że mój programik dotarł do Ciebie?
Reasumując - takie podstawy, jakie nam prezentujesz to trochę mało...
> Jak sie przekonam to bede
> robil migracje. Problem w tym ze baza Access to tylko dane a klient to
> setki regul i innych dziwnych funkcji sprawdzajacych poprawnosc i sens
> operacji na bazie. Prawdziwy system powinien dzialac tak ze klient to
> 100 linijek kodu (uproszczenie) a baza to cała reszta.
Nie zgadzam się, ale nieważne.
> Ze wzgledu na brak czasu nie wgłębiam sie w szczegóły i nie poswiecam
> setek godzin na sprawdzanie i optymalizacje tylko pytam Was drodzy
> koledzy.
Jakich setek?
App i bazę napisałem w niecałą godzinę.
> Moja baza nie mieli sie 24h na dobe tylko 8 godzin dziennie w dni
> robocze. Userzy sa wylacznie w sieci lokalnej a jak chca zdalnie to
> maja zdalne pulpity i inne usługi terminalowe.
To zastosuj się do tego co mówią Ci inni.
Jeśli używasz ADO, to używaj trybu BachUpdates i będziesz miał
aktualizacje w jednej transakcji niejako automatycznie.
Jeśli nie używasz BachUpdates (dlaczego nie?) to rób seri pojedynczych
operacji w odseparowanych transakcjach.
> Dziekuje za opinie ze ADO jest szybkie. Na razie proponuje zamknac
> watek. Bede reanimowal accessa jeszcze przez jakis czas.
Z tym się nie zgadzam, bo co to znaczy szybkie?
I że ADO nie jest szybkie?
Jak dla mnie jest wystarczająco szybkie, oczywiście są lepsze (szybsze
bilblioteki) zwłaszcza jeśli idzie o funkcjonalność czy pobieranie
danych z serwera, ale to nie tylko ADO ale też dostawca danych
(sterownik OLE DB czy ODBC).
Tak czy siak ADO jest (bardzo)dobre zwłaszcza przy pracy z MS SQL/Access.
--
wloochacz
e.cys...@wp.pl
> [ciach]> Wiem ze moje testy moga wydac wam sie dziwne. Piszecie ze bzdura albo
Włochaczu nie linczuj mnie publicznie. Nie jestem Adminem Bazodanowym
ze swiatowej rangi certyfikatem w kieszeni.
Jest zadanie do wykonania: PRZYSPIESZYC BAZE (operacje na bazie) BO
USERZY SIE SKARZA !!! Masz na to 2 miesiace !!!
Co mam zrobic? Najchetniej bym to zlecił ale o wydatkach moge
zapomniec, moge grzebac w accessie ale danych przybywa i bedzie
przybywac a co najgorsze siega sie do tych danych sprzed 5 lat albo i
starszych. Wiadomo moge zrobic nieograniczona liczbe baz o nazwach
2000.mdb, 2001.mbd ..... 2030.mdb i dociagne do emerytury ale chce
zeby w tym całym balaganie byla chociaz jedna rzecz zrobiona dobrze i
nie wymagajaca poprawek co rok.
Teraz jestem skazany na soft ktory ma firma albo na darmowy bo nic nie
kupia i musze cos z tym zrobic.
Mam wiec 2 wyjscia :
1. odwalic maniane w accessie i poprawic wydajnosc
2. zaryzykowac i przesiasc sie na inna RDBMS a jak nic z tego nie
bedzie?
Pierwsze rozwiazanie ma wade bo grzebie w kodzie ktory ktos kiedys
napisal, potem inny to poptrzerabial a ja teraz musze łatac
takie zycie
pozdrawiam
CYSTERNA
wloochacz
>> [ciach]> Wiem ze moje testy moga wydac wam sie dziwne. Piszecie ze bzdura albo
>> wloochacz
>
> Włochaczu nie linczuj mnie publicznie. Nie jestem Adminem Bazodanowym
> ze swiatowej rangi certyfikatem w kieszeni.
Ja tylko chcę wygrać zakład :>
Ale nic z tego nie będzie, bo się rakiem wycofujesz... widzisz, nie
trzeba było rzucać rękawicy, to nie byłoby linczu.
Nie mam sobie nic do zarzucenia, sam się o to prosiłeś ;)
> Jest zadanie do wykonania: PRZYSPIESZYC BAZE (operacje na bazie) BO
> USERZY SIE SKARZA !!! Masz na to 2 miesiace !!!
>
> Co mam zrobic? Najchetniej bym to zlecił ale o wydatkach moge
> zapomniec, moge grzebac w accessie ale danych przybywa i bedzie
> przybywac a co najgorsze siega sie do tych danych sprzed 5 lat albo i
> starszych. Wiadomo moge zrobic nieograniczona liczbe baz o nazwach
> 2000.mdb, 2001.mbd ..... 2030.mdb i dociagne do emerytury ale chce
> zeby w tym całym balaganie byla chociaz jedna rzecz zrobiona dobrze i
> nie wymagajaca poprawek co rok.
> Teraz jestem skazany na soft ktory ma firma albo na darmowy bo nic nie
> kupia i musze cos z tym zrobic.
>
> Mam wiec 2 wyjscia :
> 1. odwalic maniane w accessie i poprawic wydajnosc
> 2. zaryzykowac i przesiasc sie na inna RDBMS a jak nic z tego nie
> bedzie?
Masz jeszcze jedno; przedstaw realne stanowisko zarządowi i niech
podejmują decyzję. Sorry - trzeba inwestować, za darmo to nawet w r..j
się nie dostanie.
No i widać, że bezwzględnie należy zmigrować do jakiejś bazy SQL.
> Pierwsze rozwiazanie ma wade bo grzebie w kodzie ktory ktos kiedys
> napisal, potem inny to poptrzerabial a ja teraz musze łatac
>
> takie zycie
True
--
wloochacz
e.cys...@wp.pl
> [ciach]>> [ciach]> Wiem ze moje testy moga wydac wam sie dziwne. Piszecie ze bzdura albo
> >> wloochacz
>
> > Włochaczu nie linczuj mnie publicznie. Nie jestem Adminem Bazodanowym
> > ze swiatowej rangi certyfikatem w kieszeni.
>
> Ale nic z tego nie będzie, bo się rakiem wycofujesz... widzisz, nie
> trzeba było rzucać rękawicy, to nie byłoby linczu.
> Nie mam sobie nic do zarzucenia, sam się o to prosiłeś ;)
Za mało znam FB ale moze za 1-2 tygodnie ja sie nie zniechece to
mozemy sie scignac.
Oczywiscie twoje zalozenia to baza 10 GB i 50000000 rekordow itd,
wiadomo ze access nie pociagnie, ale przyjmijmy moje warunki, czyli 1
tabela max 10000 rekordow i dostep zdalny z innego kompa. Ja przez ADO
ty przez ODBC czy jak tam chcesz ale ma to byc taka forma dostepu do
bazy, ktora umozliwi łączenie sie nawet 20 uzytkownikom jednoczesnie
(a nie jakis embeded).
Zanim zaczniemy zakład trzeba ustalic szczegóły ale jak chwile
pomyslalem to nie wiem czy to mozliwe zeby wszystko ustalic, poniewaz
jak przegrasz to i tak znajdziesz jakies wymówki.
Bez wzgledu na finała zakładu wniosek bedzie nastepujący :
1. jak przgrasz to znaczy ze nie miałes racji, nawypisywałes niezbyt
pochlebnych opinii będąc w błędzie
2. jak wygrasz to znaczy ze nie chciałes pomoc na grupie dyskusyjnej
tylko chciałes sie powysmiewac albo zarobic kase
Kwota wyjściowa zakładu 200 000 PLN.
PS. zanim przystapimy pokazemy sobie wyciagi z kont osobistych ze tyle
posiadamy.
pozdrawiam
Cysterna
Przemysław Rachwał
sory że się wtrącę
patrząć we fragmenty kodu które podesłałeś zapytam głupio czy za każdym
razem tworzysz i zamykasz połączenie przy kodzie ADO?
po co tworzysz nowy obiekt DAO przy wykonywaniu kodu w Access
oba te elementy raczej szybkie nie są a po 10000 razy aplikacja szybsza
też nie będzie
wloochacz
>>> Włochaczu nie linczuj mnie publicznie. Nie jestem Adminem Bazodanowym
>>> ze swiatowej rangi certyfikatem w kieszeni.
>> Ja tylko chcę wygrać zakład :>
>> Ale nic z tego nie będzie, bo się rakiem wycofujesz... widzisz, nie
>> trzeba było rzucać rękawicy, to nie byłoby linczu.
>> Nie mam sobie nic do zarzucenia, sam się o to prosiłeś ;)
>
> Za mało znam FB ale moze za 1-2 tygodnie ja sie nie zniechece to
> mozemy sie scignac.
> Oczywiscie twoje zalozenia to baza 10 GB i 50000000 rekordow itd,
> wiadomo ze access nie pociagnie, ale przyjmijmy moje warunki, czyli 1
> tabela max 10000 rekordow i dostep zdalny z innego kompa.
Co to jest 10k rekordów?
NIC.
Za mało żeby cokolwiek testować.
Tak mało danych nie ma w realnym środowisku produkcyjnym.
> Ja przez ADO
> ty przez ODBC czy jak tam chcesz ale ma to byc taka forma dostepu do
> bazy, ktora umozliwi łączenie sie nawet 20 uzytkownikom jednoczesnie
> (a nie jakis embeded).
Taaa... Używanie Firebirda'a w trybie embeded wyklucza połączenia zdalne.
> Zanim zaczniemy zakład trzeba ustalic szczegóły ale jak chwile
> pomyslalem to nie wiem czy to mozliwe zeby wszystko ustalic, poniewaz
> jak przegrasz to i tak znajdziesz jakies wymówki.
Ciekawe, ciekawe...
A jak wygram to Ty znajdziesz wymówki?
Powtarzam - pękasz i tyle.
A szczegóły da się ustalić.
> Bez wzgledu na finała zakładu wniosek bedzie nastepujący :
> 1. jak przgrasz to znaczy ze nie miałes racji, nawypisywałes niezbyt
> pochlebnych opinii będąc w błędzie
> 2. jak wygrasz to znaczy ze nie chciałes pomoc na grupie dyskusyjnej
> tylko chciałes sie powysmiewac albo zarobic kase
Ach tak?
Czyli tak czy inaczej ja jestem be a Ty jesteś cacy?
Wiesz co, zaczynasz mnie potężnie wku...
Dostałeś na tacy rozwiązanie.
Napisałem Ci programik jak należy pewne operacje przeprowadzać, a jak
nie należy.
Dostałeś też możliwość porównania szybkości złych i dobrych praktyk.
A Ty masz czelność jeszcze jęczeć?
Reasumując - nie chciałem zarobić kasy.
Nie chciałem się "powyśmiewać".
Chciałem Ci pokazać poprawne rozwiązanie, jednocześnie przytrzaskując Ci
ten niewyparzony jęzor - nie więcej nie mniej.
> Kwota wyjściowa zakładu 200 000 PLN.
Niech będzie te marne 200k, ale żeby dodać smaczku to proponuję tę kwotę
pomnożyć tyle razy, ile razy dana baza była szybsza od drugiej.
> PS. zanim przystapimy pokazemy sobie wyciagi z kont osobistych ze tyle
> posiadamy.
Dobra.
A może wolisz ruchomości?
A może nieruchomości?
Tak czy siak - nie ma problemu.
Reasumując tę kretyńską dyskusję;
Jeśli używa się silnika SQL zgodnie z założeniami (TRANSAKCJE!!), to
żaden Access nie ma szans.
Jeśli nie (czyli. 10k insertów i każdy w osobnej transakcji) to żaden
SQL nie ma szans z Accessem.
I nie ważne, czy pracuje się ze zdalną bazą czy z lokalną. Całość
dotyczy obciążenia dokładnie z 1 użytkownikiem.
Tu mamy obrazek:
http://www.dgbit.pl/files/cysterna1.png
Co ciekawe, Access jest w miarę równy w swoich wynikach.
Firebird nie - im więcej tym szybciej to robi.
Żeby to przetestować, to trzeba by wziąć to wąskie gardło z tej
aplikacji (zapis jakiś informacji czy co tam się dzieje) i zasymulować
równoległe obciążenie np. przez 20 użytkowników.
Wtedy możemy coś powiedzieć.
Bo taki głupawy insert to tabelki zawierający dwa pola i dwa indeksy, to...
--
wloochacz
e.cys...@wp.pl
> [ciach]
> Reasumując tę kretyńską dyskusję;
[ciach]
Zauwazylem ze im wieksze glupoty pisze jedna osoba tym jeszcze wieksze
wypisuje kolejna. Pora zakonczyc ta dyskusje bo ona do niczego nie
doprowadzi, poza tym prawdopodobnie bede jeszcze pytal na tej grupie o
pewne rzeczy i nie dlatego nie chce cie wkurzac zebys jeszcze kiedys
mi pomogl (mam nadzieje ze bedziesz chcial)
Ostatnia sprawa to taka, ze czasami pewne rzeczy wydaja sie glupie ale
tylko dlatego, ze nie zna sie calego otoczenia problemu a jedynie
wycinek.
Dla przykladu gdybym zapytal, ze testuje moj rower gorski na asfalcie
na predkosc maksymalna i testy przeprowadzam pod górkę i do tej pory
uzyskałem Vmax 18 km/h i prosze o pomoc co mam zrobic zeby poprawic
wynik, to 99% odpowiedzi bedzie ze autor jest idiotą i powinien
testowac z gorki , bo wtedy bez wysiłku uzyska co najmniej 2 krotnie
wieksza predkosc. Prawda jest taka ze srodowisko do testowania zostalo
wybrane zgodnie z pewnymi zalozeniami, na opisywanie ktorych tu nie ma
miejsca ani ochoty.
Dobre rady dotyczyłyby optymalnego ustawienia wysokosci siodła i
kierownika, moze zastosowania butow SPD ktore pozwalaja nie tylko
naciskac na pedały ale rowniez ciągnąc, zastosowania innych przełożen
itd. Na takie jednak rady nie można zawsze liczyć. Drwina jest
najłatwiejsza, bo nie wymaga zadnej wiedzy, ale ja nigdy nie lekcewaze
nikogo natomiast inni uzytkownicy grup uwazaja siebie za lepszych nie
zawsze wiedząc z kim tocza dyskusję.
Bede wdzieczny włochaczu jak nie odpowiesz juz na ten wątek. Jezeli
poprawi ci to humor i samopoczucie to przyznam, ze twoj program jest o
wiele szybszy od mojego accessa tylko co z tego ze cos udowodniłes jak
to ja prosiłem o pomoc a moja baza jak była wolna tak jest.
pozdrawiam
CYSTERNA
wloochacz
> Bede wdzieczny włochaczu jak nie odpowiesz juz na ten wątek. Jezeli
> poprawi ci to humor i samopoczucie to przyznam, ze twoj program jest o
> wiele szybszy od mojego accessa tylko co z tego ze cos udowodniłes jak
> to ja prosiłem o pomoc a moja baza jak była wolna tak jest.
Tylko jej nie rozumiesz lub nie chcesz zrozumieć.
--
wloochacz
d'plus
> On 17 Lip, 11:32, wloochacz <nospam.wlooch...@nospam.dgbit.pl> wrote:
>> [ciach]
>> Reasumując tę kretyńską dyskusję;
> [ciach]
>
> Zauwazylem ze im wieksze glupoty pisze jedna osoba tym jeszcze wieksze
a już myślałem, że komuś poleci 200k. buuuu
co do procedur składowanych to największy jest zysk gdy praca jest
sieciowa LAN, WAN, VPN itd..
składowanie procedury jest przydatne gdy serwer jest mocniejszy niż
klient - wtedy przechodzi praktycznie wszystko na jego barki.
ja ostatnio zoptymalizowałem procedurę 10-cio krotnie przekładając ją do
bazy, no ale to był Oracle. teraz staram sie większość dużych operacji
wrzucać do bazy.
moja rada to Oracle XE lub MySQL jak koledzy powiedzieli. To są liderzy
wydajności a nie postgres.
--
http://www.asiakepka.com - boston based photographer
http://www.oln.pl/ - olsztyńska galeria internetowa
http://www.limuzyny.ketrzyn.pl - limuzyny do wynajęcia - warmia i mazury
wloochacz
> a już myślałem, że komuś poleci 200k. buuuu
>
> co do procedur składowanych to największy jest zysk gdy praca jest
> sieciowa LAN, WAN, VPN itd..
poza tym z raczej SZBD inaczej nie pracują, jak serwer dostępny zdalnie...
> składowanie procedury jest przydatne gdy serwer jest mocniejszy niż
> klient - wtedy przechodzi praktycznie wszystko na jego barki.
> ja ostatnio zoptymalizowałem procedurę 10-cio krotnie przekładając ją do
> bazy, no ale to był Oracle.
A jakie to ma znacznie, że to był Oracle?
> teraz staram sie większość dużych operacji
> wrzucać do bazy.
>
> moja rada to Oracle XE lub MySQL jak koledzy powiedzieli. To są liderzy
> wydajności a nie postgres.
Taaak?
Ciekawe, to znaczy że TPC kłamią jak z nut?
http://www.tpc.org/tpce/tpce_perf_results.asp
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
Są jeszcze inne SZBD obok Oracle...
--
wloochacz
Szymon
> e.cys...@wp.pl pisze:
>> On 17 Lip, 11:32, wloochacz <nospam.wlooch...@nospam.dgbit.pl> wrote:
>>> [ciach]
>>> Reasumując tę kretyńską dyskusję;
>> [ciach]
>>
>> Zauwazylem ze im wieksze glupoty pisze jedna osoba tym jeszcze wieksze
> [sru]
>
> a już myślałem, że komuś poleci 200k. buuuu
>
> co do procedur składowanych to największy jest zysk gdy praca jest
> sieciowa LAN, WAN, VPN itd..
Ta.... to zależy
> składowanie procedury jest przydatne gdy serwer jest mocniejszy niż
> klient - wtedy przechodzi praktycznie wszystko na jego barki.
To zależy
> ja ostatnio zoptymalizowałem procedurę 10-cio krotnie przekładając ją do
> bazy, no ale to był Oracle. teraz staram sie większość dużych operacji
> wrzucać do bazy.
>
To zależy
> moja rada to Oracle XE lub MySQL jak koledzy powiedzieli. To są liderzy
> wydajności a nie postgres.
>
>
A jakieś konkretne przykłady? Tylko proszę, nie porównuj mi tu
MySQL-MyISAM z Postgresem czy Oraclem. Poza tym "baza jest tak dobra jak
administrator", Oracla i tak trzeba ręcznie, jak to oni ładnie
określają, "stroić".
d'plus
> [ciach]
>> a już myślałem, że komuś poleci 200k. buuuu
>>
>> co do procedur składowanych to największy jest zysk gdy praca jest
>> sieciowa LAN, WAN, VPN itd..
> Nieprawda;
> poza tym z raczej SZBD inaczej nie pracują, jak serwer dostępny zdalnie...
SZBD? Znaczy że RDBMS łączy się z bazą poprzez interfejs sieciowy a nie
bezpośrednio? Jeśli już, to ten interfejs będzie jako local loopback co
w porównaniu z 100M/1GB LAN-em i tak będzie gigantyczną róznicą.
>> składowanie procedury jest przydatne gdy serwer jest mocniejszy niż
>> klient - wtedy przechodzi praktycznie wszystko na jego barki.
>> ja ostatnio zoptymalizowałem procedurę 10-cio krotnie przekładając ją
>> do bazy, no ale to był Oracle.
> A jakie to ma znacznie, że to był Oracle?
to, że nie był to Postgres o którym mowa i efekty nie muszą wcale być
identyczne.
>> teraz staram sie większość dużych operacji wrzucać do bazy.
>>
>> moja rada to Oracle XE lub MySQL jak koledzy powiedzieli. To są
>> liderzy wydajności a nie postgres.
> Taaak?
> Ciekawe, to znaczy że TPC kłamią jak z nut?
> http://www.tpc.org/tpce/tpce_perf_results.asp
> http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
> Są jeszcze inne SZBD obok Oracle...
>
już to widzę, jak przenoszą system z Accessa na AIX 5 i DB2, albo kupują
16 core-ową maszynę.
W popularnych i tanich zastosowaniach prym wiodą Oracle XE i MySQL.
Widziałem gdzieś test, którego nie jestem niestety w stanie przytoczyć.
miab
Chyba raczej taka perspektywa:
http://www.tpc.org/tpcc/results/tpcc_results.asp?print=false&orderby=priceperf&sortby=asc
a nie który z kilkunastomilionowców jest nieco szbszy.
miab
wloochacz
> wloochacz pisze:
>> [ciach]
>>> a już myślałem, że komuś poleci 200k. buuuu
>>>
>>> co do procedur składowanych to największy jest zysk gdy praca jest
>>> sieciowa LAN, WAN, VPN itd..
>> Nieprawda;
>> poza tym z raczej SZBD inaczej nie pracują, jak serwer dostępny
>> zdalnie...
>
> SZBD? Znaczy że RDBMS łączy się z bazą poprzez interfejs sieciowy a nie
> bezpośrednio? Jeśli już, to ten interfejs będzie jako local loopback co
> w porównaniu z 100M/1GB LAN-em i tak będzie gigantyczną róznicą.
wysyła się duuuże ilości danych z serwera do klienta i odwrotnie.
A cały myk polega przecież na tym, aby minimalizować ruch sieciowy.
>>> składowanie procedury jest przydatne gdy serwer jest mocniejszy niż
>>> klient - wtedy przechodzi praktycznie wszystko na jego barki.
>>> ja ostatnio zoptymalizowałem procedurę 10-cio krotnie przekładając ją
>>> do bazy, no ale to był Oracle.
>> A jakie to ma znacznie, że to był Oracle?
>
> to, że nie był to Postgres o którym mowa i efekty nie muszą wcale być
> identyczne.
>
>>> teraz staram sie większość dużych operacji wrzucać do bazy.
>>>
>>> moja rada to Oracle XE lub MySQL jak koledzy powiedzieli. To są
>>> liderzy wydajności a nie postgres.
>> Taaak?
>> Ciekawe, to znaczy że TPC kłamią jak z nut?
>> http://www.tpc.org/tpce/tpce_perf_results.asp
>> http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
>> Są jeszcze inne SZBD obok Oracle...
>>
>
> już to widzę, jak przenoszą system z Accessa na AIX 5 i DB2, albo kupują
> 16 core-ową maszynę.
A po co?
Do tego co im potrzebne, to najprawdopodobniej spokojnie da radę dowolny
SZBD.
> W popularnych i tanich zastosowaniach prym wiodą Oracle XE i MySQL.
> Widziałem gdzieś test, którego nie jestem niestety w stanie przytoczyć.
A ja jestem pewien, że prym to wiedzie MS SQL Express.
MS SQL Express ma ciut mniejsze ograniczenia.
Podaj mi jakiś przykład oprogramowania in-the-box, które jest
rozprowadzane z Oracle XE (poza Compiere ;)); bo pod MS SQL Express jest
tego na tony.
A MySQL?
Sorry, ale jak włączy się obsługę transakcji, triggerów, procedury to
niewiele zostaje z legendarnej szybkości MySQL'a.
Fakt - jest popularny ale jako backend rozwiązań webowych.
--
wloochacz
Szymon
> A MySQL?
> Sorry, ale jak włączy się obsługę transakcji, triggerów, procedury to
> niewiele zostaje z legendarnej szybkości MySQL'a.
> Fakt - jest popularny ale jako backend rozwiązań webowych.
>
Tak, ale tylko dla sadystów-masochistów... bo potem z powodu braku
transakcji wszystko zaczyna się rozjeżdżać, przecież nawet check w
mysqlu to proteza (zgodnie z manualem: check jest parsowane ale nie
sprawdzane).
wloochacz
forum w necie" zamiast "jest popularny ale jako backend rozwiązań
webowych."; zrobiłem się ciut mniej radykalny :D
--
wloochacz
Szymon
A to wtedy się nazywa ewolucja czy uwstecznienie?
wloochacz
> A to wtedy się nazywa ewolucja czy uwstecznienie?
d'plus
> d'plus pisze:
>> wloochacz pisze:
>>> [ciach]
>>>> a już myślałem, że komuś poleci 200k. buuuu
>>>>
>>>> co do procedur składowanych to największy jest zysk gdy praca jest
>>>> sieciowa LAN, WAN, VPN itd..
>>> Nieprawda;
>>> poza tym z raczej SZBD inaczej nie pracują, jak serwer dostępny
>>> zdalnie...
>>
>> SZBD? Znaczy że RDBMS łączy się z bazą poprzez interfejs sieciowy a
>> nie bezpośrednio? Jeśli już, to ten interfejs będzie jako local
>> loopback co w porównaniu z 100M/1GB LAN-em i tak będzie gigantyczną
>> róznicą.
> Dalej się nie zgadzam, bo to nam tylko mówi o tym że szybciej/wolniej
> wysyła się duuuże ilości danych z serwera do klienta i odwrotnie.
> A cały myk polega przecież na tym, aby minimalizować ruch sieciowy.
jakoś wogole nie mogę zrozumieć twojego toku myslenia.
wlasnie piszę, że nie ma de facto ruchu sieciowego bo procedura
wbudowana komunikuje się RDBMS->WIRTUALNY INTERFEJS->DB (jeśli już -
osobiście nie wierzę, że tak to się odbywa).
A gdy procedura jest wykonywana przez klienta to leci to poprzez
fizyczny interfejs i obkładana jest pierdoałmi typu kontrola transmisji
i ograniczenia fizyczne w najlepszym przypadku, w najgorszym leci 400km
poprzez WAN i przepycha się przez kilkanaście routerów, switchy i kabli.
>>>> składowanie procedury jest przydatne gdy serwer jest mocniejszy niż
>>>> klient - wtedy przechodzi praktycznie wszystko na jego barki.
>>>> ja ostatnio zoptymalizowałem procedurę 10-cio krotnie przekładając
>>>> ją do bazy, no ale to był Oracle.
>>> A jakie to ma znacznie, że to był Oracle?
>>
>> to, że nie był to Postgres o którym mowa i efekty nie muszą wcale być
>> identyczne.
>>
>>>> teraz staram sie większość dużych operacji wrzucać do bazy.
>>>>
>>>> moja rada to Oracle XE lub MySQL jak koledzy powiedzieli. To są
>>>> liderzy wydajności a nie postgres.
>>> Taaak?
>>> Ciekawe, to znaczy że TPC kłamią jak z nut?
>>> http://www.tpc.org/tpce/tpce_perf_results.asp
>>> http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
>>> Są jeszcze inne SZBD obok Oracle...
>>>
>>
>> już to widzę, jak przenoszą system z Accessa na AIX 5 i DB2, albo
>> kupują 16 core-ową maszynę.
> A po co?
> Do tego co im potrzebne, to najprawdopodobniej spokojnie da radę dowolny
> SZBD.
strzał w stopę? to ty przedstawiłeś te high-endowe maszyny jako dowód,
że powinno się wybrać rozwiązania inne niż oracle.
jak tutaj kolega przedstawił inny test to jasno widać, że w mniejszych
(tańszych) rozwiązaniach lideruje oracle 11g/10g i pewnie tym samym jego
młodszy brat Oracle XE.
Test mało znaczący dla tej dyskusji bo nie testuje wogóle baz typu MYSQL
i PGSQL a jedynie enterprise-owe wersje najdroższych baz testowane
zapewne również z użyciem wszelkich mozliwych funkcji dodatkowych jak
triggery i procedury wbudowane. tutaj debata chyba się toczy nad
optymalizacją procesów insert/update.
>> W popularnych i tanich zastosowaniach prym wiodą Oracle XE i MySQL.
>> Widziałem gdzieś test, którego nie jestem niestety w stanie przytoczyć.
> A ja jestem pewien, że prym to wiedzie MS SQL Express.
> MS SQL Express ma ciut mniejsze ograniczenia.
> Podaj mi jakiś przykład oprogramowania in-the-box, które jest
> rozprowadzane z Oracle XE (poza Compiere ;)); bo pod MS SQL Express jest
> tego na tony.
miliony much też mają rację?
z VS dostajesz natywną obsługę MS SQL i pewnie dlatego jest tak szeroko
popularne wsrod oprogramowania półkowego. Soft półkowy zazwyczaj nie ma
również wielkich wymagań dlatego pewnie nie ma tutaj znaczenia DB.
> A MySQL?
> Sorry, ale jak włączy się obsługę transakcji, triggerów, procedury to
> niewiele zostaje z legendarnej szybkości MySQL'a.
> Fakt - jest popularny ale jako backend rozwiązań webowych.
ja mowilem o teście, to nie moje widzimisię. być może ktoś go jeszcze
widział. pierwszy był oracle, drugi mysql, a potem reszta.
Przemyslaw Osmanski
> miliony much też mają rację?
> z VS dostajesz natywną obsługę MS SQL i pewnie dlatego jest tak szeroko
> popularne wsrod oprogramowania półkowego. Soft półkowy zazwyczaj nie ma
> również wielkich wymagań dlatego pewnie nie ma tutaj znaczenia DB.
Oj nie przesadzaj, niektore z nich to calkiem duze rozwiazania.
Odpowiedzia jest chyba cena pozniejszej migracji do wersji komercyjnej i
ew. łatwośc administrowania/instalacji.
> ja mowilem o teście, to nie moje widzimisię. być może ktoś go jeszcze
> widział. pierwszy był oracle, drugi mysql, a potem reszta.
Itam, jak robil go ktos rownie kompetentny jako niektorzy, to nie ma sie
co dziwic. Przy jakichs dziwnych założeniach moze i są takie wyniki.
pozdrawiam,
Przemek O.
d'plus
nie no racja. na każdą bazę znajdzie się odpowiedni test. tamten był na
dosyć powazanej witrynie i opierał się raczej o proste operacje bez
wielu dodatków po drodze.
wloochacz
> nie no racja. na każdą bazę znajdzie się odpowiedni test. tamten był na
> dosyć powazanej witrynie i opierał się raczej o proste operacje bez
> wielu dodatków po drodze.
Albo podaj źródło, albo przestań pitolić...
--
wloochacz
d'plus
tym postem potwierdziłeś moje przypuszczenia co do twojej osoby.
z szacunku do samego siebie nie będę już z tobą nigdy dyskutował.
Andrzej Dąbrowski
> wloochacz pisze:
>> [ciach]
>>> nie no racja. na każdą bazę znajdzie się odpowiedni test. tamten był
>>> na dosyć powazanej witrynie i opierał się raczej o proste operacje
>>> bez wielu dodatków po drodze.
>> Tylko dlaczego nikt tego testu nie widział?
>> Albo podaj źródło, albo przestań pitolić...
>>
>
> tym postem potwierdziłeś moje przypuszczenia co do twojej osoby.
> z szacunku do samego siebie nie będę już z tobą nigdy dyskutował.
>
Dyskutujemy włađnie z człowiekiem który twierdzi, ze access jest
najlepszy na świecie i niech się schowają wszelkie serwery SQL.
Doszedł do tego stanowiska z powodu "bezsensownych" testów w których
rzeczywiście Access jest najlepszy. Dlatego jeśli ktoś przychodzi i mówi
że sprawdził i w rzeczywistości to Słońce krąży wokół Ziemi to powinien
od razu podać źródło i metodykę testów. Źródło danych jest bardzo ważne
- równie dobrze podczas egzaminu z historii możesz się powołać na
Wołoszańskiego - od razu masz egzamin w plecy. Praktycznie dla każdej
bazy danych da sie wydumać takie testy, które sprawią ze konkurencja
wysiądzie (jak chociażby "równe" warunki testu - access na komputerze
lokalnym i FB na zdalnym, testowanie serwera Oracle z nieaktualnymi
statystykami, albo uśrednianie wyników z 10 tych samych zapytań na FB
uruchamianych jedno za drugim).
Co więcej nie da sie powiedzieć która baza jest najlepsza, lub
najszybsza - to nie bieg na 100m. W zależności od zastosowań - liczby
danych, równoczesnych użytkowników, rodzaju instrukcji, itd. itp. bazy
sprawdzają się raz lepiej raz gorzej. Dlatego dobiera się bazy danych
pod zastosowanie, a administratorzy potrafiący w pełni wykorzystać
możliwości bazy danych są w cenie. Dodam też, że nie widziałem w żadnym
szanującym się piśmie zestawienia baz danych w rankingu pt. najszybsza.
Jak już to drukowane zestawienia wyników różnych zapytań, przy różnych
parametrach baz danych - czyli masa różnych tabel i tabelek, a i wówczas
pisano że wyniki są orientacyjne, bo przy innych warunkach niż w teście
wyniki mogą wyjść znacząco różne.
--
Andrzej Dąbrowski
Technical Team (Poland)
Embarcadero Partner,
phone +48 (22) 864 14 65
d'plus
> d'plus pisze:
>> wloochacz pisze:
>>> [ciach]
>>>> nie no racja. na każdą bazę znajdzie się odpowiedni test. tamten był
> Co więcej nie da sie powiedzieć która baza jest najlepsza, lub
> najszybsza - to nie bieg na 100m. W zależności od zastosowań - liczby
> danych, równoczesnych użytkowników, rodzaju instrukcji, itd. itp. bazy
> sprawdzają się raz lepiej raz gorzej. Dlatego dobiera się bazy danych
> pod zastosowanie, a administratorzy potrafiący w pełni wykorzystać
> możliwości bazy danych są w cenie. Dodam też, że nie widziałem w żadnym
> szanującym się piśmie zestawienia baz danych w rankingu pt. najszybsza.
> Jak już to drukowane zestawienia wyników różnych zapytań, przy różnych
> parametrach baz danych - czyli masa różnych tabel i tabelek, a i wówczas
> pisano że wyniki są orientacyjne, bo przy innych warunkach niż w teście
> wyniki mogą wyjść znacząco różne.
racja, ale w pewnych bardzo typowych zastosowaniach porównanie może być
wykonane. bardziej zaawansowane testy potrafią być bardziej
niejednoznaczne jak słusznie zauważyłeś.
nie mam ochoty ciągnąć już tego tematu. dla mnie tak naprawdę
najważniejsza jest znajomość danej bazy i tym się kieruję przy wyborze.
bo jak sam pisałeś, dużo zależy od tego nie CO, tylko JAK się to robi.
EOT
wloochacz
> wloochacz pisze:
>> d'plus pisze:
>>> wloochacz pisze:
>>>> [ciach]
>>>>> a już myślałem, że komuś poleci 200k. buuuu
>>>>>
>>>>> co do procedur składowanych to największy jest zysk gdy praca jest
>>>>> sieciowa LAN, WAN, VPN itd..
>>>> Nieprawda;
>>>> poza tym z raczej SZBD inaczej nie pracują, jak serwer dostępny
>>>> zdalnie...
>>>
>>> SZBD? Znaczy że RDBMS łączy się z bazą poprzez interfejs sieciowy a
>>> nie bezpośrednio? Jeśli już, to ten interfejs będzie jako local
>>> loopback co w porównaniu z 100M/1GB LAN-em i tak będzie gigantyczną
>>> róznicą.
>> Dalej się nie zgadzam, bo to nam tylko mówi o tym że szybciej/wolniej
>> wysyła się duuuże ilości danych z serwera do klienta i odwrotnie.
>> A cały myk polega przecież na tym, aby minimalizować ruch sieciowy.
>
>
> jakoś wogole nie mogę zrozumieć twojego toku myslenia.
> wlasnie piszę, że nie ma de facto ruchu sieciowego bo procedura
> wbudowana komunikuje się RDBMS->WIRTUALNY INTERFEJS->DB (jeśli już -
> osobiście nie wierzę, że tak to się odbywa).
Tak się to nie odbywa, za wyjątkiem sytuacji specjalnych; mam na myśli
operacje na zewnętrznych źródłach danych w stor procu.
> A gdy procedura jest wykonywana przez klienta to leci to poprzez
> fizyczny interfejs i obkładana jest pierdoałmi typu kontrola transmisji
> i ograniczenia fizyczne w najlepszym przypadku, w najgorszym leci 400km
> poprzez WAN i przepycha się przez kilkanaście routerów, switchy i kabli.
Znaczy Chodzi Ci o procedurę w aplikacji, której efektem ma być to samo
co wynikiem działania procedury na serwerze bazodanowym?
I twierdzisz, że używanie StorProców ma największy zysk, jeśli działamy
ze zdalnym serwerze, zwłaszcza na wolnym łączu z nim?
Ciekawe podejście, któremu nie sposób odmówić jakiejś tam logiki.
Zapewniam Cię, że zalet jest znacznie więcej - a podstawową jest sam
język SQL i relacyjne bazy danych zorientowane na przetwarzanie zbiorów
danych. To co w app wymaga stosowania pętli, tu robi się jednym poleceniem.
Tylko pewnie to wiesz, a jak nie wiesz to po co zabierasz głos?
>>>>> składowanie procedury jest przydatne gdy serwer jest mocniejszy niż
>>>>> klient - wtedy przechodzi praktycznie wszystko na jego barki.
>>>>> ja ostatnio zoptymalizowałem procedurę 10-cio krotnie przekładając
>>>>> ją do bazy, no ale to był Oracle.
>>>> A jakie to ma znacznie, że to był Oracle?
>>>
>>> to, że nie był to Postgres o którym mowa i efekty nie muszą wcale być
>>> identyczne.
Będzie 20x szybciej?
>>>>> teraz staram sie większość dużych operacji wrzucać do bazy.
>>>>>
>>>>> moja rada to Oracle XE lub MySQL jak koledzy powiedzieli. To są
>>>>> liderzy wydajności a nie postgres.
>>>> Taaak?
>>>> Ciekawe, to znaczy że TPC kłamią jak z nut?
>>>> http://www.tpc.org/tpce/tpce_perf_results.asp
>>>> http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
>>>> Są jeszcze inne SZBD obok Oracle...
>>>>
>>>
>>> już to widzę, jak przenoszą system z Accessa na AIX 5 i DB2, albo
>>> kupują 16 core-ową maszynę.
>> A po co?
>> Do tego co im potrzebne, to najprawdopodobniej spokojnie da radę
>> dowolny SZBD.
>
> strzał w stopę? to ty przedstawiłeś te high-endowe maszyny jako dowód,
> że powinno się wybrać rozwiązania inne niż oracle.
> jak tutaj kolega przedstawił inny test to jasno widać, że w mniejszych
> (tańszych) rozwiązaniach lideruje oracle 11g/10g i pewnie tym samym jego
> młodszy brat Oracle XE.
> Test mało znaczący dla tej dyskusji bo nie testuje wogóle baz typu MYSQL
> i PGSQL a jedynie enterprise-owe wersje najdroższych baz testowane
> zapewne również z użyciem wszelkich mozliwych funkcji dodatkowych jak
> triggery i procedury wbudowane. tutaj debata chyba się toczy nad
> optymalizacją procesów insert/update.
Chodzi mi tylko o jedno Twoje zdanie: "moja rada to Oracle XE lub MySQL
jak koledzy powiedzieli. To są liderzy wydajności a nie postgres"
To oczywista nieprawda, bo wydajność to rzecz względna.
>>> W popularnych i tanich zastosowaniach prym wiodą Oracle XE i MySQL.
>>> Widziałem gdzieś test, którego nie jestem niestety w stanie przytoczyć.
>> A ja jestem pewien, że prym to wiedzie MS SQL Express.
>> MS SQL Express ma ciut mniejsze ograniczenia.
>> Podaj mi jakiś przykład oprogramowania in-the-box, które jest
>> rozprowadzane z Oracle XE (poza Compiere ;)); bo pod MS SQL Express
>> jest tego na tony.
>
> miliony much też mają rację?
> z VS dostajesz natywną obsługę MS SQL i pewnie dlatego jest tak szeroko
> popularne wsrod oprogramowania półkowego. Soft półkowy zazwyczaj nie ma
> również wielkich wymagań dlatego pewnie nie ma tutaj znaczenia DB.
Oczywiście, znowu mijasz się z prawdą.
Chodziło mi właśnie o "popularne i tanie zastosowania", w których to nie
Oracle XE wiedzie prym...
>> A MySQL?
>> Sorry, ale jak włączy się obsługę transakcji, triggerów, procedury to
>> niewiele zostaje z legendarnej szybkości MySQL'a.
>> Fakt - jest popularny ale jako backend rozwiązań webowych.
>
> ja mowilem o teście, to nie moje widzimisię. być może ktoś go jeszcze
> widział. pierwszy był oracle, drugi mysql, a potem reszta.
--
wloochacz
wloochacz
>>> nie no racja. na każdą bazę znajdzie się odpowiedni test. tamten był
>>> na dosyć powazanej witrynie i opierał się raczej o proste operacje
>>> bez wielu dodatków po drodze.
>> Tylko dlaczego nikt tego testu nie widział?
>> Albo podaj źródło, albo przestań pitolić...
>>
>
> tym postem potwierdziłeś moje przypuszczenia co do twojej osoby.
> z szacunku do samego siebie nie będę już z tobą nigdy dyskutował.
Może powinieneś przewartościować szacunek do swojej osoby, gdyż
twierdzenie "że gdzieś/kiedyś na jakiejś poważnej witrynie coś
przeczytałem i na pewno tak jest" nie robi na nikim wrażenia.
Ale po co ja to piszę w ogóle...
--
wloochacz