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



## cemiboy (16. April 2008)

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

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


Beispiel:

```
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!


----------



## dbwizard (16. April 2008)

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....
> 
> ...



- 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


----------



## shutdown (16. April 2008)

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


----------



## cemiboy (16. April 2008)

Was ich mir überlegt habe ist folgendes :


```
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....


----------



## dbwizard (16. April 2008)

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.



- 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


----------



## shutdown (16. April 2008)

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.


----------



## cemiboy (16. April 2008)

Ich hab mich jetzt bissle mal eingelesen und umgeschaut im Net würde es mit Nested Table gehen


----------



## shutdown (16. April 2008)

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.


----------



## dbwizard (16. April 2008)

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.



- 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


----------



## cemiboy (16. April 2008)

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?


----------



## dbwizard (16. April 2008)

cemiboy hat gesagt.:


> 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?



- Was heisst "ähnlich" ? Das ist ein Beispiel, so du kannst es einfach auf deine Bedürfnisse anpassen ?

Gruss


----------



## shutdown (16. April 2008)

> ergibt eine "schöne" Baumstruktur . Das Schlüsselwort CONNECT BY ... resp. SYS_CONNECT_BY_PATH sind hier entscheidend



Das ist interessant, war mir bisher unbekannt. Gibt's sowas nur in Oracle oder auch für Informix und Mysql? Vom SQL-Standard her ist mir das erst mal unbekannt.



> Eine Baumstruktur kannst du schon in einer Tabelle abbilden



Ja stimmt, sogar eine klassische 

Was man so allerdings nicht mehr abbilden kann, ist, wenn sich aus dem Baum ein Netz entwickelt - und das hast du spätestens dann, wenn du eine Grafikkarte im Midi- und im BigTower platzieren willst - von den Netzteilen gar nicht zu reden 

@cemiboy
Es hilft dir zumindest bei der Darstellung. Löst aber weiterhin nicht dein Problem, dass du im System die Logik hinterlegen musst. Aktiv. Die gibt's bisher nicht. Also musst du sie anlegen. In Tabellen.


----------



## dbwizard (16. April 2008)

shutdown hat gesagt.:


> Das ist interessant, war mir bisher unbekannt. Gibt's sowas nur in Oracle oder auch für Informix und Mysql? Vom SQL-Standard her ist mir das erst mal unbekannt.



- Weiss nicht, ob die anderen DB's so was ähnliches haben. Standard ist es nicht, aber irgendwie hat es ja schon einen Grund, das du für Oracle so viel hinblätterst 


```
Was man so allerdings nicht mehr abbilden kann, ist, wenn sich aus dem Baum ein Netz entwickelt - und das hast du spätestens dann, wenn du eine Grafikkarte im Midi- und im BigTower platzieren willst - von den Netzteilen gar nicht zu reden :-)
```

- Richtig. Da müssten wir mit dem OP aber erst mal über Datenmodelierung, ERM etc diskutieren...Ich wollte mit dem Beispiel ja auch nur einen Denkanstoss geben...Ich glaube, wenn er etwas rumGoogelt ,dass er Unmengen an "Warenkorblösungen" findet, das sollte es sicher so was wie ein "Warenkorb Design Pattern" oder "Best Practice" geben...

Gruss


----------



## cemiboy (16. April 2008)

ich hab mich schon wund gegooglt nur ich find nix oder such auch vlcht falsch


----------

