W dniu poniedziałek, 6 maja 2013 01:02:51 UTC+2 użytkownik M.M. napisał:
> W dniu poniedziałek, 6 maja 2013 00:39:18 UTC+2 użytkownik firr kenobi napisał:
>
> > W dniu niedziela, 5 maja 2013 22:06:51 UTC+2 użytkownik M.M. napisał:
>
> > > glowicy na dysku, ale nie wiem czy wiekszosc to 95%, czy moze 60%. Jesli
>
>
>
> > dyski maja cache w ram - i kiedys
>
> > pisalem jak to ladnie dziala, np
>
> > pierwsza kompilacja blisko 10 s
>
> > a kolejna 1 s, innym razem o tym
>
> > ze dostep z cache jest niewiele
>
> > wolniejszy niz memcopy ) wydaje sie
>
> > wiec ze to cache powinno dzialac
>
> > zwlaszcza ze wspolczesne kompy maja
>
> > sporo ramu - czyzby nie dzialalo ?
>
>
>
> Dziala i to na tyle dobrze, ze przyspieszenie widac golym okiem.
>
>
>
> Problem w tym, ze danych moze byc 100 razy wiecej niz pamieci
>
> RAM w jednym kompie. W takim przypadku "statystyczny bufor"
>
> raz zadziala dobrze, drugi raz zle. Zwykle algorytm buforujacy
>
> musi byc dostosowany do aplikacji.
>
>
>
> Teraz z innej beczki:
>
> Odczyt z dysku jest szybki, naprowadzania glowicy
>
> wolne. Na dysku lezy duza tabela, zawiera recepty pacjentow. Recepty
>
> moga byc porozrzucane losowo. Gdy chce recepty Xa, to naprowadzam
>
> glowice nad kazdy rekord z recepta i odczytuje. Gdy chce recepty
>
> Ya, to robie to samo. Mozna wiec zmienic kolejnosc recept, tak aby
>
> obok siebie lezaly recepty tego samego pacjenta. Ale gdy bede
>
> chcial recepty z 5-maja, to napotkam ten sam problem, w innej
>
> postaci. Indeksy rozwiazuja problem przeszukiwania calej tabeli, ale
>
> nie rozwiazuja problemu gdy rekordy sa losowo porozrzucane.
>
>
>
> Czy w bazach danych (w systemach operacyjnych?) sa standardowo
>
> implementowane jakies rozwiazania tego problemu? Gdybym mial
>
> recznie cos takiego rozwiazywac, to chyba bym zrobil dwie kopie
>
> tabeli, w jednej bym posortowal po nazwiskach, w drugiej po dacie.
>
>
>
> Oczywiscie wplata sie w to wszystko koszmarny problem, a mianowicie
>
> spowolnienie operacji usuwania i edycji pola po ktorym tabele zostaly
>
> posortowane. Wiec moze optymalnym rozwiazaniem jest zrodlo danych na
>
> XML czy CSV a nie na tabelach rekordow? Z pliku CSV mozna latwo
>
> usunac recepte, mozna recepte przeniesc z jednego pliku do drugiego.
>
>
>
> Hmmm jakis czas temu byla dyskusja o rozwiazaniach NO-SQL, ale to
>
> o czym teraz napisalem, to chyba rozwizanie NO-TABLES? :D
>

cholera jasna, Znowu fatalnie sie czuje
(nie wiem nawet czy to nie nawrot boreliozy
bo znowu 3dni temu lazilem po jakichs
krzakach, znowu pogryzlo mnie chyba jakies
robactwo i znowu czuje masakryczny prąd galwaniczny w stawach - przerabane, ufam
jednak ze chyba az takiego pecha nie mam
bo sa to nieziemskie kłopoty)


co do tych baz/plikow to sluszna uwaga,
sa to jednak kwestie dot szczegolw
implementacji i poprawnego uzywania
baz danych i systemu plikow a ja nie
mam duzej wiedzy na ten temat

dysk+system plikow to jest w sumie rodzaj
bazy danych ale raczej nie oferuje on
wyszukiwania (*) - nie oferuje on tez
wlasnie
wspomnianych insertów i deletów (a moglby
bo przeciez klastry tworza linked liste
ale zdaje sie jest zle napisany i tego nie
obsluguje)

tak ze np wstawianie i deletowanie
takich recept ani na dysku ani w bazie
chyba nie moze byc szybkie

(*) i jak na dany moment nie jestem
pewien czy powinien za to obsluge insertowania i deltowania do srodku plikow
powinien obslugiwac raczej na pewno