Erweiterbare/Verzweigte Baumstruktur in datenbank abspeicher

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
martinli
User
Beiträge: 10
Registriert: Freitag 25. Januar 2008, 17:54
Kontaktdaten:

Erweiterbare/Verzweigte Baumstruktur in datenbank abspeicher

Beitragvon martinli » Donnerstag 5. Juni 2008, 16:07

Moin,
ich will mein PHP/MySQL Adressbuch gern in Python umschreiben.
Allerdings will ich es auch im ein paar Kleine Details erweitern.
Die wichtigste Erweiterung soll darin bestehen dass ich die Personen in "Gruppen" einteilen können möchte.
-Freunde
__
-Schulfreunde
__-Unifreunde
-Arbeitskollegen
__-Abteilung 1
____-Bereich Nord
____-Bereich Süd
__-Abteilung 2

Also eigentlich eine normale Baumstruktur.
Nun möchte ich aber, dass eine Person auch gleichzeitig Schulfreund sein kann und Arbeitskollege der Abteilung 1 Bereich Süd.
Wie würdet ihr so etwas abspeichern?
Also ich mein eine "row" muss natürlich für die zugehörigkeit im Adressbuch vorhanden sein. Aber wie würdet ihr die Baumstruktur speichern? In einer eigenen tabelle?
Vielen Dank schon mal für eure Hilfe!
Martin
rayo
User
Beiträge: 773
Registriert: Mittwoch 5. November 2003, 18:06
Wohnort: Schweiz
Kontaktdaten:

Beitragvon rayo » Donnerstag 5. Juni 2008, 16:19

Hi

Ich würde es so machen:

Tabelle "person" mit allen Infos zur Person

Tabelle "category" mit Aufbau:
cat_id, name, parent

Tabelle "personInCategory" mit Aufbau:
p_id, cat_id

Somit kannst du beliebig viele Personen mit beliebig vielen Kategorien ablegen.

Bei der Kategorie ist einfach parent=0 wenn es keine weiteren Kategorien oberhalb mehr gibt.

Gruss
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Beitragvon audax » Donnerstag 5. Juni 2008, 17:09

http://dev.mysql.com/tech-resources/art ... -data.html

Joa...besser als die Website kann ich es auch nicht erklären :D

Allerdings würde ich dann später nen ORM draufknallen...bei den ganzen Join wird einem ja schwindelig ;)
[ jap. bin ein SQL-Weichei. ]
martinli
User
Beiträge: 10
Registriert: Freitag 25. Januar 2008, 17:54
Kontaktdaten:

Beitragvon martinli » Montag 9. Juni 2008, 22:50

also, wenn ich das richtig verstehe, dann würdet ihr einen Tabelle erstellen, die nur den Aufbau des Baumdiagrammes beinhaltet.
Klar, das von den Personen zu trennen ist vielleicht ganz sinnvoll. Aber eigentlich würde ich dann die "personInCategory" eher einfach in eine Zeile der "person" schreiben.

Nur den Aufbau der "category" verstehe ich noch nicht ganz.
cat_id Klar
name Ich gehe mal davon aus, dass das der Name der Kategorie ist, also beispielsweise Bereich Nord.
parent Nur hier weiß ich jetzt nicht so recht, wie ich das aufbauen soll.
Schreibe ich da einfach die nächst höhergelegene Kategorie hin? Oder gleich den ganzen Pfad?

Vielen Dank schon mal für eure Hilfe!
Martin
rayo
User
Beiträge: 773
Registriert: Mittwoch 5. November 2003, 18:06
Wohnort: Schweiz
Kontaktdaten:

Beitragvon rayo » Dienstag 10. Juni 2008, 05:37

martinli hat geschrieben:Klar, das von den Personen zu trennen ist vielleicht ganz sinnvoll. Aber eigentlich würde ich dann die "personInCategory" eher einfach in eine Zeile der "person" schreiben.


Somit könntest du nur noch 1 Kategorie pro Person zuweisen, mit einer extra Tabelle kannst du soviel du willst.

martinli hat geschrieben:Nur den Aufbau der "category" verstehe ich noch nicht ganz.
cat_id Klar
name Ich gehe mal davon aus, dass das der Name der Kategorie ist, also beispielsweise Bereich Nord.
parent Nur hier weiß ich jetzt nicht so recht, wie ich das aufbauen soll.
Schreibe ich da einfach die nächst höhergelegene Kategorie hin? Oder gleich den ganzen Pfad?


Beim parent schreibst du nur die cat_id der nächst höheren Kategorie rein, ausser bei den obersten, da kannste 0 reinschreiben.

Gruss
martinli
User
Beiträge: 10
Registriert: Freitag 25. Januar 2008, 17:54
Kontaktdaten:

Beitragvon martinli » Dienstag 10. Juni 2008, 07:00

Also ich hab das bisher so gemacht, dass ich die Zugehörigkeit zu mehreren Gruppen in einer Tabelle sozusagen mit einer csv gelöst habe:
8a5a0eae251267eb349bf9db3e09712d|
66723baaa17f1304f3ccd72aa5ea4d28|
b4d65d9d077a38b7647b3f1cf31fc2bc|
652d93163631fe003bc24e8f9affd3d1|
5b28a33f6a81e6a99563271ff8b04797|
f587e02939ff7f0474ad57eeb0e39e8c|

Dann sollte es auch klappen mehrere gruppen in eine Spalte zu schreiben.
Aber vielleicht leichter zu bearbeiten ist es natürlich wenn man pro Zeile nur eine Zugehörigkeit definiert.

Vielen dank noch mal!
Martin
Benutzeravatar
Hyperion
Moderator
Beiträge: 7471
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Beitragvon Hyperion » Dienstag 10. Juni 2008, 07:43

Was sollen uns diese cryptischen Angaben sagen?
martinli
User
Beiträge: 10
Registriert: Freitag 25. Januar 2008, 17:54
Kontaktdaten:

Beitragvon martinli » Dienstag 10. Juni 2008, 07:47

naja, ich habe in meinem altern adressbuch auch Gruppen, aber nur in zwei ebenen, Also Gruppen und Untergruppen.
Und um nicht nach den Gruppennamen suchen zu müssen, habe ich alles als md5 hast gespeichert.
Wie gesagt, ich habe alle zugehörigkeiten in einer einzigen spalte. Bisher habe ich dafür keine eigene Tabelle angelegt.
Es ist halt die Frage, was besser ist?
Gruß
Martin
BlackJack

Beitragvon BlackJack » Dienstag 10. Juni 2008, 09:31

Ehrlich gesagt habe ich's immer noch nicht verstanden. Du hast (Gruppen)Namen durch Hashes ersetzt? Und statt nach den Namen, kann bzw. muss man jetzt nach den Hashes suchen?
Benutzeravatar
Hyperion
Moderator
Beiträge: 7471
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Beitragvon Hyperion » Dienstag 10. Juni 2008, 10:14

Und zusätzlich: Du hast alle in einer Spalte stehen und trennst sie durch ein Trennzeichen? (Wenn ja: GANZ schlecht Idee - Verletzung der 1NF!)
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Beitragvon Y0Gi » Dienstag 10. Juni 2008, 11:14

Mein Ansatz: SQLAlchemy, Adjacency List Relationships für Gruppen und 'ne n:m-Verknüpfung mit den Personen (als separate Entität).
rayo
User
Beiträge: 773
Registriert: Mittwoch 5. November 2003, 18:06
Wohnort: Schweiz
Kontaktdaten:

Beitragvon rayo » Dienstag 10. Juni 2008, 11:53

Ja schreib nie mehrere Werte in eine Zelle einer Datenbank, macht abfragen mühsam, verletzt die 1. Normalform (wie schon von Hyperion genannt).

Nimm lieber eine 2. Tabelle und erstell pro Kategoriezugehörigkeit einen Eintrag.

Gruss
martinli
User
Beiträge: 10
Registriert: Freitag 25. Januar 2008, 17:54
Kontaktdaten:

Beitragvon martinli » Mittwoch 18. Juni 2008, 13:28

