wyłączanie śledzenia wątków

dzizas ze tez wam sie chce....

No widzisz, ja mam braki teoretyczne powiadasz, a ty masz praktyczne i wierz mi, ze wole je miec nic snuc niestworzone historie sprzeczne z tym co sie robi jak sie robi itd po co mi wiec czytanie kolejnych ksiazek skoro wiem co i jak dziala i dlaczego w praktyce? ale dosyc szkoda czasu to pewne

Cytat:

Hmm. A co ma CPU w komputerze klienta do czasu jaki podaje forum przy każdej generacji strony?

sorry ale z tym na koniec to sie nie powstrzymam i zareaguje w jedyny mozliwy sposob na twoje specyficzne branie kazdego zdania doslownie, wiec na dobranoc:

hmm, ciekawa dyskusja mnie ominela chyba
tak tylko wtrace co do transakcji - najpopularniejsza i jedna z najszybszych baza czyli MySQL 'dostala' obsluge transakcji dopiero w obecnej zalecanej stabilnej wersji 3.23 (wprowadzenie nowego typu tabel BDB) ale nadal naszybszy i domyslny dla MySQL jest typ tabeli MyISAM, ktory transakcji nie ma

Nogal napisał:

ilosc porownan nie zalezy od ilosci kluczy - wynosi ona zawsze 2. OK ide spac - dosyc emocji na dzisiaj

Musze Cie rozczarowac, ale jesli chcesz miec tablice haszujaca, ktore w 2 porownaniach zawsze znajduje wartosc, to jej wielkosc musialby byc rowna polownie maksymalnej ilosci wartosci, jakie chcesz tam umiescic
Wiec wielkie SRY, ale takich cudow nie ma.

To, ile jest wymaganych obliczen do znalezienia wartosci, zalezy od typu funkcji haszujacej i sposobu segregowania przy takich samych wartosciach funkcji haszujacej (najczesciej sa umieszczane na liscie)
Gdy mamy tyle rekordow w tablicy haszujacej, co jej wielkosc, to sredni koszt znalezienia klucza w niej wynosi O(log n).
Gdy zapelnienie wzrasta, koszt wzrasta rowniez...

no własnie miałem to napisać ale dopiero sie obudziłem (w końcu dyskutowałem do 4 nad ranem i mnie uprzedziłeś

Gregor, dla Richiego to nie ma znaczenia czy są transakcje czy nie bo to wymysł teoretyczny nie sprawdzający się w praktyce podobnie jak JOINy

zastanawialem sie troche nad ta iloscia zapytan i rozbijaniem na drobne tego co mozna by zrobic jednym wiekszym, niestety nie mam czasu pogrzebac w dokumentacji wiec rzuce tylko taka mysl i powiecie czy to ma sens czy nie
otoz wg mnie moze jest tak ze duze zapytanie do kilku tabel jednoczesnie moze blokowac dostep do tych tabel dla innych userow a kilka malych zapytan blokuje pojedyncze tabele i to na krocej - efekt jest taki ze z punktu widzenia jednego usera operacja moze wykonuje sie troche dluzej ale moze takie podejscie jest kozystniejsze dla wielu userow kozystajacych z bazy w tym samym momencie (jak mowie sa to tylko moje domysly)

Gregor, ciekawa myśl, ale jak to musi wkurwiać wszystkich egoistów.

Hmm. DObrze kombinujesz. Na to nie wpadłem. Jest prawdopodobne że przy równoczesnym odwoływaniu się do bazy przez wielu użytkowników w celu wyciągnięcia dużej ilości danych, obciążenie systemu będzie na tyle duże, że czas oczekiwania na zwolnienie zasobów wzrośnie do wartości gdzie, lepiej będzie rozbić zapytania.
Pytanie czy z takich założe wyszli twórcy phpBB.
1. baze projektuje sie albo na komputery wydajne albo zakłada się że będą chodziły na P133MHz -wtedy opóźnienie może być duże
2. ważny jest data flow rate. przy wyciąganiu dużych ilości danych też może to mieć znaczenie gdy system ma wolne dyski, pamięci, procesor ew. sieć gdy DB nie stoi na tym samym kompie co server front-end.

W wypadku phpbb nie sądze aby ilość danych transferowanych z/do bazy miała jakieś znaczenie.
Pozostaje tylko ten pierwszy czynnik. I jesli phpbb był projektowany przy dla naprawdę wolnych i/lub bardzo obciążonych komputerów to pewnie poparli to testami i faktycznie wybrali optymalne rozwiązanie. Co jednak wciąż nie zmienia faktu, że wybrali drogę mniej bezpieczną dając szansę postawienia bazy na tanich kompach z 'demobilu'.

BTW: właśnie się dowiedziałem (ale sam nie sprawdziłem) że w Oracle'u nie ma JOIN'ów. Ale nie ma co się śmiać. Za to są relacje definiowane na poziomie bazy danych.

IMHO to Gregorowi chodzilo o to, ze phpBB zostalo zaprojektowane zeby obslugiwac kilka-kilkadziesiat tysiecy userow a wtedy trzeba barc pod uwage, ze jednoczesnie moze byc ich nawet kilka tysiecy w tej samej chwili.

A skąd ten pomysł, że zapytanie do tablicy powoduje jej zablokowanie dla innych userów ???

Nie sądze aby chodziło o zablokowanie tablicy w sensie zablokowania do niej dostępu a raczej o obciążenie silnika bazy danych. Bo tak naprawdę nigdy nic nie wykonuje sie równocześnie. Stąd przy mało wydajnych systemach opóźnienia mogłyby się potęgować.
Choć to tylko ciągle przypuszczenia. Może jest właśnie tak że złożone zapytanie nie dość że jest szybsze to obciąża bazę mniej niż wiele pojedynczych. Ale tu się nie wypowiem bo nigdy tego nie sprawdzałem.

przy zapisie do bazy to chyba jasne ze jest blokowany dostep (do calej tabeli lub do 'pages' - grupy rekordow jesli baza to obsluguje)
a jesli przy wyslaniu postu 'na szybko' powoduje 22 'queries' to pewnie duza czesc z nich to zapis (przy odczycie zreszta tez sa uaktualnianie jakies statsy itp)
a z tego co sie orientuje to 'row-lewel loking' jest dopiero wprowadzane w wersji 4.xx MySQL wiec tak czy inaczej blokowanie tabel moze byc problemem
mam zreszta nadzieje ze niedlugo przejdziemy na 4.xx gdzie jest tez wprowadzane keszowanie zapytan (w przypadku forum leci pewnie mnostwo identycznych) ktore ma przyspieszyc dzialanie nawet do 200% w skrajnych przypadkach

Gregor, a obecny MySQL 4.x ma jeszcze jakies poważne braki czu mozna go już instalować zamiast 3.23? Drażni mnie parę głupich wręcz braków w 3.23. Np. mimo istnienia funkcji YEAR i MONTH nie jest zaimplementowana funkcja DAY. No i inne takie....

ostatnia wersja 'stable' to 3.23.54a
a wersja 4.0.7 to jest wersja gamma - w pelni funkcjonalna ale ciagle w trakcie rozwoju
choc pewnie i tak juz w tej fazie stabilniejsza od produktow M$ w wersji do sprzedazy
wiecej na: www.mysql.com