Ich habe eine Tabelle, die mit sich selbst verknüpft ist:

markieren

Code:

CREATE TABLE BELEGPOSITION (
  ID                       BIGINT NOT NULL,
  PARENTID                 BIGINT,
  OZ                       VARCHAR(20) NOT NULL,
  /* Schlüssel */
  PRIMARY KEY (ID),
  /* Fremdschlüssel */
  CONSTRAINT "BELEGPOSITION-BELEGPOSITION"
    FOREIGN KEY (PARENTID)
    REFERENCES BELEGPOSITION(ID)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION
);

(in der Praxis sind es natürlich weitaus mehr Spalten)

Die ID ist also der Primärschlüssel (AutoInc), ParentID ist der Verweis zur Eltern-Position.
Das ganze hat den Sinn, hierarchische Positionen aufbauen zu können (z.B. im Baugewerben für Lose und Titel, oder für Unterpositionen, Stücklisten usw.)

Die OZ (Ordnungszahl) bestimmt den letzten Teil der Positionsnummer aus der aktuellen Hierarchie-Ebene:
1. Position (Hauptposition), OZ: 01, Positionsnr: 01
2. Position (Unterposition), OZ: 01, Positionsnr: 01.01
3. Position (Unterposition), OZ: 02, Positionsnr: 01.02
4. Position (Unter-Unterposition), OZ: 01, Positionsnr: 01.02.01
...

Ich muss mich jetzt entscheiden, wie ich die Positionsnr in meinem Programm dynamisch aufbaue. Die Ergebnismenge soll später in einem Grid dargestellt werden.

Mir fallen dabei mehrere Lösungen ein:
1. ein weiteres InternalCalcField in meinem DataSet, welches die Positionsnr zusammenbaut. (das wäre mein Favorit)
Problem: Wie komme ich performant an die Parent-Position?

2. Recursive CTEs
Problem: soweit mir bekannt, sind diese aber read-only, richtig?

3. ein entsprechendes Grid verwenden (DevExpress TreeList), welches mir automatisch meine Hirarchie zusammenbaut (das habe ich sowieso vor)
Dann könnte ich im OnGetText (oder so ähnlich) den Inhalt der Spalte zusammenbauen.
Nachteil: Ich vermische GUI und Daten wieder... Besser wäre wohl, wenn die Daten so schon im DataSet vorliegen.

Wie würdet ihr das machen? Habt ihr andere Ideen?

Was passiert denn mit der Baumstruktur, ist die immer fix oder kann auch umsortiert, gelöscht, verschoben, übergangen, usw. werden?

ist die Struktur variabel, dann würde ich mir das erst zusammenbauen wenn du es brauchst. Das kannst du dann ja bequem eine SP machen lassen...

Ja, ist variable... Man kann also sortieren, die Parameter für die Nummerierung (Positionsabstand usw.) einstellen, verschieben, löschen usw.

Eigentlich brauche ich die Nummerierung schon bei der Eingabe (im Grid), zur Orientierung z.B.
Das muss also schon irgendwo lokal in meiner Anwendung passieren...

Bei der Darstellung könnte ich es wunderbar zusammenbauen, da ich dann direkten Zugriff auf die Parent-Nodes habe, aber eigentlich würde ich es wie gesagt irgendwie schon in meinem DataSet haben...

Ist mir noch nicht ganz ersichtlich wie jetzt?

Sind die Daten in der DB und die willst die Los- u. Positionsnummern vergeben?

Du gibst die Daten ein und willst die dann aus dem Grid in der Hierarchie der angegebenen Nummer ablegen?

Klingt irgendwie nach GAEB

Unter anderem soll das GAEB unterstützten, richtig

Ich habe ein Grid, welches mit der Datenbank verbunden ist (über eine Query)
Dieses Grid hat 3 Aufgaben:
1. vorhandene Positionen darstellen
2. vorhandene Positionen bearbeiten
3. neue Positionen (manuell) erfassen

Das Grid ist also sowohl Eingabemaske als auch Darstellung. Das ist auch so gewollt...

Den Datenbankaufbau habe ich ja schon oben gepostet.
Man könnte die Positionsnummer natürlich auch komplett abspeichern (01.01.0001), aber genau das möchte ich nicht. Ich möchte (wie z.B. bei GAEB XML) eine echte Hierarchie aufbauen, nur die jeweils für die Position relevante Ordnungszahl (01, 01, 0001) abspeichern und die komplette Positionsnummer aufgrund der Baumstruktur von meinem Programm aufbauen lassen.

Der Vorteil: Ich ändere bei einer Position nur die OZ, und alle Unterpositionen werden automatisch angepasst. (bzw. sie müssen gar nicht angepasst werden, weil die Positionsnr ja dynamisch erzeugt wird)

Ich suche jetzt eine passende Stelle, bei der ich diese Positionsnummer in meinem DataSet aufbauen kann. Dazu habe ich ein InternalCalcField, also ein Feld was nicht in die Datenbank geschrieben wird, und könnte das Feld über OnCalcFields entsprechend berechnen lassen. Ich muss also innerhalb von OnCalcFields irgendwie auf die Parent-Position zugreifen können
Wenn ich das möglichst performant gelöst kriege, ist mein Problem gelöst


Ich hatte sowas schon mal in .NET mit ORMs programmiert. Dort hatte ich zu jeder Position ein Property "Parent"... Die Positionsnr war dann auch nur ein Property, welches in etwa diesen Getter hatte:

markieren

Code:

if (this.Parent == null)
{
  value = this.OZ;
}else{
  value = this.Parent.Positionsnr + "." + this.OZ;
}

Meines Erachtens wäre es besser wenn du eine Funktion bereitstellst, die die Nummerierung übernimmt anhand eines Startwertes und man diese aktiv aufrufen muss.

Diese muss ja auch irgendwie festgeschrieben und nicht jedes mal neu berechnet werden.

Du gibst jedem Datensatz eine Feld für die Positionsnummer und schon läuft das ganze Ding...

Wie gesagt, genau das möchte ich eben nicht machen... Erfahrungsgemäß ist das fehleranfällig, und die Informationen werden teilweise redundant gespeichert.

Zitat von ibp:

Diese muss ja auch irgendwie festgeschrieben und nicht jedes mal neu berechnet werden.

Wenn gewährleistet ist, daß der "Vater" immer gleich bleibt, könnte man dies so lösen.

Kennt Firebird das "Connect by"? Damit kann man in Oracle solche verbindungen ablaufen.

Gruß
K-H

Zitat von Morphie:

Wie gesagt, genau das möchte ich eben nicht machen... Erfahrungsgemäß ist das fehleranfällig, und die Informationen werden teilweise redundant gespeichert.

ich meinte aber nicht den ganzen Zweig, sondern immer nur seine eigene Position...

Zitat:

Kennt Firebird das "Connect by"?

Nein, aber rekursive Common Table Expressions (CTE).