🚀 go-pugleaf

Maciej "MACiAS" Pilichowski napisał(a) w wiadomości:
<37074e65.5708883@rymunda.torun.pdi.net>...
>
>> (pola idpojazd, iddcechy, wartosc) (wartosc najlepiej jako
>>string i robic konwersje)
>>1, 1, 2 (trek - dlug, 2 m)
>>1, 2, $FF002345 - (trek, kolor- kosc sloniowa)
>
>Ok, czyli tutaj mamy wlasciwie spis pojazdow, ktore sa np. w miescie,
>bez mowienia kto jest ich wlascicielem.
>Na razie jednak to rozwiazanie juz w tym punkcie lapie minusy:
>- pole jest string i trzeba dokonywac recznie konwersji
>- id pojazdu nie moze byc autoincrement, i musze robic to
>wlasnorecznie, czego sie troche boje ;-))) /aczkolwiek kiedys musi byc
>ten pierwszy raz/

Id pojazdu nie ma być autoinkremet bo ma wskazywać na pojazd z tabeli
pojazdy. Tylko tam to pole ma być autoinkrement.

>Ok, czyli wlasciwie tu mam zdefiniowane, czyj pojazd jest kogo. Tyle
>ze w tym punkcie dochodzi nastepna wada:
>- jeszcze wieksze rozdrobnienie niz pierwotnie
>Doszedlem do sytuacji w zasadzie gorszej, bo musze spiac 3 tabele.

No coż coś za coś, ale wg mnie to 3 tabele to nie problem. Wg mnie problem
to 33 tabele spięte razem - z tym też można dać sobie radę. Śledząc już o
dłuższego czasu twoje wypowiedzi dochodzę do wniosku że jednocześnie chcesz
być minimalistą (wszystko ograniczyć do minimum, także swoją robotę hehe) i
perfekcjonistą (żeby było porządnie dla samego istnienia porządku). Moim
zdaniem te dwie rzeczy jest ciężko pogodzić korzystając z czegoś co ktoś
napisał. Bo jeśli ktoś coś zrobił porządnie tzn, żeby było minimalistycznie
jeśli chodzi o nakład pracy użytkownika to nie będzie perfekcji gdyż z
założenia będzie to zbyt rozbudowane i dające zbyt wiele możliwości czyli za
głupie. Można z kolei pisać wszystko samemu od podstaw wtedy będzie w
naszych oczach perfekcyjnie ale minimalizmu w przypadku nakładu pracy się
nie osiągnie.
Dlatego moim zdaniem trzeba ustalić jakiś "konsensus" - trochę dać z siebie
resztę wyciągnąć z gotowców.
Ze zdaniem czy 3 tabele są gorsze niż 2 podejrzewam, że wielu ludzi na tej
grupie (piszących bazy) mogłoby długo polemizować..... Nie zawsze mniej
znaczy lepiej. Wcale przy tym nie uważam, że rozdrobnienie jest pozytywne,
ale rozdrobnienie nad którym się panuje i wie się co z tym zrobić ma sens.

>Przykladowo chcialbym uzyskac /posortowanego po wlasciecielu/ grida z
>samochodami o kolumnach:
>wlasciciel, marka samochodu, kolor, masa, i reszta cech samochodowych
>Wlasciciela odsortuje, to jest latwe. Ale co z reszta?


Tu rzeczywiście jest problem. Bez robienia dodatkowego zapytania i obróbki w
pamięci kompa lub bez jakiegoś krosstaba będzie cienko. Ja to robię w swoim
programie po swojemu bo wiem czego szukam - w jeden ściśle określony sposób.
Jeśli ty zaś chcesz zachować elestyczność czyli dać możliwość użytkownikowi
sorta na wiele sposobów to będzie niewesoło. Zrobić się na pewno da ale
roboty masa.

>No i teraz tak -- jesli mi podpowiesz tutaj z tym sortowaniem, to
>jednoczesnie, nie obrazaj sie, w/w rozwiazanie bede uwazal za gorsze.
>Bowiem tak jak Ty tu, tak jak u siebie zrobie sortowanie, bo typ
>spinania jest taki sam, a baz-posrednikow jest mniej. Jednoczesnie nie
>mam zadnych klopotow z konwersja i nie musze ingerowac w
>autoincrement. Bazy sa mniejsze i struktura /ale to juz IMHO/ jest
>prostsza.

No cóż nie obrażam się. Podesłałem ci tylko jedno z możliwych rozwiązań.
Natomiast do dziś uważam, że i to rozwiązanie ma swoje zalety. W mojej
bazie, o której już pisałem, mam zdefiniowane wykonywane analizy i
zmieniając jedynie słownik analiz mogę dodać nowe (a nie wiem co
laboratorium wymysli w przyszłości) oraz zmieniać ich przyporządkowanie do
różnych grup bez ingerencji w sam program. Gdybym zdefiniował je (analizy)
jako pola jednej bazy to dołożenie nowej analizy oznaczałoby rekonstrukcję
głównej tabeli a to juz problem.
Wcale nie uważam że dla ciebie to rozwiązanie jest najlepsze, ba nawet
dobre, ale na tym polega dyskusja.


--
Janusz Dziadoń
j.dziadon@bph.krakow.pl