"We are back" « oc.at

mapping-table

Oculus 09.03.2004 - 11:34 1242 10
Posts

Oculus

void
Avatar
Registered: Jun 2001
Location: schlafzimmer
Posts: 856
ich habe 10 tables, deren primary-keys zu anderen 2 tables und 2 werten gemappt werden sollen

ein hässliches bild, um das zu veranschaulichen

mapping.jpg

user und group sind eigentlich nur die namen der benutzer und gruppen
X und Y sind dagegen normale tables

wie verpack ich das jetzt am besten in eine einzige mapping-tabelle?
bzw wie schaut die schönste lösung für dieses problem aus?

trigger möcht ich vermeiden, und es sollte auch nicht unbedingt zuviel speicher verbraten (>50000 zeilen)

freu mich über jeden vorschlag

atrox

in fairy dust... I trust!
Avatar
Registered: Sep 2002
Location: HTTP/1.1 404
Posts: 2782
gibt es einen supertyp für die tabellen ? wenn ja, verwende dessen key für eine n:m verknüpfung (also mit einer zwischentabelle) - oder du verwendest entsprechende zwischentabllen für jede mögliche verknüpfung.

wenn du alle diese verknüpfungen "gleich" behandeln willst/möchtest/mußt koönntest du dir auch überlegen eine tabelle zu machen, in der du die PKs von A..J, X..Y sammelst - allerdings kann es dann, je nachdem welche DB du verwendest, probleme geben, über die NULL-Values der nichtbenutzten schlüsseln, einen vereinigten PK zu legen.

überhaupt, drängt sich der verdacht auf, daß hier fehler bei der datenmodellierung/normalisierung begangen worden sind. vielleicht willst du ja dein design erklären ?

Oculus

void
Avatar
Registered: Jun 2001
Location: schlafzimmer
Posts: 856
design schaut so aus:

typ, typgruppe, typgruppenmapping
diese 3 tabellen zb für drucker, druckergruppe und druckergruppenmapping

jetzt soll eben für ads-user/gruppen und clients/clientgruppen (die auch wieder über eine gruppenmapping-table verknüpft sind) ein mapping definiert werden

clients haben drucker, clientgruppen haben drucker, clients haben druckergruppen, clientgruppen haben druckergruppen etc.

es wäre relativ einfach mit einer dicken fetten mapping tabelle mit allen FKs als spalten, wobei eben immer nur 2 felder ausgefüllt sind
zb. client-id 1, drucker-id 1, alles andere NULL oda irgenda standardwert (wobei ich dann in jeder table dummy-einträge bräuchte wegen FK-integrität)
oder zb. ads-user "oculus", drucker-id 1 und alles andere NULL

mit so einer dicken table wärs auch kein aufwand, alle mappings für einen zu löschenden client zu entfernen. wird einfach cascaded über den FK

allerdings ist die table eben extrem fett, und wird durchaus bis zu 50, 80mb gross, was net unbedingt zielführend is
ausserdem, pro zeile 2 von 12 spalten sinnvoll nutzen is *****, des kanns net sein

aber i bin an dieser idee festgefahren und weiss sonst nix anderes ;)

watchout

Legend
undead
Avatar
Registered: Nov 2000
Location: Off the grid.
Posts: 6845
wie wärs wenn du 4 tabellen machst:
typen
einheiten (vormals drucker,clients,...)
gruppen
mappings

und bei den tabellen wo du's brauchst machst du noch ein feld "typ" dazu
leider weiss ich ja nix über die restliche datenstruktur, aber ich denke so wirds bisserl übersichtlicher ;)

Oculus

void
Avatar
Registered: Jun 2001
Location: schlafzimmer
Posts: 856
das is leider net möglich, da ein drucker völlig unterschiedliche informationen hat wie ein client
die tabellen sind also völlig verschieden

so a generisches modell is also net unbedingt geeignet

watchout

Legend
undead
Avatar
Registered: Nov 2000
Location: Off the grid.
Posts: 6845
hmm, aber zumindest die gruppen müssten doch immer die gleichen informationen beinhalten - unabhängig vom typ

übrigens seh ich eigentlich keinen sinn einer mapping-table, oder sind gruppen:einheiten nicht 1:n verknüpft?