Hm, also ich suche nach dem hash, weil ich das für eindeutiger halte.
Zudem, kann es bei meinem neuen Vorhaben, eine richtige Baumstruktur zu erstellen auch mal dazu kommen, dass es einen Kategorienamen doppelt gibt. Spätestens da muss eine Kategorie genauer definierbar sein als durch den Namen.
Und zum Thema "Ein Datensatz/Feld":
also eigentlich hab ich das bei fast allen Daten auch so gehandelt.
In der neuen Version möchte ich aber das Adressbuch auch erweitern können. Entweder ich lege zu jeder Erweiterung eine neue Tabelle an, das finde ich eigentlich etwas doof, weil ich dann später eine Vielzahl von Tabellen habe.
Hm, also ich will jetzt nicht sagen, dass ich mir das ganze nicht noch mal überlegen werde, Aber irgendwie werft ihr meine bisherigen Gedanken ein wenig durcheinander!
Vielen dank für eure Hilfe!
Martin
BlackJack

Beitragvon BlackJack » Mittwoch 18. Juni 2008, 13:42

Ein Hashwert ist eindeutiger als *was*? Wenn zwei Kategorien den gleichen Namen haben, dann kommt da auch der gleiche Hashwert heraus. Das ist ja gerade das schöne und praktische an Hashwerten: Gleiche Eingaben ergeben den gleichen Hashwert.

Und ja, bei relationalen Datenbanken hat man am Ende mehrere Tabellen. Das ist das Prinzip einer relationalen Datenbank: verschiedene Tabellen, zwischen denen es Relationen gibt. Daher der Name. ;-)

Wenn es im Baum Knoten mit den gleichen Namen geben kann, dann kann man ganz offensichtlich den Namen nicht als eindeutige ID verwenden. In den meisten Fällen ist es sowieso besser eine künstliche ID zu verwenden.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7471
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Beitragvon Hyperion » Mittwoch 18. Juni 2008, 13:51

martinli hat geschrieben:Hm, also ich suche nach dem hash, weil ich das für eindeutiger halte.

eindeutiger als was?
Zudem, kann es bei meinem neuen Vorhaben, eine richtige Baumstruktur zu erstellen auch mal dazu kommen, dass es einen Kategorienamen doppelt gibt. Spätestens da muss eine Kategorie genauer definierbar sein als durch den Namen.

Wie wäre es durch eine id? ;-) Wobei ich noch immer nicht genau verstanden haben, was eine Kategorie ist!
Und zum Thema "Ein Datensatz/Feld":
also eigentlich hab ich das bei fast allen Daten auch so gehandelt.
In der neuen Version möchte ich aber das Adressbuch auch erweitern können. Entweder ich lege zu jeder Erweiterung eine neue Tabelle an, das finde ich eigentlich etwas doof, weil ich dann später eine Vielzahl von Tabellen habe.

Wieso das denn? Generell kann man die Attribute eines Adresseintrages ja auch in einer Zeile einer Tabelle speichern. Du müßtest also nur bei einem neuen Feld (ICQ-NUmmer o.ä.) einfach eine Spalte dranhängen, nicht aber eine neue Tabelle.
CSV in einer Zelle ist tödlich! Lass es Dir noch mal gesagt sein!
Hm, also ich will jetzt nicht sagen, dass ich mir das ganze nicht noch mal überlegen werde, Aber irgendwie werft ihr meine bisherigen Gedanken ein wenig durcheinander!
Vielen dank für eure Hilfe!
Martin

Das mag daran liegen, dass Du konzeptionelle Fehler machst! Ich kapiere nicht, wieso Du es nicht folgendermaßen löst:

Code: Alles auswählen

create table kontakt (
  // Personendaten
)

create table kategorien (
  id int primary key,
  name varchar,
  parent int,
  foreign key id references (katgegorien.id)
)

// und nun die n:m-Relation

create table kontakt_in_kategorie (
  kontaktid int,
  kategorieid int,
  primary key(kontaktid, kategorieid)
)

Das ist jetzt kein kirrektes SQL, aber sollte die Struktur klar machen. In Kontakt steht ein spezieller User. In Kategorien kannste verschiedene "Gruppen" hierarchisch zusammenpacken. Schließlich kannst Du einer Kategorie einen User zuordnen. Dieser kann in beliebig vielen Kategorien sein und jede Kategorie kann beliebig viele User haben. Das ist es doch, was Du willst?

Als Bonus kannste sogar einer Person nur in einer Gruppe spezielle Attribute zuweisen ;-)

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder