Opiniowanie pakietow -- baza danych i nie tylko

[Paweł Kołodziej]

Dnia Fri, Jan 26, 2001 at 12:00:47PM +0100, Michal Moskal napisał(a):
> On Thu, Jan 25, 2001 at 08:25:05PM +0100, Paweł Kołodziej wrote:
> > Hej.
> > Jesli bedziemy robili to na sql'u (moim zdaniem powinnismy) to proponuje
> 
> Znaczy jest taka sprawa: IMHO sql to overkill. Zanim o nim mówiłeś
> ja już miałem napisany kawałek bazy. W db3 + own directory...

Powiem tak: jeśli chcesz się pobawić w pisanie engine bazy danych
praktycznie od początku (db3 mimo, że dobry do wielu zastosowań, jest
jednak niemiłosiernie prymitywny), to niema sprawy. Mozna to robic na db3,
czy nawet pliku tekstowym. Pójście tą drogoą, wymaga pisania praktycznie 
wszystkiego w C [1], kod będzie spory w związku z tym będzie w nim sporo
błędów, a dodanie nowej funkcjonalności często niemołosiernie ucążliwe.
Wkońcu ludzie po to rozwijają bazy danych, żeby móc za ich pomocą tworzyć
inne narzędzia. To jak z libc -- niby do kazdego programu mozna by pisac
swojego, wlasnego libc. Mozna, ale poco ?!

> może powinienem się pouczyć sqla... jeśli będą silne protesty to spróbuje.

sql nie jest taki straszny. Praktycznie na początek wystarczy ci dwa
polecenia "insert" i "select". To naprawdę nie jest czarna magia, a
kożysci olbrzymie. Uwież mi. sql wydaje się być w tym przypadku optymalnym
wyborem. W takim db3 nie ma nawet jak indeksów zrobić (bo i nie do tego
została stworzona).


> w poniedziałek postne co napisałem, o protesty proszę dopiero wtedy :)

ok. 

> > taka srtukture bazy:
> > 
> > Tabela: osoby
> > ID, imie, nazwisko, ksywa, email, status
> > (status czyli liczba okreslajaca status użytkownika: "user", "operator",
> > "zaufany user" );
> > 
> 
> u mnie jest s/ksywa/login s/imie nazwisko/real_name... ale to szczegóły.

jasne. nie chodzilo mi o dokladne nazwy pol w bazie, a jedynie charakter
przechowywanych informacji.

> 
> nie ma statusu, jest access flags. tzn. string z capbilities,
> tak jest chyba lepiej.

moze byc i tak.

> > - tabela pakiet_funkcja opreśla jakiemu pakieteowi sa przypisane jakie
> >   funkcje
> 
> tzn. jedna funkcja może być przypisana więcej niż jednemu
> pakietowi? bo ja mam ficzery jak podobietk pakietu.

"upgrade z poprzedniej wersji"
"sktrypty preinst"

Wtedy jak ktos ma ochote popracowac na upgradeami pakietow z poprzednich
wersji to bierze sobie jedna statystyke zawierajaca opinie dotyczace
funkcji o numerze jakims tam.  Jesli zrobimy wiele tabel z opisami funkcji
w wielu jezykach i w kazdej az nich funkcja o takiej samym znaczeniu
bedziem miala taki sam numer, i koles bedzie tez mogl uwzglednic opinie
obcokrajowcow.

> > - tabela srosdwisko informauje o zainstalownaych przez usera innych
> >   programach wymaganych przez dany
> > - IDkompa do numerek natawany przez nas komputerom (bo jeden user moze
> >   miec kilka kompow). Nie ma potrzeby przechowywania tych numerow w
> >   osobnej tabeli, bo nie jest z nimi powiazana zadna informacja (no chyba
> >   ze bedziemy trzymali jakies info o kompach (procek, cos takiego).
> 
> to chyba na przyszłość.

tzn. co na przyszlosc ? IMHO obie pozycje sa raczej konieczne.

> > - mylse ze spokojnie mozna rozdzielic pobieranie danych (od strony
> >   serwera) od wysylania ich do klienta, i robienia statystyk. W takim
> >   ukladzie kazda czesc moze byc pisana w czym innym.
> 
> nie jestem pewien. tzn cześć logiki jest wspólna. np.
> wysyłanie informacji o zainstalowanych pakietach.

wysylanie przez klienta. A przeciez klient jest jeden. W nim nic nie
rozdzielam. Od strony serwera to operacje praktycznie niezależne.

[1] żeby była jasność. Bardzo lubie C (to mój ulibiony język), ale nie na
    siłe.

-- 
Paweł Kołodziej 
pawelk w pld.org.pl 
,,O ile nam wiadomo, komputer nigdy nie popełnił niewykrytego błędu.''
                                                 -- Weisert