Oculus

void
Avatar
Registered: Jun 2001
Location: schlafzimmer
Posts: 856
ok, das hast du falsch verstanden und ich schlecht erklärt :)

es gibt für jede(n) typ und typgruppe ein gruppenmapping, ja
aber die große mapping-tabelle mappt typen UND typgruppen zu clients, clientgruppen, ads-usern und ads-gruppen

man soll also zb einem client beliebige typgruppen und einzelne typen zuweisen können
zb client xyz hat druckergruppe "filiale1" und drucker "laserjet", wobei zu der druckergruppe "filiale1" wiederum beliebig viele drucker gemappt sind

ich hab eben 2 möglichkeiten:
unterscheide ich zwischen gruppen und einzelnen mappings?
oder blase ich per procedure ein gruppenmapping auf die einzelnen mappings auf?
bei zweiterem würd ich mir schonmal die hälfte der spalten in der mapping-table ersparen, auf kosten von vielfachen zusätzlichen zeilen
(edit: dann bräucht ich aber wieder trigger, um die mappings aktuell zu halten, wenn sich bei typgruppen was ändert -> schas)
Bearbeitet von Oculus am 09.03.2004, 22:30

watchout

Legend
undead
Avatar
Registered: Nov 2000
Location: Off the grid.
Posts: 6845
also, ich hab das glaubich noch immer net ganz geschnallt... :rolleyes: :D
aber ich tät sagen, es is gscheiter weniger spalten/tabellen zu haben als weniger zeilen zu haben, vor allem wenn es sich nur um mapping-tables handelt

Oculus

void
Avatar
Registered: Jun 2001
Location: schlafzimmer
Posts: 856
na schau:
es soll einem client beliebige drucker zugewiesen werden
und um das zu vereinfachen, soll man drucker zu gruppen zusammenfassen und natürlich dem client dann diese druckergruppe zuweisen können, wobei man noch immer die option für einzelne drucker hat
und da man mehrere clients zu clientgruppen zusammenfassen kann, soll man natürlich auch diesen clientgruppen drucker(gruppen) zuordnen können

im endeffekt zieht dann die spezifischste zuweisung (client vor clientgruppe, drucker vor druckergruppe)

und das jetzt nicht nur für drucker, sondern auch andere objekte wie zb. shortcuts, verzeichnisse etc.

atrox

in fairy dust... I trust!
Avatar
Registered: Sep 2002
Location: HTTP/1.1 404
Posts: 2782
nachdem sich deine drucker, druckertypen usw so extrem unterscheiden, daß du sie nicht vereinheitlichen kannst/willst, macht imho auch eine gemeinsame mapping-table keinen sinn.

wenn es 1:n beziehungen sind, bist du fein raus; wenn es n:m beziehungen sind, brauchst du zwischentabellen.

wenn du jetzt aber alle drucker eines clients haben willst, mußt du einerseits direkt das druckermapping als auch das druckergruppenmapping durchsuchen (vorteilhaft, wenn deine datenbank ein UNION unterstützt) - oder du sagst, du verzichtest auf die direkten drucker-mappings und führst s.g. implizite druckergruppen ein: das sind speziell gekennzeichnete druckergruppen mit nur einem "member" die automatisch bei einem einzelmapping angelegt werden und wieder gelöscht werden. weil du sie über irgendein feld gekennzeichnet hast, scheinen sie auch bei der normalen ansicht der druckergruppen nicht auf; aber du hast den vorteil daß du über ein einziges druckergruppen-join alle drucker eines kunden erhälst - sowohl die expliziten gruppen (die die willentlich zu gruppen zusammengefaßt wurden) als auch die impliziten gruppen (die einzelzuweisungen, die über eine "phantom"gruppe gelöst werden)
Bearbeitet von atrox am 10.03.2004, 01:20

Oculus

void
Avatar
Registered: Jun 2001
Location: schlafzimmer
Posts: 856
das hab ich jetzt nicht ganz verstanden
ich glaub, ich weiss, was du meinst, aber ich weiss nicht, wie ich das für mein problem nutzen soll :)

werds jetzt über zwischentabellen lösen, für jeden typ eine mapping-table
sind zwar viele tabellen, aber es erspart mir einiges an komplizierter logik
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz