• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

Wie am besten dar stellen / Datenbankstruktur

T

ToM80

Guest
Hallo zusammen,

ich erstelle der Zeit eine Intranet, was auch eine Bilddatenbank enthällt.
Nach ersten Praxistest, hat sich gezeigt, das mein bisheriges Modell der Keyword-Zuordnung zu den Bildern uneffektiv ist.
Die Bilder müssen halt "vertaggt" werden, damit sie später mittels Suche gefunden werden können.

Nach langen Überlegungen bin ich zu folgender Tabellenstruktur gekommen

SuchwortID | SuchwortName | SuchwortEltern | SuchwortKinder |

Ich hab mir folgendes dabei gedacht:
ID klar, eindeutige Identifizierer.
Name: auch klar, das eigentliche Suchwort
Eltern: ID des übergeordneten Suchworts
Kinder: Array mit ID's der untergeordneten zugehörigen Suchwörter

Das ganze soll später als Baumstruktur aufklappen und man somit weitere Suchwörter ohne manuelle Texteingabe dem Bild zuordnen können.
Hier mal ein Baum von Oben (Kontinent) bis Unten (Dogenpalast):

Kontinent->Europa->Länder->Italien->Regionen->Venetien->Städte->Venedig->Stadtteile->San Marco->Sehenswürdigkeiten->Gebäude->Dogenpalast

Die Frage ist, ob das ganze sehr sinnvoll ist, da ich denke, dass es sehr Ressourcen fressend ist.
Denn wenn ich mich nicht täusche müsste ich hergehen und folgende Abfragen generieren:
Suchwort das dem Bild (Dogenpalast) zugeordnet wurde: Italien
Jetzt sollen die verwandten Suchwörter in der Baumstruktur gezeigt werden:
1. Alle Datensätze aus der Suchwörtertabelle auslesen und als Array abspeichern
2. Suche im Array Suchwörternamen nach "ITALIEN" und ermittele die Position und speichere sie als swPos
3. Speichere die ID aus dem Array SuchwortID aus der Position swPos als swID
4. Speichere die Kinder aus als swKinder und das Elternelement unter swEltern

Jetzt habe ich schon mal alle nötigen Angaben für ITALIEN, jedoch muss ich jetzt a) mittels der Elternelemente mich nach oben bewegen, bis Kontinent
und b) mich mittels der Kinder nach unten bewegen.

Finde ich ziemlich kompliziert, aber mir ist nichts anderes eingefallen, vllt. hat ja, so fern überhaupt jemand durch mein Geschriebenes durchsteigt, eine(r) von euch eine Idee, Meinung, Vorschlag?
 
Also in die Tabelle gehören die Links auf die Kinder nicht rein, denn davon gibt es ja mehrere.
Rein von der Datensicht her brauchst Du zum Abbilden in der Datenbank nur die ID, den Namen und die ParentID. Per SQL könntest Du so alles erreichen, Du kriegst das direkte Parent Element zu einem Eintrag raus und Du kriegst raus, welche Childs es gibt, usw.

Sonderlich schnell ist es aber nicht, denn um Dich komplett von unten nach oben zu hangeln, sind etliche SQL Befehle notwendig und die kosten Zeit.
Um das auch einigermaßen vernünftig benutzen zu können, muss also irgendwas zusätzliches her. Mein Vorschlag: eine zusätzliche Spalte "Pfad". Dieser Pfad gibt den kompletten Pfad bis zum aktuellen Element in z.B. Verzeichnisschreibweise an.
Für Dogenpalast würde dort also "/Kontinent/Europa/Länder/Italien/Regionen/Venetien/Städte/Venedig/Stadtteile/San Marco/Sehenswürdigkeiten/Gebäude" stehen, das Feld muss natürlich entsprechend gross ausfallen. Dadurch hast Du zwar doppelte Datenhaltung und bist nicht mehr wirklich bei dritter Normalform, aber manchmal muss man eben von sowas abweichen.
Nun kannst Du aber sofort alle Parentelemente ablesen, kannst alle Childs, aller Unterknoten auslesen und Du kannst auf einfache Weise verhindern, dass im Edit Modus Zweige als Kinder von sich selbst oder deren Kindern zugeordnet werden (d.h. keine zyklische Zuordnung).

