Laden...

Entwicklung einer Datenstruktur/Datenbankstruktur

Erstellt von Tisdo vor 9 Jahren Letzter Beitrag vor 9 Jahren 2.327 Views
T
Tisdo Themenstarter:in
17 Beiträge seit 2015
vor 9 Jahren
Entwicklung einer Datenstruktur/Datenbankstruktur

Hallo Zusammen,
ich bräuchte hier einen Rat zum Thema Datenstruktur/Datenbank-„Design“.
Zum Verständnis (vereinfacht): Ich habe eine Position (z.B. Holzrahmen) die aus verschiedenen Profilen (Rundprofil, Rechteckprofil) aufgebaut werden soll. Die Profile an sich können verschiedene Maße haben, also z.B. sind sie in einem Breitenraster 20, 25, 30, 35 mm verfügbar.

Mein Denkansatz, um sowas in einer Datenbank abzubilden, wäre: Die Profile werden zunächst mit den möglichen Maßen in den „Stammdaten“ hinterlegt:

class SdRechteckprofil
{
	Int[] Breitenmaße = {20, 25, 30, 35};
	// noch viele andere Maße und Eigenschafte (Farbe, usw. )
}

In einer Position können die Profile jedoch nicht mehr „variabel“ sein, sondern „fix“, da sonst die Position nicht eindeutig aufgebaut ist. Also hab ich mir folgendes überlegt:

class Rechteckprofil
{
	SdRechecktprofil SdRP;
	Int Breite; //Mit Set/Get wird geprüft, ob Breite möglich ist
}

Und dann natürlich Schlussendlich:

class Position
{
	Rechtecktprofil RP;
}

Die Datenbank ist eine Objektdatenbank. Da es doch recht unterschiedliche Profile mit vielen Möglichkeiten gibt, spare ich mir so das Mapping der Felder.
Überlegung des Ganzen:

  • Ich brauche, während ich die Position bearbeite alle Informationen bis runter in die Datenbank. Rufe ich die Position in diesem Format einmal auf, habe ich sofort sämtliche Daten die ich benötige.
  • Da ich nicht einfach in jede Position die benötigten Profile der Stammdaten kopiere, spare ich Speicherplatz. (wobei das vermutlich standartmäßig so gemacht wird, hier fehlt mir die Erfahrung)
  • Änderungen an den Stammdaten werden sofort in die Profile/Positionen übernommen.
  • Nicht jede Variation der Profile kann eine eigene Klasse bekommen, dafür gibt es viel zu viele Kombinationsmöglichkeiten.

Was haltet ihr von diesem System, was wäre eure Lösung?
Muss dazu sagen, dass ich noch sehr sehr wenig mit Datenbanken zu tun hatte.

Mit freundlichen Grüßen

Edit: Rechtschreibung

C
2.121 Beiträge seit 2010
vor 9 Jahren

Ich muss sagen ich habe die Aufgabenstellung nicht verstanden. Nachdem noch niemand was dazu gesagt hat bin ich vielleicht nicht der einzige.

Du schreibst von einem Denkansatz wie du das in der DB ablegst und zeigst dann eine Klasse. Hängt das damit zusammen dass du eine Objektdatenbank hast, damit speicherst du dir die möglichen Breiten in einem Array eines einzigen Eintrags in dieser Tabelle?
Das würd ich nicht so machen. Stammdaten die nur aus Zahlen bestehen würde ich auch wirklich nur als Zahl speichern. Eine pro "Zeile".

Da es doch recht unterschiedliche Profile mit vielen Möglichkeiten gibt, spare ich mir so das Mapping der Felder.

Was bedeutet das?

Nicht jede Variation der Profile kann eine eigene Klasse bekommen, dafür gibt es viel zu viele Kombinationsmöglichkeiten.

Meinst du Klasse (eine eigene class die separat definiert ist) oder eine eigene Instanz einer gemeinsamen Klasse?
Es muss ja nicht jede Kombination in der DB stehen. Du muss nur irgendwie feststellen können ob die Kombination erlaubt ist oder nicht.

Wenn du eine Position anlegst würde ich da die Maße und sonstigen Angaben direkt reinschreiben.
Bisher verstehe ich dich so, du hast eine Position die das Ergebnis einer Konfiguration ist.
In der gibts einen Verweis auf Rechteckprofil und darin wieder einen auf SdRechecktprofil. Das sind die Stammdaten nehme ich an? Wozu braucht ein Rechteckprofil einen Verweis auf sämtliche (!) Möglichkeiten der Stammdaten? Dann hat jede Position einen Verweis auf sämtliche Möglichkeiten die zur Verfügung standen, das ist doch nicht nötig. Platz spart es auch nicht wirklich.

T
Tisdo Themenstarter:in
17 Beiträge seit 2015
vor 9 Jahren

Zur Aufgabenstellung:
Rahmenbedingungen sind: Ich möchte Positionen anlegen, die aus verschiedenen Profilen, mit vielen verschieden Variationsmöglichkeiten, aufgebaut sind. Alles andere ist frei gestaltbar.

Mein erster Denkansatz ist: Die Profile mit ihren Variationen werden zunächst in den sogenannten "Stamdaten" gespeichert. Aus diesen Stammdaten wird die Position in einer möglichen Variation der Profile aufgebaut. Objektdatenbank, um die Daten möglichst handlich zu haben, das Speicher- und Abrufprinzip hat mir sofort gefallen.

Du schreibst von einem Denkansatz wie du das in der DB ablegst und zeigst dann eine Klasse. Hängt das damit zusammen dass du eine Objektdatenbank hast, damit speicherst du dir die möglichen Breiten in einem Array eines einzigen Eintrags in dieser Tabelle?
Das würd ich nicht so machen. Stammdaten die nur aus Zahlen bestehen würde ich auch wirklich nur als Zahl speichern. Eine pro "Zeile".

Objektdatenbank heißt ja, dass ich komplette Instanzen einer Klasse speichere und auch so wieder abrufe. Intern, da hast du Recht, wäre das Array ein einziger Eintrag in der Tabelle der Datenbank, wobei das hier eigentlich in keinster Weise zum tragen kommt, denn wenn ich die Daten abrufe, werde ich nicht nur die möglichen Breiten benötigen. Insofern verstehe ich dich hier nicht.

Da es doch recht unterschiedliche Profile mit vielen Möglichkeiten gibt, spare ich mir so das Mapping der Felder.

Was bedeutet das?

In relationalen Datenbanken müsste ich zum speichern/abrufen Stringbefehle für jede Klasse erstellen(die Felder der Tabelle zuordnen/mappen), und die erhaltenen Daten aufdröseln und einer Klasse bzw. ihren Feldern zuordnen, was hier ein ziemlicher Aufwand wäre, wie ich finde. Dies würde bei der Objektdatenbank wegfallen.

Meinst du Klasse (eine eigene class die separat definiert ist) oder eine eigene Instanz einer gemeinsamen Klasse?

Angenommen ich würde jede mögliche Variation in einer eigenen Instanz einer Klasse in der Datenbank speichern, würde das für meinen Geschmack zu unüberschaubaren Datensätzen führen. Da sträube ich mich innerlich dagegen.

Wenn du eine Position anlegst würde ich da die Maße und sonstigen Angaben direkt reinschreiben.

Das habe ich mir auch überlegt. Das Problem, das ich darin sehe, ist die Übersichtlichkeit. Ohne die "Zwischenklasse" (hier: Rechteckprofil), müsste ich hier sehr viele Informationen in der Position unter bekommen. Mit Zwischenklassen wären die Daten mehr gekapselt (sagt man das so?). Grade im Hinblick darauf, dass die Daten der Profile teilweise stark übereinstimmen und teilweise klare Unterschiede haben, würde hier die Zuordnung wesentlich leichter fallen.

Bisher verstehe ich dich so, du hast eine Position die das Ergebnis einer Konfiguration ist.

Richtig.

In der gibts einen Verweis auf Rechteckprofil und darin wieder einen auf SdRechecktprofil. Das sind die Stammdaten nehme ich an?

Also SdRechteckprofil wären die Stammdaten, richtig.

Wozu braucht ein Rechteckprofil einen Verweis auf sämtliche (!) Möglichkeiten der Stammdaten? Dann hat jede Position einen Verweis auf sämtliche Möglichkeiten die zur Verfügung standen, das ist doch nicht nötig.

Angenommen ich bin in der Erfassung, wo Positionen angelegt und geändert werden, und beziehen uns nur mal auf das Ändern. Dann hätte ich mit einem Aufruf der Position alle Änderungsmöglichkeiten vorliegen und kann diese dem Bearbeiter anbieten. Den Vorteil sehe ich dabei in "mit einem Aufruf". Ich muss nicht erst 10 Anfragen an die Datenbank stellen, bis ich alle Daten habe, die ich benötige. Aber vielleicht hast du Recht, das muss ich mir nochmal durch den Kopf gehen lassen.

Platz spart es auch nicht wirklich.

Da nur ein Verweis und nicht eine Kopie der Stammdaten gespeichert wird, dürfte es nur einen sehr kleinen Teil ausmachen.

Die Klasse Position müsste dann auch wohl eher so aussehen(sagen wir mal für einen rechteckigen Rahmen, wobei später auch 5 oder mehr Ecken möglich sein sollen):


class Position
{
       object ProfilLinks;
       object ProfilOben;
       .....

       //Oder so
      object[] profile; //Beginnend links oder so
}

Hilft diese Erklärung? Bin mir grade nicht sicher ob es das hier schlimmer oder besser macht.

C
2.121 Beiträge seit 2010
vor 9 Jahren

Mein erster Denkansatz ist: Die Profile mit ihren Variationen werden zunächst in den sogenannten "Stamdaten" gespeichert.

richtig das ist sinnvoll.
Wie du dann die Daten ablegst mag vielleicht wirklich in deinem Fall egal sein. Du kannst halt nicht mehr schnell prüfen, ist Wert 25 erlaubt, denn du musst immer erst ein Objekt laden um das zu prüfen. Wenn du die Objekte sowieso immer geladen hast ist es aber erst mal egal wie du das machst.

Objektdatenbank, um die Daten möglichst handlich zu haben

Es ist nicht viel Arbeit sowas zu speichern, das stimmt. Aber ändere mal was am Aufbau deiner Objekte. Nenne zum Beispiel ein Feld um. Tut die ganze Automatik dahinter dann wirklich immer noch was sie soll? Mach dich mit deiner DB auch mit Wartungsaufaben vertraut. Kannst du wirklich einfach (handlich) herausfinden was gerade alles in der DB steht? Kriegst du eine Übersicht aller Stammdaten durch ein Tool heraus wenns sein muss oder musst du dann dein Programm erweitern, Objekte laden und die visualisieren? "handlich" darf sich nicht nur aufs erste programmieren beziehen sondern sollte auch Fehlersuche und Erweiterungen einschließen.
Ich kenne Objektdatenbanken wie gesagt nicht besonders, das sind aber alles Punkte über die ich Bescheid wissen will bevor ich eine nutze.

Mit Zwischenklassen wären die Daten mehr gekapselt

Auch richtig. Ich meinte warum du die Stammdaten aller möglichen sonstigen Profile überall dazu speicherst. Siehe nächster Punkt.

Da nur ein Verweis und nicht eine Kopie der Stammdaten gespeichert wird

Wenn das so ist ... bist du sicher dass die DB das so speichert? Dazu müsste sie erkennen dass sie genau dieses Objekt schon gespeichert hat und sie nur einen Verweis drauf anlegen muss. Da bin ich mir nicht sicher. Woher soll sie erkennen können dass bei einer neuen Position das Referenzobjekt genau das ist das sie früher mal in einer ganz anderen Position schon mit gespeichert hat. Das solltest du ebenfalls rausfinden. Falls das nämlich nicht so ist, hast du Chaos.

T
Tisdo Themenstarter:in
17 Beiträge seit 2015
vor 9 Jahren

Es ist nicht viel Arbeit sowas zu speichern, das stimmt. Aber ändere mal was am Aufbau deiner Objekte. Nenne zum Beispiel ein Feld um. Tut die ganze Automatik dahinter dann wirklich immer noch was sie soll? Mach dich mit deiner DB auch mit Wartungsaufaben vertraut. Kannst du wirklich einfach (handlich) herausfinden was gerade alles in der DB steht? Kriegst du eine Übersicht aller Stammdaten durch ein Tool heraus wenns sein muss oder musst du dann dein Programm erweitern, Objekte laden und die visualisieren? "handlich" darf sich nicht nur aufs erste programmieren beziehen sondern sollte auch Fehlersuche und Erweiterungen einschließen.

In der Art wollte ich mich hier auch informieren, sollte in einem 2. Thread geschehen, werde aber vorerst nochmal auf eigene Faust probieren und nach Infomaterial suchen.
Ein Tool zum Auslesen der Daten gibt es.

Wenn das so ist ... bist du sicher dass die DB das so speichert? Dazu müsste sie erkennen dass sie genau dieses Objekt schon gespeichert hat und sie nur einen Verweis drauf anlegen muss.

Ja, hierauf legt die Doku ziemlich viel Wert drauf, das zu zeigen. Wie das intern gemacht wird weiß ich nicht, aber meine ersten Versuche bestätigen, dass es funktioniert.