🚀 go-pugleaf

Jacek Szpyrka wrote:
> 
> Gracjan Ziółek napisał(a) w artykule
> <345DF500.6778@celebris.bdk.lublin.pl>...
> 
> >Jacek Szpyrka wrote:
> >>
> >> Robert Maron napisał(a) w artykule <63fe2s$50l$4@domek.slodki.domek>...
> >>
> >> >nie rozumiem, po co merdzowac dlugie rekordy? jak dlugie, to zawsze
> >> >sortujesz wskazniki, to chyba oczywiste...
> >>
> >> Racja, moja wina (tu trzy uderzenia w klatkę piersiową).
> >
> >No to ja już nie muszę się odzywać. Jacek chyba (bez obrazy..) mało
> >pisze w C :). Tam w takim przypadku najpierw przychodzą do głowy
> >wskaźniki, dopiero potem 'że można inaczej' :)
[...]

> 1. Codziennie przez 8 godzin programuję w C++ w pracy i nie jest to proste
> programowanie interfejsów a projektowanie i analiza algorytmów.

W fazie projektowania nie myśli się jeszcze o sposobie reprezentacji
zmiennych (np. wskaźniki). To na pewno dlatego ;)

[...]

> Jeżeli chodzi o merge-sort to oprócz wskażników trzeba sortować od razu
> klucze bo inaczej i tak trzeba będzie wiele razy czytać z bazy.

Nikt nie zgłasza sprzeciwu :)

> Wydaje mi się że przy odpowiednio dużym stosunku ilości rekordów do
> ilości dostępnego ramu b-drzewa jednak wygrywają. Chociaż przy
> stosowanych dzisiaj powszechnie ilościach pamięci musiało by to być
> NAPRAWDĘ DUŻO rekordów.

Zdaje się, że to miało być kilka(naście?) milionów rekordów. Czy to
dostatecznie dużo? Poza tym, nie każdy system inny niż PC w domu pozwoli
uzytkownikowi (jednemu z kilkudziesięciu) skorzystać z 90% pamięci.
Wcale nie uważam za pozytywne myślenia typu 'eee, mam duzo RAMu, to se
mogę pakować tam, co chcę'. Może i pod DOSem takie myślenie się
sprawdza, ale to już prawie historia :).

	pozdrawiam

-- 
gracjan ziółek
administrator systemów
mailto:gzio@celebris.bdk.lublin.pl
http://ajax.umcs.lublin.pl/~gracjanz/