Tabelle füllen nach parent/child oder child/child beziehung?

C

cemiboy

Mitglied
Möchte eine Prozedur schreiben bei der ich nach Hierarchie(Baumform einfügen kann)

Angenommen so ist grad Warenkorb-Tabelle gefüllt....


Beispiel:
PHP: 
Sq_no---------Prod_name--------Referer------Opt_flag
1.............Tower.............--...........--
2...............Netzteil.........1........... f
3...............Motherboard......1........... f
4...............Grafikkarte......1........... f
5..................Kühlergrafik..4........... f
6...............Ram..............1...........f
7..................Ramkühler.....6...........f
Jetzt möchte ich noch eine 2 Grafikkarte und noch ein Ramkühler einfügen die bekommen vom System als sq_no die nächste value. Jetzt soll
die zugehörigkeit im Baum überprüft werden und die Referer richtig gesetzt werden und auch der flag.


Hat jemand ne Idee wie ich das machen kann Das kommt später in eine Prozedur!
 
cemiboy hat gesagt.:
Möchte eine Prozedur schreiben bei der ich nach Hierarchie(Baumform einfügen kann)

Angenommen so ist grad Warenkorb-Tabelle gefüllt....


Beispiel:
PHP: 
Sq_no---------Prod_name--------Referer------Opt_flag
1.............Tower.............--...........--
2...............Netzteil.........1........... f
3...............Motherboard......1........... f
4...............Grafikkarte......1........... f
5..................Kühlergrafik..4........... f
6...............Ram..............1...........f
7..................Ramkühler.....6...........f
Jetzt möchte ich noch eine 2 Grafikkarte und noch ein Ramkühler einfügen die bekommen vom System als sq_no die nächste value. Jetzt soll
die zugehörigkeit im Baum überprüft werden und die Referer richtig gesetzt werden und auch der flag.


Hat jemand ne Idee wie ich das machen kann Das kommt später in eine Prozedur!
Zum Vergrößern anklicken....

- Wohin in der Baumstruktur die neuen Item's eingefügt werden, kannst alleine du entscheiden. Das System kann nicht erkennen, wo die 2. Graphikkarte eingefügt werden soll , denke ich. Dasselbe gilt für das Flag, für was auch immer das ist.

In deinem Beispiel würde das Einfügen folgendemassen aussehen :

INSERT INTO Warenkorb (Sq_no,Prod_name,Referer, Opt_flag) VALUES (NEUE_SQ_no,'Neue Graphikkarte',1,'f')
/

- Dies würde die neue Graphikkarte dem System TOWER hinzufügen. Analog wäre es für den Ramkühler zu machen
- Die neue Sq_No müsstes du über eine Sequenz beziehen (Falls es Oracle ist...)

Gruss
 
Zuletzt bearbeitet:
Da kann ich meinem Vorredner nur zustimmen - aber soweit waren wir doch glaub ich gestern schon mal, oder? :)

Auch wenn das nicht dein Datenbankmodell ist, muss ich nochmal sagen, wenn du alles so lässt, wird dieses Ding immer nur noch hässlicher - und pflegen würde ich sowas nicht wirklich wollen.

Du kannst die Baumstruktur - wie ich das gestern schon beschrieben habe, ja auch zusätzlich in weiteren Tabellen abbilden. Und das Einfügen in diese Warenkorb-Tabelle auf Basis deiner eigenen Tabellen steuern.

Aber irgendwas musst du tun, um von diesem - sorry - Mist-Modell wegzukommen
 
Was ich mir überlegt habe ist folgendes :

PHP: 
 for <rec>in <cursor>loop
    if 
      rec.opt_flag in ('DEF','FIX')
    then 
      l_wkref := l_ref_temp;
      
      insert into <warenkorb>     
      values ()
   
 else
      l_wkref     := rec.wksq; 
      l_ref_temp:= rec.wksq;
      insert into <warenkorb>    
      values ()

d.h. wen eine Option eingefügt wird dann muss ich irgendwas einbauen damit er den Referer richtig setzt also ne Art überprüfung.

Ansonst wenn kein (FIX,DEF) ist dann ist es sowieso ein Hauptprodukt und es muss nix beachtet werden....
 
cemiboy hat gesagt.:
d.h. wen eine Option eingefügt wird dann muss ich irgendwas einbauen damit er den Referer richtig setzt also ne Art überprüfung.
Zum Vergrößern anklicken....

- IRGENDWAS ist hier das Schlüsselwort :). Du hast KEINE Möglichkeit zu bestimmen, welchem Parent (Referer) ein neuer Datensatz zugefügt werden soll. Wie willst du überprüfen, welchem Parent deine neue Graphikkarte zugefügt werden soll ? Dem Tower ? Dem Netzteil ? Shutdown hat in seinem Post darauf hingewiesen, das du eine Art Steuertabelle brauchst, in der die Parent-Child Beziehungen abgelegt sind
 
Zuletzt bearbeitet von einem Moderator:
Ich würde an der Stelle auch noch mal grundsätzlich an die Geschäftslogik denken:

Die Parent-Child-Beziehung kann ja grundsätzlich vorgeben, dass
- ein Netzteil zum Tower
- eine Grafikkarte zum Mainboard
- ein Grafikkartenkühler zur Grafikkarte
gehört.

Aber soweit ich mich noch erinnern kann, reicht das in deinem Fall ja noch nicht.
Wolltest du nicht sogar vorgeben (Beispiele von mir erfunden), dass
- ein Monster-Mainboard zum Big-Tower
- der Ultra-leise Lüfter zur an sich kühlen Grafikkarte
- ein Extrastarkes Netzteil zu dem Rechner mit 2 Grafikkarten und einem Raid0-Festplattenverbund a 3 Terabyte
gehört?

Wenn dem so ist, musst du - wenn du ein zusätzliches Steuer-Datenmodell anlegen darfst - auch hier gehörig beim Design aufpassen, dass du alle Beziehungen, die diese Logik voraussetzt, auch abbilden kannst.
 
Natürlich kannst du die verwenden - löst aber nicht dein Problem.

Eine Nested Table ist ja im Grunde eine weitere Tabelle, die du als Spalte in eine bestehende Tabelle hineinpfriemelst. Anlegen und mit Daten füllen musst du sie aber trotzdem.

Zudem ist das ganze nicht sehr schön. Du müsstest ja die Produkttabelle "nesten" um das Mainboard an den Tower zu hängen.
Dann die Produktabelle noch mal nesten um die Grafikkarte an das Mainboard zu hängen.
Und dan die Produkttabelle noch mal nesten um den Kühler an die Grafikkarte zu schrauben.

Und wenn jetzt noch eine besondere Kleinteile für den Kühler hast - nochmal nesten?

Das ist alles nicht sauber. Eine klassische Baumstruktur wird über 2 Tabellen abgebildet, in deinem Fall Produkt und Produkt_ist_Element_von_Produkt.

Ganz nebenbei bemerkt - auch wenn du diese Baumstruktur so korrekt abbildest - du kannst den Baum an sich nie allein mit SQL darstellen, da wirst du immer Anwendungscode brauchen. Aber zumindest ist die Datenhaltung dann so, dass man damit was anfangen kann.
 
shutdown hat gesagt.:
Das ist alles nicht sauber. Eine klassische Baumstruktur wird über 2 Tabellen abgebildet, in deinem Fall Produkt und Produkt_ist_Element_von_Produkt.

Ganz nebenbei bemerkt - auch wenn du diese Baumstruktur so korrekt abbildest - du kannst den Baum an sich nie allein mit SQL darstellen, da wirst du immer Anwendungscode brauchen. Aber zumindest ist die Datenhaltung dann so, dass man damit was anfangen kann.
Zum Vergrößern anklicken....

- Eine Baumstruktur kannst du schon in einer Tabelle abbilden : Mal ein Beispiel (Auszug), wie wir es in einem unserer Projekte gelöst haben

CREATE TABLE control_structure
(structure_id NUMBER NOT NULL,
value_d VARCHAR2(100),
parent_id NUMBER)

- und daraus kannst du mit SQL den kompletten Baum abbilden :

SELECT STRUCTURE_ID, SYS_CONNECT_BY_PATH (value_d, '\') cbp
FROM CONTROL_STRUCTURE
START WITH PARENT_ID IS null
CONNECT BY PRIOR STRUCTURE_ID = PARENT_ID
ORDER SIBLINGS BY value_d

(Ich kann dir das Ergebnis hier nicht zeigen, da dies vertauliche Daten sind ...., aber es
ergibt eine "schöne" Baumstruktur :). Das Schlüsselwort CONNECT BY ... resp. SYS_CONNECT_BY_PATH sind hier entscheidend


Gruss
 
Gibt es so was Ähnliches für mein Fall das ich zum Beispiel den ganzen Warenkorb-table so selektiere und dann nach zugehörigkeit einfüge?
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück