Oculus
void
|
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 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!
|
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
|
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
Legendundead
|
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
|
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
Legendundead
|
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
|
ok, das hast du falsch verstanden und ich schlecht erklärt ![:)](/images/smilies/smile.gif) 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
Legendundead
|
also, ich hab das glaubich noch immer net ganz geschnallt... ![:D](/images/smilies/biggrin.gif) 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
|
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!
|
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
|
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 ![:)](/images/smilies/smile.gif) 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
|