🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: pl.comp.lang.delphi.bazy-danych
8 messages
8 total messages Started by Maciej "MACiAS" Pilichowski Wed, 31 Mar 1999 08:21
Bylo: podwojne filtrowanie -- przyklad [SQL]
#85
Author: Maciej "MACiAS" Pilichowski
Date: Wed, 31 Mar 1999 08:21
54 lines
2648 bytes
Hej,

  Moze podam przyklad o co mi chodzi, to bedzie latwiej. 

Mam sobie spis ludnosci -- jedna baza.

Mam spis typow pojazdow. W tejze liscie jest pole z nazwa dodatkowej
bazy danych zawierajacej specyficzne dane odnosnie pojazdu.

Mam liste wszystkich pojazdow. Sa tu takze pola odpowiadajace za cechy
wspolne pojazdow.

No i sa poszczegolne listy pojazdow -- samochodow, rowerow, motocykli.

Wazniejsze pola:
a) Spis ludnosci -- Id.
b) Spis typow pojazdow -- NazwaDodatkowejBazy.
c) Spis pojazdow -- IdWlasciciela, IdPojazdu /wskazuje na pojazd w
dodatkowej bazie/, IdTypuPojazdu.

Dzialanie wyobrazam sobie tak. Wybieram wlasciciela. Wybieram typ
pojazdu /np. samochod/. Pokazuje mi sie lista wszystkich samochod
goscia.

O ile wyrzucenie danych wspolnych dla pojazdow /np. liczba kol, kolor/
z listy pojazdow, to nie jest problem /Query1/:

SELECT * FROM lista_pojazdow WHERE (IdWlasciciela=Obywatele.Id) AND
(IdTypuPojazdu=ListaTypow.Id)

o tyle jest juz klopot z wyselekcjonowaniem z danej bazy dodatkowej
informacji. Idealem bylaby moznosc napisania

SELECT * FROM :NazwaDodatkowejBazy WHERE (Query1.IdPojazdu=Id)

przy ustawionym DataSource na liste typow pojazdow.

Jak na razie nie wpadam na zadne eleganckie rozwiazanie. Wstawienie do
Query2 tego co jest w Query1 do mnie nie przemawia. Moze bedzie tez
rozwiazaniem JOIN -- watek wyzej.

Prowizorycznie dorzucilem jeszcze jedno pole juz bezposrednio w
dodatkowych bazach pojazdow -- IdWlasciciela. Wtedy zapytanie dla
Query2 jest banalne. No, ale z kolei irytuje mnie nadmiarowosc danych.

Moze ktos podrzuci mi jakas ciekawa idee?

milego dnia zycze
hej
--
Maciej "MACiAS" Pilichowski              http://www.torun.pdi.net/~macias/
nowe klamoty w marcu: pieniadze publiczne, W I R U S  Happy99
     S P R Z E D A M : oryginalne gry HalfLife i Thief, streamer Jumbo250,
lornetke z zoomem, segment CD Technics, przeciwsloneczne okulary sportowe
Re: Bylo: podwojne filtrowanie -- przyklad [SQL]
#86
Author: Tomasz Rubaj
Date: Wed, 31 Mar 1999 10:04
79 lines
3373 bytes
Maciej MACiAS Pilichowski wrote:

>   Moze podam przyklad o co mi chodzi, to bedzie latwiej.
> 
> Mam sobie spis ludnosci -- jedna baza.
> 
> Mam spis typow pojazdow. W tejze liscie jest pole z nazwa dodatkowej
> bazy danych zawierajacej specyficzne dane odnosnie pojazdu.
> 
> Mam liste wszystkich pojazdow. Sa tu takze pola odpowiadajace za cechy
> wspolne pojazdow.
> 
> No i sa poszczegolne listy pojazdow -- samochodow, rowerow, motocykli.
> 
> Wazniejsze pola:
> a) Spis ludnosci -- Id.
> b) Spis typow pojazdow -- NazwaDodatkowejBazy.
> c) Spis pojazdow -- IdWlasciciela, IdPojazdu /wskazuje na pojazd w
> dodatkowej bazie/, IdTypuPojazdu.
> 
> Dzialanie wyobrazam sobie tak. Wybieram wlasciciela. Wybieram typ
> pojazdu /np. samochod/. Pokazuje mi sie lista wszystkich samochod
> goscia.
> 
> O ile wyrzucenie danych wspolnych dla pojazdow /np. liczba kol, kolor/
> z listy pojazdow, to nie jest problem /Query1/:
> 
> SELECT * FROM lista_pojazdow WHERE (IdWlasciciela=Obywatele.Id) AND
> (IdTypuPojazdu=ListaTypow.Id)
> 
> o tyle jest juz klopot z wyselekcjonowaniem z danej bazy dodatkowej
> informacji. Idealem bylaby moznosc napisania
> 
> SELECT * FROM :NazwaDodatkowejBazy WHERE (Query1.IdPojazdu=Id)
> 
> przy ustawionym DataSource na liste typow pojazdow.
> 
> Jak na razie nie wpadam na zadne eleganckie rozwiazanie. Wstawienie do
> Query2 tego co jest w Query1 do mnie nie przemawia. Moze bedzie tez
> rozwiazaniem JOIN -- watek wyzej.
> 
> Prowizorycznie dorzucilem jeszcze jedno pole juz bezposrednio w
> dodatkowych bazach pojazdow -- IdWlasciciela. Wtedy zapytanie dla
> Query2 jest banalne. No, ale z kolei irytuje mnie nadmiarowosc danych.
> 
> Moze ktos podrzuci mi jakas ciekawa idee?
> 
Moze troche przeprojektujesz baze? Jak to zrobic
Rozumiem ze dane specyficzne dla kazdego modelu sa pamietane dla kazdej
jednostki w osobnej bazie. 

Moze wygodniej bedzie trzymac te wszystkie unikalne cechy w jednej
tablicy o polach:
(moze IdWlasciciela)
IdPojazdu
(powyzsze pola to klucz)
NazwaCechy
WartoscTejCechy
Albo
(moze IdWlasciciela)
IdPojazdu
IdCechy

I jeszcze jedna osobna tabele z cechami. To jesli wiele samochodow moze
miec wiele wspolnych cech.
Dane o cechach pojazdu wyswietlasz w wierszach. Nie trzeba wtedy zadnego
brzydkiego
> SELECT * FROM :NazwaDodatkowejBazy WHERE (Query1.IdPojazdu=Id)

Jesli nie napisalem tego dosc jasno - odezwij sie na priva.

Poczytaj troche o projektowaniu relacyjnych baz danych. Postaciach
normalnych itd.
Jesli bedziesz sie trzymal pewnych zasad projektowania to na ogol nie
bedziesz popadal w problemy z "dziwnymi" zapytaniami, czy metodami
dodawania rekordow.


TRubaj
Re: Bylo: podwojne filtrowanie -- przyklad [SQL]
#87
Author: Maciej "MACiAS" Pilichowski
Date: Thu, 01 Apr 1999 10:28
52 lines
2375 bytes
Hej,

  Dzieki serdeczne za odpowiedz.

On Wed, 31 Mar 1999 12:04:25 +0200, Tomasz Rubaj
<trubaj_NoSpam@ajax.umcs.lublin.pl> wrote:

>Moze troche przeprojektujesz baze? 

Myslalem o tym, ale na razie nie wpadlem na zadne sensowne
rozwiazanie.

>Rozumiem ze dane specyficzne dla kazdego modelu sa pamietane dla kazdej
>jednostki w osobnej bazie. 

Dokladniej: w osobnej bazie danego typu jednostki.

Informacje o Treku, Giancie laduje w bazie o rowerach, a info o
Fordzie, VW laduja w bazie o samochodach.

>Moze wygodniej bedzie trzymac te wszystkie unikalne cechy w jednej
>tablicy o polach:
>NazwaCechy
>WartoscTejCechy

To odpada bo Cecha moze byc numeryczna, moze byc opisowa.

>IdCechy

Hmm...
Czyli mialbym jedna baze samochodowo-rowerowo-jakastam. No tak, ale
jesli tam od razu zaczne wpisywac cechy, to bede mial problemy z
nadawaniem IdPojazdu /nie moge zastosowac autoincrement, bo pare cech
musi byc od jednego pojazdu, a znowu jak dam integera, to sie boje,
czy podolam pracy w sieci/. Jak wyrzuce to do zewnetrznej bazy, co
likwiduje problem z IdPojazdu, to w zasadzie wracam do sytuacji
wejsciowej.

>Poczytaj troche o projektowaniu relacyjnych baz danych.

Gdzie? Bylem dzisiaj w ksiegarni. Pustki -- jedna ksiazka o SQLu,
ktora juz mam i 2 jakies beznadziejne.

No i jakie ksiazki.

milego dnia zycze
hej
--
Maciej "MACiAS" Pilichowski              http://www.torun.pdi.net/~macias/
nowe klamoty w marcu: pieniadze publiczne, W I R U S  Happy99
     S P R Z E D A M : oryginalne gry HalfLife i Thief, streamer Jumbo250,
lornetke z zoomem, segment CD Technics, przeciwsloneczne okulary sportowe
Re: Bylo: podwojne filtrowanie -- przyklad [SQL]
#88
Author: Tomasz Rubaj
Date: Thu, 01 Apr 1999 10:37
39 lines
1971 bytes
Maciej MACiAS Pilichowski wrote:

> 
> Dokladniej: w osobnej bazie danego typu jednostki.
> 
> Informacje o Treku, Giancie laduje w bazie o rowerach, a info o
> Fordzie, VW laduja w bazie o samochodach.
> 
> >Moze wygodniej bedzie trzymac te wszystkie unikalne cechy w jednej
> >tablicy o polach:
> >NazwaCechy
> >WartoscTejCechy
> 
> To odpada bo Cecha moze byc numeryczna, moze byc opisowa.
> 
> >IdCechy
> 
> Hmm...
> Czyli mialbym jedna baze samochodowo-rowerowo-jakastam. No tak, ale
> jesli tam od razu zaczne wpisywac cechy, to bede mial problemy z
> nadawaniem IdPojazdu /nie moge zastosowac autoincrement, bo pare cech
> musi byc od jednego pojazdu, a znowu jak dam integera, to sie boje,
> czy podolam pracy w sieci/.
Przynajmniej jesli chodzi o paradoxa w sieci to jest odwrotnie.
Autoincrement rozjezdza sie najbardziej.

> Jak wyrzuce to do zewnetrznej bazy, co
> likwiduje problem z IdPojazdu, to w zasadzie wracam do sytuacji
> wejsciowej.

> Gdzie? Bylem dzisiaj w ksiegarni. Pustki -- jedna ksiazka o SQLu,
> ktora juz mam i 2 jakies beznadziejne.
> 
> No i jakie ksiazki.
Nie bardzo pamietam. Nie idzie mi tez jakos szukanie w sieci.
Wpisz w infioseeku "Projektowanie baz danych". Jest tam jakas
bibliografia.

TRubaj
Re: Bylo: podwojne filtrowanie -- przyklad [SQL]
#89
Author: Janusz Dziadoń
Date: Fri, 02 Apr 1999 08:08
97 lines
4182 bytes
Maciej "MACiAS" Pilichowski napisał(a) w wiadomości:
<37023079.4932281@rymunda.torun.pdi.net>...
>>IdCechy
>Czyli mialbym jedna baze samochodowo-rowerowo-jakastam. No tak, ale
>jesli tam od razu zaczne wpisywac cechy, to bede mial problemy z
>nadawaniem IdPojazdu /nie moge zastosowac autoincrement, bo pare cech
>musi byc od jednego pojazdu, a znowu jak dam integera, to sie boje,
>czy podolam pracy w sieci/. Jak wyrzuce to do zewnetrznej bazy, co
>likwiduje problem z IdPojazdu, to w zasadzie wracam do sytuacji
>wejsciowej.


Tak to wlasnie powinno byc. Móglbys miec tabele nazw cech (slownik), oraz
tabele cech poszczególnych typów pojazdów.

Wówczas np.

tabela scechy.dbf (pola idscecha, nazwa) (s jak slownik)
1, kolor
2, dlugosc
3, kabrio
4, czytorower
5, masa
6, liczbaosob
7. numer rejestr

tabela spojazdy.dbf (pola idspojazdu,nazwa)
1, Trek
2, Giant
3, FiatPunto
4, VWPolo
5, Motor Yamaha750

tabela dcechy.dbf (pola iddcechy, idspojazdu, idscechy) (d jak dopuszczalne
cechy dla danego pojazdu)
1, 1, 2 (Trek ma dlugosc)
2, 1, 1 (kolor ramy tez jakis jest)
3, 1, 5 (masa treka)
4, 2, 2 (dlugos gianta)
5, 1, 6 (liczba osób na treka)
6, 2, 1 (dlug gianta)
7, 2, 6 (liczba osób na gianta)
8, 4, 5 (liczba osob do polo)
9, 3, 2 (kolor punciaka)
10, 3, 7 (numer rej punto)
11, 4, 7 (numer rej polo)
12, 5, 7 (numer rej yamaha)
itd.

W tej tabeli zdefiniujesz jakie cechy kazdy pojazd posiadac moze. Jesli
jakies cechy sa oczywiste i dla wszystkich pojazdów to mozna je wrzucic do
tabeli spojazdy jako kolejne pola np. idpojazdu,nazwa, dlugosc, kolor, masa,
liczbaosob, liczbakol

I teraz potrzebna ci bedzie w bazie pojazdow tylko wpis o wartosci danej
cechy a juz nie pojazdu (a poprzez cechy sie do niego dostaniesz), choc
redundantnie mozna to zostawic dla przyspieszenia dzialania
tabela cechy.dbf (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)
1, 3, 2.4
2, 9, $00043 (punciak piasek pustyni)
2, 10, KWO 2947 chyba jasne
3, 11, KXX 4300 pierwszy samochod VWPolo
4, 12, WGB 4560
5, 12, ZGB 8790 drugi samochod VWpolo bo inny idpojazdu

Zakladam, ze edycje wartosci cech pojazdu przeprowadzisz tak, ze niemozliwym
bedzie wprowadzenie cech niedopuszczalnych tzn dla pojazdu np treka nie
mozna wprowadzac cech innych niz dopuszcza.

Teraz pozostaje jeszcze tylko baza pojazdy (pola idpojazdu, wlasciciel, rok
prod). Tu wlasnie mozesz dodac redundantnie typ pojazdu z bazy typow dla
przyspieszenia dzialania (pola idpojazdu, wlasciciel, rok prod, idspojazdu)
1, Józek, 1999
2, Kasia, 1998
3, Rysio, 1998
4, Jerzy, 1970
5, Edyta, 1990

Koniec.
Chcesz wiedziec jaki pojazd ma Kasia prosze bardzo:
idpojazdu - 2 -> z tabelki chechy ->cecha 9 lub 10 jest zwiazana z
samochodem Punto.

Tu sie az prosi zeby typpojazdu byl w tej ostatniej bazie ale on tez musi
byc w bazie dopuszczalnych cech, zeby dalo sie je okreslic.
Troche to zawile, ale szybciej by sie zrobilo na rysunku niz tekstem, ew.
telefon.

Dodam jeszcze ze sam korzystam z podobnej bazy - mam baze analiz dla pewnych
probek - typow analiz jest wiele ale rozne typy probki dopuszczaja tylko
pewne analizy. I jakos sie kreci. Roboty wiecej ale uzytkownik wniebowziety.
--
Janusz Dziadon
j.dziadon@bph.krakow.pl
Re: Bylo: podwojne filtrowanie -- przyklad [SQL]
#90
Author: Maciej "MACiAS" Pilichowski
Date: Sat, 03 Apr 1999 09:23
108 lines
4889 bytes
Hej,

  Dziekuje Ci serdecznie za odpowiedz. Czytam ja na razie 3 raz, wiec
moglem czegos nie wylapac, ale pozwolisz, ze pare uwag na goraco...

  Generalnie jestem w trakcie przemyslen, czy robic cos z sama
struktura bazy, czy tez moze ja zostawic a pobawic sie w laczenie
tabel i zatrudnic, jeszcze nierozpoznanego przeze mnie, TUpdateSQL.

  Problemem u mnie na razie jest to, ze u mnie dane siedza w dwoch
tabelach /vide post z przykladem/. Tzn. dane juz samych pojazdow. I o
ile z wyswietlaniem sobie juz poradzilem, to teraz nie wiem jak to
dziadostwo sortowac lacznie. 
Indeksy mam zalozone dla listy pojazdow jako takich, bo w cechach nic
nie siedzi -- sa tam same cechy.
  I jak dochodzi do sortowania, to oczywiscie nie moge z tym dojsc do
ladu. To jest glowny bol.
  Chyba, ze znasz mozliwosc spinania dwoch tabel, jesli jedna jedna ma
zalozony indeks, a obie tabele sa w relacji 1:1 /tj. w pierwszej i
drugiej jest tyle samo rekordow, w pierwszej dla kazdego rekordu jest
jeden i tylko jeden rekord z bazy 2, i odwrotnie/.

>Wówczas np.
>tabela scechy.dbf (pola idscecha, nazwa) (s jak slownik)
>1, kolor
>2, dlugosc

Ok, przyda sie np. do tytulowania kolumn.

>tabela spojazdy.dbf (pola idspojazdu,nazwa)
>1, Trek
>2, Giant

Nadal kojarze.

>tabela dcechy.dbf (pola iddcechy, idspojazdu, idscechy) (d jak dopuszczalne
>cechy dla danego pojazdu)
>1, 1, 2 (Trek ma dlugosc)
>2, 1, 1 (kolor ramy tez jakis jest)
>3, 1, 5 (masa treka)

Ok, kojarze. Co mozna wrzucic za ceche do danego pojazdu.

>I teraz potrzebna ci bedzie w bazie pojazdow tylko wpis o wartosci danej
>cechy a juz nie pojazdu 

No dobrze.

> (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/

>Zakladam, ze edycje wartosci cech pojazdu przeprowadzisz tak, ze niemozliwym
>bedzie wprowadzenie cech niedopuszczalnych tzn dla pojazdu np treka nie
>mozna wprowadzac cech innych niz dopuszcza.

Jasna sprawa.

>Teraz pozostaje jeszcze tylko baza pojazdy (pola idpojazdu, wlasciciel, rok
>prod). Tu wlasnie mozesz dodac redundantnie typ pojazdu z bazy typow dla
>przyspieszenia dzialania (pola idpojazdu, wlasciciel, rok prod, idspojazdu)
>1, Józek, 1999
>2, Kasia, 1998

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.

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? 

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.

Jak mi powiesz jak posortowac te spiete bazy w ramach np. jednego
grida, nie uzywajac SQLowego JOIN /bo tego sie wlasnie ucze/, to
dozgodnna wdziecznosc zapewniona ;-))) A jak sie spotkamy, to i piwo
naturalnie ;-)

milego dnia zycze
hej

PS. Jestem troche padniety, wiec sorry, jesli cos pominalem.

--
Maciej "MACiAS" Pilichowski              http://www.torun.pdi.net/~macias/
nowe klamoty w marcu: pieniadze publiczne, W I R U S  Happy99
     S P R Z E D A M : oryginalne gry HalfLife i Thief, streamer Jumbo250,
lornetke z zoomem, segment CD Technics, przeciwsloneczne okulary sportowe
Re: Bylo: podwojne filtrowanie -- przyklad [SQL]
#91
Author: Janusz Dziadoń
Date: Tue, 06 Apr 1999 07:06
79 lines
4965 bytes
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
Re: Bylo: podwojne filtrowanie -- przyklad [SQL]
#92
Author: Maciej "MACiAS" Pilichowski
Date: Tue, 06 Apr 1999 13:58
42 lines
2864 bytes
Hej,

> Œ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).

No coz... stwierdzam, ze jestes dobrym psychologiem. Co do minimalizmu
-- to nie dlatego, ze boje sie pracy, ale uwazam, ze male jest piekne.
Takze dlatego, ze latwo wykrywac bledy w malych rzeczach. Lubie wiec
zwiezlosc i pewna estetyke w pisaniu.

> 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.

No i ustalilem go wlasnie. Masz racje, myslac dlugo i mam nadzieje
owocnie doszedlem do tego samego wniosku. Albo bazy beda male, ladne i
w ogole cacy, ja sie zarobie probujac wymyslac niemozliwe jakies
brewerie /i jednoczesnie spac nie bede mogl, myslac u ktorego klienta
to sie sypnie/, ale dam jednak bazom pewna nadmiarowosc informacji,
pisania bedzie super malo, a bedzie to szybkie.
I tak to wlasnie zrobilem. Powiazania dzialaja bardzo szybko, bo
wsadzilem dane nadmiarowe, ale dziala to szybko i na moje oko pewnie,
jesli chodzi o logike zawiadywania.

W kazdym razie jeszcze raz dziekuje serdecznie za pomoc.

milego dnia zycze
hej
--
Maciej "MACiAS" Pilichowski              http://www.torun.pdi.net/~macias/
nowe klamoty w kwietniu: nowe bookmarki o DVD
     S P R Z E D A M : oryginalne gry HalfLife i Thief, streamer Jumbo250,
lornetke z zoomem, segment CD Technics, przeciwsloneczne okulary sportowe
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads