Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: "Własna" kolejność rekordów w tabeli
Forum PHP.pl > Forum > Bazy danych
Nivelis
Witam,

o dziwo nie potrafię znaleźć rozwiązania swojego problemu w internecie, dlatego będę również wdzięczny za rzucenie kilku keywordów (lub wskazówek) zamiast gotowego rozwiązania smile.gif

Moja tabela "katerogie" zawiera (dla maksymalnego uproszczenia) następujące pola
id - identyfikujące daną kategorię
name - wiadomo
order - w celu określenia "customowej" kolejności kategorii

W Panelu Administracyjnym mam wylistowane wszystkie kategorie, posortowane według pola order. W każdym wierszu z kategorią znajdują się też 2 strzałki (do prostego przemieszczania kategorii w górę/w dół).

Moje pytania są następujące:
- jak najprościej (np. bez używania funkcji MAX() dodać nową kategorię o "najstarszej" kolejności ?
- jak usunąć kategorię tak, by nie została luka (np. order po usunięciu kilku kategorii wygląda tak: 0, 7, 8, 9, 13)
- jak najprościej (przy pomocy wyżej wymienionych "strzałek") zamienić 2 kategorie miejscami (zakładam, że order ma klucz UNIQUE) ?
- linijkę wyżej zamieniam miejscami dwie kategorie, które leżą obok siebie. jak się ma sytuacja w przypadku, gdy chcę przesunąć kategorię np. z pozycji 2 na zajętą pozycję 10, tak aby reszta się ładnie poukładała ?
- czy istnieje lepszy sposób na zaprojektowanie tego niż wyżej przedstawiony ?

Dodam, że istnieje także druga tabela z podkategoriami, w której każdy element ma przypisanego rodzica i swoją kolejność w obrębie danej nadkategorii.

Pozdrawiam i z góry dziękuję za wszelką pomoc,
Nivelis
mmmmmmm
Cytat(Nivelis @ 20.01.2014, 11:25:16 ) *
Moja tabela "katerogie" zawiera (dla maksymalnego uproszczenia) następujące pola
id - identyfikujące daną kategorię
name - wiadomo
order - w celu określenia "customowej" kolejności kategorii

Nie nadawaj nazw, które są słowami kluczowymi w SQL.

Cytat(Nivelis @ 20.01.2014, 11:25:16 ) *
Moje pytania są następujące:
- jak najprościej (np. bez używania funkcji MAX() dodać nową kategorię o "najstarszej" kolejności ?

ORDER BY `order` DESC LIMIT 1 smile.gif
Cytat(Nivelis @ 20.01.2014, 11:25:16 ) *
- jak usunąć kategorię tak, by nie została luka (np. order po usunięciu kilku kategorii wygląda tak: 0, 7, 8, 9, 13)

Po co?
Cytat(Nivelis @ 20.01.2014, 11:25:16 ) *
- jak najprościej (przy pomocy wyżej wymienionych "strzałek") zamienić 2 kategorie miejscami (zakładam, że order ma klucz UNIQUE) ?

UPDATE katerogie SET `order`=6-`order` WHERE `order` IN (2,4) -- 6 bierze się z sumy 2 + 4
Cytat(Nivelis @ 20.01.2014, 11:25:16 ) *
- linijkę wyżej zamieniam miejscami dwie kategorie, które leżą obok siebie. jak się ma sytuacja w przypadku, gdy chcę przesunąć kategorię np. z pozycji 2 na zajętą pozycję 10, tak aby reszta się ładnie poukładała ?

Po co?
Cytat(Nivelis @ 20.01.2014, 11:25:16 ) *
- czy istnieje lepszy sposób na zaprojektowanie tego niż wyżej przedstawiony ?

Być może - nie znam.
Cytat(Nivelis @ 20.01.2014, 11:25:16 ) *
Dodam, że istnieje także druga tabela z podkategoriami, w której każdy element ma przypisanego rodzica i swoją kolejność w obrębie danej nadkategorii.

Błąd. wrzuć wszystko do jednej tabeli z dodatkowym polem (parentId). Wtedy UNIQUE na parentId, order
Nivelis
Cytat
Nie nadawaj nazw, które są słowami kluczowymi w SQL.

To nie są moje nazwy, podałem je w uproszczeniu, aby wyjaśnić problem.

Cytat
ORDER BY `order` DESC LIMIT 1

Dodać, nie pobrać.
Nadal nie wiem jak zrobić to bez dodatkowego SELECT'a, który zwróci mi największy numerek porządkowy.

Cytat
Po co? < drugie smile.gif >

Drag & drop w wybrane miejsce.

Cytat
Błąd. wrzuć wszystko do jednej tabeli z dodatkowym polem (parentId). Wtedy UNIQUE na parentId, order

I jak niby miałaby działać w tym przypadku relacja wiele do jednego ?
nospor
Cytat
Nadal nie wiem jak zrobić to bez dodatkowego SELECT'a, który zwróci mi największy numerek porządkowy.
No raczej sie nie obejdzie.... przeciez musisz wiedziec jaki numer jest najwiekszy. Wrozka ci nie powie

Cytat
I jak niby miałaby działać w tym przypadku relacja wiele do jednego ?
To co ty masz za zystem kategorii, ze jedna podkategoria moze nalezec do wielu nadkategorii?
Nivelis
Cytat
To co ty masz za zystem kategorii, ze jedna podkategoria moze nalezec do wielu nadkategorii?


No faktycznie nie może, mój błąd smile.gif Ale w takim razie i tak nie widzę sensu upychania tego w jedną tabelę.
nospor
No ale tak sie robi, ze kategorie leża w jednej tabeli. Nie ma najmniejszego sensu tworzyc dwoch tabel, ktore przechowują te same info/strukture.

Pocztaj o strukturach drzewiastych. Jest tego cała masa, np. drzewka IP
Nivelis
Pozwolę sobie kontynuować wątek, gdyż mam wątpliwości.
Moja struktura teraz wygląda tak:

- identyfikator
- identyfikator rodzica
- nazwa
- liczba porządkowa

W tym momencie dane się mieszają, kategoria od subkategorii jest rozróżniana jedynie tym, że identyfikator rodzica w pierwszym przypadku ma wartość NULL.
Dane się mieszają, trzeba je dodatkowo rozdzielać, żeby wykonać jakąś operację przykładowo tylko na kategoriach głównych i jest ogólny chaos.
Na pewno powinno to tak być? Jaki jest sens upychania tego do jednej tabeli nawet jeśli dane są do siebie podobne?
Drzewo sięga tylko jednego potomka, nie będzie bardziej zagnieżdżone (subkategoria nie może mieć kolejnych subkategorii).

Byłbym wdzięczny jakby ktoś jeszcze się wypowiedział smile.gif
nospor
Chaos....? dodanie
WHERE identyfikator_rodzica = null
nazywasz CHAOSEM?? To taki zart, tak?
Nivelis
Raczej wymieszanie dwóch różnych danych w jednej tabeli bez większego celu. Sam identyfikator powinien wskazywać na konkretny obiekt a w tym przypadku potrzebujemy aż dwóch własności, żeby stwierdzić czym ten obiekt w ogóle jest. Nie chodzi o to, że taka struktura uniemożliwia pracę czy utrudnia ją w znaczącym stopniu, po prostu z mojego punktu widzenia sprawia wrażenie nieestetycznej, takiej, że da się to zrobić "lepiej".

Co innego gdyby faktycznie drzewo miałoby mieć x potomków - ale tak nie jest.
nospor
Za to tworzenie kolejnej zbednej tabeli, ktora trzyma te same dane juz dla CIebie nie jest bezsensu? Interesujace.....

Tak sie robi. Ale jak nie chcesz, to nikt ci nie zabroni robic i nawet 15 dodatkowych tabel.
Nivelis
Danych o innym przeznaczeniu. Pobranie konkretnych danych z konkretnej tabeli wydaje się być szybsze od przeszukiwania jednej, składującej wszystko i segregowania ich za każdym razem gdy się chce na nich wykonać operację. Nie potrzebuję 15 tabel - potrzebne mi jedynie dwie co podkreśliłem pisząc o tym, że drzewo nie będzie zagnieżdżone do nie wiadomo ilu elementów.

Ale chyba podziękuję za dyskusję z Tobą bo z niewiadomego mi powodu od samego początku prezentujesz ofensywny ton wypowiedzi - nikt nie każe Ci odpowiadać w moim temacie i jeśli denerwuje Cie on w jakikolwiek sposób to ja to rozumiem ale w tym przypadku nie rób łaski tylko go pomiń smile.gif Konkretny przypadek, konkretny dylemat - co zdajesz się ignorować brnąc w swoje miliony tabel.

Mimo wszystko dzięki za pomoc.
nospor
Od pewnego momentu zadajesz pytania niejako na moje odpowiedzi, wiec kontynuuje rozmowe z Toba.

Zas twoj wywod o niepomaganiu jak sie nie chce, dziala rowniez w drugą strone. Skoro wiesz lepiej i nie chcesz pomocy - nie pytaj smile.gif
Wyjasniam ci jak to sie robi. Nie ma sensu tworzyc dwoch identycznych tabel, co ty proponujesz. Tu sie robi jedna tabele i nie ma zadnego chaosu, nie ma zadnego poslizgu z pobieraniem danych i nie ma w ogole z tym zadnego problemu. Zakladasz odpowiednie indeksy i wszystko smiga pieknie.
Poza tym ile ty bedziesz mial tych kategorii? 100? 1000? To zadna liczba dla bazy danych. Nawet jakbys ich mial 1000000 to rowniez to by nie byl zaden problem trzymac je w jednej tabeli.

Ale chyba podziękuję za dyskusję z Tobą bo z niewiadomego mi powodu od samego początku prezentujesz ton wypowiedzi - pytam ale i tak wiem lepiej wink.gif

ps: i wytlumacz mi prosze, ktore moje posty mają ofensywny ton wypowiedzi, bo niezmiernie mnie to interesuje.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.