Du hast natürlich etwas mehr Verwaltungsaufwand zu betreiben, aber das Ergebnis dürfte besser aussehen.
Wenn Du z.B. noch zusätzlich den Direktzugriff auf die IDs der Parents entlang des Pfades brauchst, denn hindert Dich ja niemand eine weitere Spalte anzulegen, die die IDs in ähnlicher Form abbildet also "/1/3/17/188/190/..." (oder auch als Hex-Werte)
 
Wenn ich dich richtig verstehe, würdest du die Childs nirgends aufnehmen.
Das mit dem kompletten Pfad hatte ich auch schon überlegt.
Begründung warum ich das nicht gemacht habe:

Erstmal warum ich die Kinder haben möchte:
Am Bsp Italien.
In dem Pfad "Kontinent/Europa/Länder/Italien/Regionen/Venetien/..."
kommt nach Italien das Suchwort Regionen. Hier sollen bei Italien natürlich nur die italienischen Regionen aufgeführt werden, während wenn man nur den Ordner" Regionen öffnet, alle erfassten Regionen als z. B. auch Schwarzwald, Rhön... angezeigt werden.
Deshalb wollte ich die Spalte Kinder haben, um nur die relevanten unter Ordner anzuzeigen. Bei Italien wäre dann als Kind halt Venetien, nicht aber Regionen gespeichert.
Regionen zeigt sich am Ende wiederrum an, da es dass Elternelement von Venetien ist.
Die kompletten Zielpfade gehen halt aus gleichen Gründen auch nicht, da Region nicht immer mit Italien verbunden ist ;)
 
Also ich würde z.B. "Regionen" dann einfach mehrfach aufnehmen. Mit einem Select kann man dann ja trotzdem alle Regionen aller Länder ausfindig machen, natürlich nur wenn man "Regionen" überall gleich geschrieben hat.
Ansonsten machst Du Dir nur das Leben schwer.

Was Du mit den Childs machen willst habe ich nicht so 100% kapiert. Sollen die je nach Länderauswahl umsortiert werden, oder wie? Woher weißt Du denn, welche relevant sind, wenn "Regionen" länderübergreifend ausgelegt ist?
 
Das muss ja manuell vorher angegeben werden und das wollte ich im Child speichern.

Also der User träg will das Suchwort Rhön aufnehmen. Nach Eingabe erscheint der Baum mit sämtlich zur Verfügung stehenden Suchwörtern, aus denen er nun diejenigen aussuchen kann, die dem Wort Rhön zugeordnet werden können. Z. B. Wälder, Fulda, Mittelgebirge, Bayern, Hessen, Thüringen, Wasserkuppe...
 
Eine komplette Baumstruktur lässt sich auch mit einem einzigen Query auslesen. Gibt genug Artikel darüber, hier mal einer auf deutsch.
 
Die Problematik ist nicht die Baumstruktur an sich, sondern die, dass die Elemente der Baumstruktur mehrere unterschiedliche Parents haben können ;)

Hi meto, nach nochmaligen durchlesen, ist mir aufgefallen, dass die nested set Methode mir doch helfen kann.
Danke dafür, werde meine DB dementsprechend umbauen :)
 
Zuletzt bearbeitet von einem Moderator:
Also nach längeren Überlegen ist die Struktur nur die halbe Miete.
Ich müsste dann für jedes Bild einen eigenen Baum an Suchwörtern anlegen.
Ob das so ideal ist weiß ich nicht, aber was besseres ist mir auch immer noch nicht eingefallen, denke mal ich werde es so machen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben