🚀 go-pugleaf

On 2013-05-13 12:05, M.M. wrote:
> W dniu poniedziałek, 13 maja 2013 09:59:47 UTC+2 użytkownik Michal Kleczek napisał:
>
>> W calym watku to sie pojawia wielokrotnie:
>> 1. twoje rozwiazania tego nie zapewniaja bo operuja na poziomie systemu
>> plikow - a od systemu plikow do fizycznego rozlozenia danych na
>> nosnikach jeszcze baaaaaaardzo daleka droga
> Czy potrafisz to jakos uzasadnic?
>

Tak, ale nie chce mi sie, bo to oczywista oczywistosc dla kogokolwiek, 
kto ma chocby blade pojecie co to jest i jak dziala system plikow oraz 
czym "plik" tak naprawde jest.

>
>> 2. DBMS jest dokladnie pod to projektowany, by minimalizowac ilosc
>> operacji we/wy przy dostepie do danych
> Tu na pewno mylisz sie. Pisalem w tym watku kilka razy, napisze jeszcze raz:
> projektowany jest po pierwsze pod ogolny przypadek. Poza tym projektowany
> jest pod wygode, elastycznosc, bezpieczenstwo, transakcje, wielodostepnosc
> itd. Minimalizowanie operacji we/wy ma ktorys z kolei priorytet.
>

Jasne. I dlatego wlasnie ktos wymysla struktury danych typu B-drzewa - 
specjalizowane wlasnie w celu minimalizacji ilosci operacji we/wy.

>
>> Wziac dobry (odpowiedni do zastosowan) DBMS. NIE probowac robic "lepiej".
> Nie mam bladego jak uzywasz slowa "lepiej", pewnie zupelnie inaczej niz ja.
>
>
>> Kazdy indeks jest po to, zeby minimalizowac czas dostepu do danych.
>> Rozne rodzaje indeksow sa przeznaczone do
>> a) roznego rodzaju dostepu
>> b) roznych rodzajow danych
>> Sa rozne rodzaje indeksow. Na poczatek:
>> http://en.wikipedia.org/wiki/Database_index
> A jesli dane sa rozrzucone po dysku, to zaden indeks nie pomoze i
> trzeba zrobic tyle odczytow, ile jest danych, prawda?
>

_Zawsze_ trzeba odczytac przynajmniej tyle, zeby potrzebne dane z dysku 
wczytac do pamieci. Kwestia jest jak te dane na dysku znalezc, zeby 
zminimalizowac koniecznosc niepotrzebnych dodatkowych odczytow.

Przyklad z twoim plikiem CSV posortowanym po dacie. Zalozmy, ze zawiera 
N rekordow. Pierwszy ma w kolumnie daty wartosc 2001-01-01. Ile potrzeba 
odczytow, zeby znalezc rekordy z data 2011-02-23?

>
>> Trzymanie danych "obok siebie" niekoniecznie jest najlepsza strategia.
> Dobrze rozumiem: Niekoniecznie, czyli może być najlepszą?
>

Moze.

>
>>> Clustered mozna
>>> zakladac tylko na jedno pole, wiec odpada, prawda?
>> Nieprawda.
> Czytalem ze tylko na jedno, no ale dobra. Wiec pytanie: jak w bazach
> jest realizowany clustered na więcej niż jednym polu?
>

Nie rozumiem pytania... Tak samo jak na jednym.

>
>
>> Jestem - probuje ci chyba bezskutecznie uswiadomic, ze proponowane przez
>> ciebie rozwiazania to nic innego jak indeksy w DBMS.
> Moze sie mylisz? Moje rozwiazanie w jednym programie potrzebuje kilku
> sekund a na sqlite trwalo 90 minut na nieplnej bazie.
>

Mozesz pokazac kod jednego i drugiego? W szczegolnosci strukture bazy i 
zapytanie?
Bo jesli masz taka roznice, to znaczy, ze cos straszliwie schrzaniles.

>
>
>> Prawie na pewno szybciej, niz zrobi to kod pisany przez ciebie.
> Tez to pisalem wiele razy. Nie chodzi o sciganie sie z baza danych
> na poziomie samego kodu. Chodzi jeszcze o sciganie sie na poziomie
> stuktur danych.

Dokladnie :-)

--
Michal