Lista =?ISO-8859-2?Q?uporz=B1dkowana?= w relacji

Witam.

Jak robicie listy uporządkowane w relacjach, tzn. tak, żeby jeden rekord w
relacji był jednym elementem listy? Konkretnie chodzi mi o listę
jednokierunkową.

Na razie to wyobrażam to sobie tak, jak to się robi w programowaniu, tzn.
dodaję dwa atrybuty -- identyfikator (unikalny) i identyfikator następnego
rekordu. Ale to jest cokolwiek... niewygodne i wymaga wielu zapytań +
transakcji przy dodawaniu/usuwaniu elementów.

Baza danych to PostgreSQL, 8.0.1.

Pozdrawiam();
--
michał gawron | rlu 283570 | mcv, email/jabber at mulabs.org/chrome.pl
:wq

> Jak robicie listy uporządkowane w relacjach, tzn. tak, żeby jeden rekord w
> relacji był jednym elementem listy? Konkretnie chodzi mi o listę
> jednokierunkową.

Zrób sobie kolumnę z numerem pozycji w liście

Pozdrawiam
FOX

Dnia Tue, 30 May 2006 22:49:38 +0200, mcv <root@localhost.org> wklepał(-a):

>Witam.
>
>Jak robicie listy uporządkowane w relacjach, tzn. tak, żeby jeden rekord w
>relacji był jednym elementem listy? Konkretnie chodzi mi o listę
>jednokierunkową.

Nie napisałeś najważniejszego: jakie ma być zastosowanie tej listy (może jest
inne rozwiązanie)?
--
Sławomir Szyszło mailto:slaszysz@poczta.onet.pl
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?grou...mp.bazy-danych

*Sławomir Szyszło* testified:

> Dnia Tue, 30 May 2006 22:49:38 +0200, mcv <root@localhost.org>
> wklepał(-a):
>
>>Witam.
>>
>>Jak robicie listy uporządkowane w relacjach, tzn. tak, żeby jeden rekord w
>>relacji był jednym elementem listy? Konkretnie chodzi mi o listę
>>jednokierunkową.
>
> Nie napisałeś najważniejszego: jakie ma być zastosowanie tej listy (może
> jest inne rozwiązanie)?

Może i jest, ale mimo wszystko chętnie dowiedziałbym się jak robić list,
a nie inne rzeczy ;-)

A chodziło o połączenie relacji 'kandydat' z 'kierunek', kandydat wybierał
kilka kierunków, na które chciał zdawać, z uwzględnieniem priorytetów,
gdzie najchętniej chciałby się dostać :-)

--
michał gawron | rlu 283570 | mcv, email/jabber at mulabs.org/chrome.pl
:wq

*FOX* testified:

>> Jak robicie listy uporządkowane w relacjach, tzn. tak, żeby jeden rekord
>> w relacji był jednym elementem listy? Konkretnie chodzi mi o listę
>> jednokierunkową.
>
> Zrób sobie kolumnę z numerem pozycji w liście

A wiesz co? Na początku myślałem, że to głupie rozwiązanie.
Nie wpadłem, że można dać potem np. przed wstawieniem
UPDATE ... SET pos = pos + 1 WHERE pos > ileśtam.
Z jakiegoś powodu wmówiłem sobie, że będę musiał każdy rekord osobno
aktualizować.

Dzięki, na moje skromne oczekiwania wystarczy :-)

> Pozdrawiam
> FOX

--
michał gawron | rlu 283570 | mcv, email/jabber at mulabs.org/chrome.pl
:wq

>> Nie napisałeś najważniejszego: jakie ma być zastosowanie tej listy (może
>> jest inne rozwiązanie)?

[...]

Ja mam troche bardziej złożony problem w tym temacie. Na razie
nie zastanawiałem się jak go rozwiązać, ale skoro pojawił się
wątek na grupie, to może warto pociągnąć dalej.

Wyobraźmy sobie że w tabeli są listy (średnio 100 elementów).
np.: A->B, B->C, C->D, D->E
Ale niekiedy listy mogą mieć rozgałęzienia.
np.: A->B, B->C, C->D, B->E, E->F
Następnie chce zrobić iteracji listy, znając jej element końcowy.
W trudniejszym przypadku, dla F, będzie to lista: F,E,B,A.

Znam dwa rozwiązanie
1. trzymać w bazie nadmiarowe dane (id, tatus_id, drzewko)
2. podczas przeszukiwania robić kolejne zapytania.

Wybrałem 1. Wadą jest generowanie w bazie dodatkowych danych.
Zaletą jest szybkość odczytu listy.

Ale może są inne, lepsze sposoby.



Pozdrawiam
Antoni Jakubiak

Dnia Wed, 31 May 2006 00:43:39 +0200, mcv <root@localhost.org> wklepał(-a):

>Może i jest, ale mimo wszystko chętnie dowiedziałbym się jak robić list,
>a nie inne rzeczy ;-)
>
>A chodziło o połączenie relacji 'kandydat' z 'kierunek', kandydat wybierał
>kilka kierunków, na które chciał zdawać, z uwzględnieniem priorytetów,
>gdzie najchętniej chciałby się dostać :-)

No a klasyczna relacja N:M (w tabeli łączącej dodatkowy atrybut "priorytet") nie
wystarczy? IMHO tak. Podaj co chcesz wyciągać z tych tabel, to się okaże.
--
Sławomir Szyszło mailto:slaszysz@poczta.onet.pl
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?grou...mp.bazy-danych

*Sławomir Szyszło* testified:

> Dnia Wed, 31 May 2006 00:43:39 +0200, mcv <root@localhost.org>
> wklepał(-a):
>
>>Może i jest, ale mimo wszystko chętnie dowiedziałbym się jak robić list,
>>a nie inne rzeczy ;-)
>>
>>A chodziło o połączenie relacji 'kandydat' z 'kierunek', kandydat wybierał
>>kilka kierunków, na które chciał zdawać, z uwzględnieniem priorytetów,
>>gdzie najchętniej chciałby się dostać :-)
>
> No a klasyczna relacja N:M (w tabeli łączącej dodatkowy atrybut
> "priorytet") nie wystarczy? IMHO tak. Podaj co chcesz wyciągać z tych
> tabel, to się okaże.

Takoż właśnie zrobię - tabelkę candidaterofile, zawierającą tylko klucze
obce do tabel candidate i profile (wszędzie są klucze surogatowe)
oraz atrybut priority. Tylko tyle, kandydat po prostu miał mieć
uporządkowaną listę kierunków, na które chciałby się dostać.

Teraz mam inny problem, mianowicie jak zrealizować takie wybieranie
kierunków w miarę prosto przez WWW ;-) Chyba wspomogę się Javascriptem.

Dziękuję za odpowiedzi i pozdrawiam();
--
michał gawron | rlu 283570 | mcv, email/jabber at mulabs.org/chrome.pl
:wq

Antoni Jakubiak wrote:
>>> Nie napisałeś najważniejszego: jakie ma być zastosowanie tej listy (może
>>> jest inne rozwiązanie)?
>
>
> [...]
>
> Ja mam troche bardziej złożony problem w tym temacie. Na razie
> nie zastanawiałem się jak go rozwiązać, ale skoro pojawił się
> wątek na grupie, to może warto pociągnąć dalej.
>
> Wyobraźmy sobie że w tabeli są listy (średnio 100 elementów).
> np.: A->B, B->C, C->D, D->E
> Ale niekiedy listy mogą mieć rozgałęzienia.
> np.: A->B, B->C, C->D, B->E, E->F
> Następnie chce zrobić iteracji listy, znając jej element końcowy.
> W trudniejszym przypadku, dla F, będzie to lista: F,E,B,A.

To jest zwykłe drzewo.

> Znam dwa rozwiązanie
> 1. trzymać w bazie nadmiarowe dane (id, tatus_id, drzewko)
> 2. podczas przeszukiwania robić kolejne zapytania.
>
> Wybrałem 1. Wadą jest generowanie w bazie dodatkowych danych.
> Zaletą jest szybkość odczytu listy.
>
> Ale może są inne, lepsze sposoby.

Hmm.. nie wiem, co trzymasz w polu drzewo, ale problem reprezentacji
drzew jest dość dobrze opisany w FAQ.

--
P.M.

[SuzanMalkovich]

Buy nexium 40mg.
Next Day FedEX, Visa and Mastercard payments. US Pharmacy. Order now without prior prescription.

ThankYou. Please remove it to related section.