Kezdőoldal » Számítástechnika » Programozás » Adatbázisból tömbbe hogy...

Adatbázisból tömbbe hogy tudok hatékonyan menüszerkezetet betenni?

Figyelt kérdés

Üdv,

adatbázisból szeretnék menüt rendezni többdimenziós tömbbe.

Erre várnék 5leteket. Jó volna DB-ből már rendezve lekérni és aztán csak behúzni tömbbe.

prog.hu-n volt egy jó kód, de nem tökéletes: [link]

Nálam is a másodlagos menük már rossz helyre kerülnek.

Tábla: ID, nev, szulo, sorrend

Ha a menü főmenü, akkor a parent értéke nulla.


Gondolkodtam azon, h valami rekurzív eljárást írok, ami egyesével végigmegy a lekérdezés eredményén, majd egy tömbbe elkezdi bepakolni úgy, hogy ID alapján. De mivel bármilyen sorrend lehet a feldolgozásban, így nem tudni, h ki milyen mélységbe kerül. Azaz minden vizsgált menüpontnál a már elhelyezett fán végig kéne mennem. Ez nem tűnik túl hatékonynak. Köszönöm annak, aki segít ebben.



2019. márc. 22. 20:08
1 2 3
 11/25 A kérdező kommentje:

Értem én, hogy gőzgép, de mi hajtja?

Konkrétumok segítenének igazán.

2019. márc. 23. 00:30
 12/25 anonim ***** válasza:
47%
Akkor sokadjára: "fa adatszerkezet"
2019. márc. 23. 00:49
Hasznos számodra ez a válasz?
 13/25 A kérdező kommentje:
+1: kód? folyamatábra?
2019. márc. 23. 01:00
 14/25 anonim ***** válasza:
47%

Tehát akkor nem is 2d tömb kell neked, hanem fa....


sztem simán kérd le (szulo, sorrend)- sorrendben, ebből könnyen építhetsz fát.


Gondolom itt nem millió rekordokról van szó, hisz akkor le sem kérnéd egyben. Illetve feltételezhetjük, hogy a szülő ID-ja kisebb mint a gyereké, ugye?


Algoritmus: Lekéred a megadott sorrendben.


Változók:

OsszesMenuElem, tipusa: valamilyen set (php-ban ez gondolom csak sima array)


OssesMenuElem[0] = Új MenuElem (ez a gyökér)


Ciklus a lekért listán:


Szülő = OszsesMenuElem[AktuálisMenuElem.Szülő] // ha feltételezzük, hogy a szülő ID-ja kisebb, akkor már létezik a szülő


Szülő.Almenük.Add(AktuálisMenuElem)

OsszesMenuElem.Add(AktuálisMenuElem.Id, AktuálisMenuElem)


Ciklus vége


Nyilván lehet szebben, máshogy... pláne nagyo nsok menu elem esetén, de akkor már a lekérés (és talán az adatbázis séma) sem úgy lenne ahogy írtad

2019. márc. 23. 08:57
Hasznos számodra ez a válasz?
 15/25 A kérdező kommentje:
"Illetve feltételezhetjük, hogy a szülő ID-ja kisebb mint a gyereké, ugye?" - Nem. Hiszen bármilyen variációt ki lehet alakítani.
2019. márc. 23. 20:08
 16/25 A kérdező kommentje:
Arra gondoltam, h lekérem egy asszocitaív tömbbe, ahol a szülő, sorrend szerint rendezem a lekérdezést. Azaz elöl lesz az összes fő menüpont. Ez után azt mondom, h lépjkedjünk végig az elemeken. Ha a szülő 0, akkor egy új tömb változóba tegye bele, majd törölje ezt az elemet. Ha a szülő nem 0, akkor azt jelenti almenüpont. Azaz nézze meg, hogy már ez a szülő az új tömbbe bene van-e. Ha nincs, akkor lépjen tovább. Ha benne van, akkor illessze be magát következő elemként (ugye a sorrendisg miatt sorrendben lesznek az alenük azonnal), majd az eredeti tömbből töröljük az elemet. Ha a bégére értünk, de van még elem, akkor ismételjü meg a dolgot a maradék elemmel. Ha van olyan elem, aminek nincs szülője, azaz hibás a szerkezet, akkor dobjon error log-ot, és lépjen ki a ciklusból. Akár úgy is, h ha fél sec-nél tovább tart a ciklus, vagy ha pl. elemszám*X-nél többször fut le a ciklus. Vagy simán ha nincs az új tömbbe, akkor a lekérdezési tömbbe nézze meg, hogy van-e ilyen szülő. Ha nincs, törölje magát (és error log). Vagy az egészet 1 tömbön belül is el lehet játszani rendezéssel...de sztem az macerásabb.
2019. márc. 23. 20:56
 17/25 A kérdező kommentje:
Az a kérdés, h a szülő megtalálásánál hogyan tudom a leghatékonyabban az új elemet beszúrni..
2019. márc. 23. 21:18
 18/25 anonim ***** válasza:
Túl kéne már lépni a tömbökön.
2019. márc. 23. 21:37
Hasznos számodra ez a válasz?
 19/25 anonim ***** válasza:

#16 Ha bevezetsz némi redundanciát az adatbázisszerkezetedbe, név szerint eltárolod minden elemhez, hogy milyen mélységi szinten van, akkor könnyedén tudod mélységi sorrendben lekérni a menüelemeket (ennek a hátránya értelemszerűen az adatbázisban levő redundancia, ami plusz tárhelyfoglalást, és odafigyelést igényel az adatok frissítésekor). Ez ilyen showbiznisz, választhatsz, hogy a lekérdezés/lekért adatok feldolgozása legyen gyors, vagy az adatbázis karbantartása. Mivel menürendszerről van szó, ami valószínűleg nem változik túl gyakran, ezért ez vállalható dolog.


Ha mélységi sorrendben tudod lekérni az elemeket, az számos előnnyel jár:

- Sorfoyltonosan tudod feldolgozni a menüelemeket, mivel minden elemnek garantáltan feldolgoztad már a szülőjét

- Tetszőleges mélységig tudod lekérni a menüelemeket, így ha csak az első 2 szintet akarod lekérni, könnyedén megoldható

- Gyors és egyszerű marad az adatok lekérdezése, nem kell rekurziót, sem csavaros sql-t írogatni a célod eléréséhez.


Innentől már elég triviális a dolog, szép sorban feldolgozod a rekordokat, először a 0. szint elemeit, aztán az 1. szint elemeit, és így tovább. Az egyetlen amire oda kell figyelni, hogy ha egy meglévő menüelemnek változik a szülője, akkor azt, és az összes alatta levő menüelemet frissíteni kell az új mélységi értékkel. Ezért mondtam, hogy vagy a lekérdezésen, vagy a karbantartáson spórolsz, mindkettőn nehéz.

2019. márc. 24. 00:42
Hasznos számodra ez a válasz?
 20/25 anonim ***** válasza:

""Illetve feltételezhetjük, hogy a szülő ID-ja kisebb mint a gyereké, ugye?" - Nem. Hiszen bármilyen variációt ki lehet alakítani."


Jó, akkor sincs nagy gond, az algorutmusom annyit változik, hogy ha még nincs meg a szülő, akkor kihagyod azt az elemet... és az egészet ciklusban addig ismétled amíg mind meg nem lesz...


Nem írtad korábban, hogy ez egy dinamukusan átrendezhető menü, ezért éltem a feltételezéssel, hiszen logkikus lett volna ha úgy van.... de ha dinamikus, akkor is megoldható hogy az áthelyezésnél (amikor az új szülő ID-ja nagyobb mint az áthelyezett elem), hogy újra létrehozod a struktúrát és törlöd a régit.. ezzel biztosítva, hgoy a gyerek ID-ja nagyobb legyen.

2019. márc. 24. 11:01
Hasznos számodra ez a válasz?
1 2 3

Kapcsolódó kérdések:




Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!