CREATE TABLE `posts` (
`id` int(7) NOT NULL AUTO_INCREMENT,
`prev_id` int(7) DEFAULT '0',
`topic_id` int(6) NOT NULL,
`user_id` int(5) NOT NULL,
`body` text NOT NULL,
`time` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
)
Pole `prev_id` wskazuje na `id` postu, na który odpowiada.
Problem jest następujący: Czy da się jednym zapytaniem pobrać posty
tak, aby odpowiadające znalazły się nad poprzednikami? Jeśli nie, to
czy jest sens sortować to na poziomie kodu (wydajność)?
Znających odpowiedź proszę o wyrozumiałość :)
[...]
> Problem jest nast�puj�cy: Czy da si� jednym zapytaniem pobra� posty
> tak, aby odpowiadaj�ce znalaz�y si� nad poprzednikami? Je�li nie, to
> czy jest sens sortowa� to na poziomie kodu (wydajno��)?
>
> Znaj�cych odpowied� prosz� o wyrozumia�o�� :)
To jest problem na bazy-danych, nie na PHP.
I podpowiem, �e w FAQ grupy bazy-danych s� bardzo fajne przyk�ady
na efektywne struktury pozwalaj�ce na zag��bianie si�.
http://www.dbf.pl/faq/
http://www.dbf.pl/faq/tresc.html?rozdzial=1#o1_9
Wybierz tak�, kt�ra Ci b�dzie najbardziej pasowa� i tyle.
--
Wojciech Ba�cer
pro...@post.pl
Nie wystarczy wybrać struktury, którą nawiasem mówiąc już mam. Trzeba
jeszcze zbudować do tego zapytania, a to jest dla mnie największy
problem.
Z chęcią zmienię strukturę na inną jeśli tylko będę wiedział jak ją
zaimplementować.
W moim przypadku zależy mi najbardziej na łatwym wyświetlaniu całego
drzewa "na płasko" czyli, dzieci pod rodzicami i znajomość głębokości
danego elementu.
Na pozostałych funkcjach jak znajdywanie rodzica, czy wyświetlanie
jednej gałęzi już mnie nie interesuje.
Może ktoś poratować?
[...]
> W moim przypadku zale�y mi najbardziej na �atwym wy�wietlaniu ca�ego
> drzewa "na p�asko" czyli, dzieci pod rodzicami i znajomo�� g��boko�ci
> danego elementu.
Dodaj wi�c pole 'depth' i przy dodawaniu pola musisz sprawdza�
jak g��boko ono siedzi. Potem ju� masz latwo bo wy�wietlisz to
drzewko jednym selectem sortuj�c np po: depth asc, time desc.
R.
no trzeba doda� jeszcze jedno pole, po kt�rym b�dzie sortowanie, bo sam
time nie wystarczy. Przy dodawaniu post�w, trzeba uaktualnia� do pole
dla ca�ego drzewa w�tk�w, troch� zabawy, ale jednym selectem pobiera si�
ca�o��
--
Wk�ady kominowe: http://twojkomin.pl
>> Dodaj wi�c pole 'depth' i przy dodawaniu pola musisz sprawdza�
>> jak g��boko ono siedzi. Potem ju� masz latwo bo wy�wietlisz to
>> drzewko jednym selectem sortuj�c np po: depth asc, time desc.
>>
>
> no trzeba doda� jeszcze jedno pole, po kt�rym b�dzie sortowanie, bo sam
> time nie wystarczy. Przy dodawaniu post�w, trzeba uaktualnia� do pole
> dla ca�ego drzewa w�tk�w, troch� zabawy, ale jednym selectem pobiera si�
> ca�o��
No przecie� napisa�em. "Dodaj wi�c pole 'depth'.
Co� jeszcze potrzebne? Zazwyczaj sortowanie odbywa si� po g��boko�� + data,
i tak to opisa�em.
>
> No przecie� napisa�em. "Dodaj wi�c pole 'depth'.
> Co� jeszcze potrzebne? Zazwyczaj sortowanie odbywa si� po g��boko�� + data,
> i tak to opisa�em.
>
nie chodzi po depth, a o jaki� order czy position, bo sam time mo�e nie
spe�nia� za�o�e�
[...]
>> No przecie� napisa�em. "Dodaj wi�c pole 'depth'.
>> Co� jeszcze potrzebne? Zazwyczaj sortowanie odbywa si� po g��boko�� + data,
>> i tak to opisa�em.
>
> nie chodzi po depth, a o jaki� order czy position, bo sam time mo�e nie
> spe�nia� za�o�e�
timestamp spe�nia i przy forach si� sprawdza. Na inne dodatkowe pole nie
by�o za�o�e� w zadaniu. ;)