2011-01-05 20 views
0

Ich frage mich, ob es eine vernünftige Idee ist, Active Directory zum Speichern von Entitäten zu verwenden, die zu einer Anwendung gehören, wenn nicht alle Entitätstypen die traditionellen AD-Entitäten wie Organisationseinheit, Benutzer, Gruppe, etc.Active Directory zum Speichern von Daten verwenden

Im Moment habe ich ein Datenbankschema, bestehend aus Dingen wie Kunden und Benutzern. Jeder Kunde kann seine eigenen Abteilungen haben. Jede Abteilung kann mehrere Benutzer haben. Jeder Benutzer kann einen Namen, Authentifizierungsdetails usw. haben. Ein Kollege erinnerte mich daran, dass Active Directory bereits über eine Infrastruktur verfügt, die diese Art von Hierarchien unterstützt. Daher ist es möglicherweise nicht optimal, diese von Grund auf neu zu erstellen.

Jetzt ist mein Problem, dass ich viel mehr Entitäten als nur Kunden, Benutzer und so weiter benötigen werde. Ich muss Statistiken, Dokumente, Kontakte (die keine Benutzer im System sind) und andere Informationen speichern. Um eine Zahl aus dem Nichts auszuwählen, können 10-20 zusätzliche Entitätstypen vorhanden sein, die nicht bereits in Active Directory vorhanden sind. Diese Entitätstypen werden mit Kunden, Benutzern usw. verknüpft. Die Benutzer in diesem System sind keine Benutzer in meinem lokalen Netzwerk, sondern greifen über das Internet auf meine Software zu.

Ich habe nur ein sehr vages Verständnis von Active Directory, aber wie ich es verstehe, müsste ich das AD-Schema erweitern, um meine eigenen Entitäten zu speichern. Ich müsste Eigenschaften zu "Organisationseinheit" wie "Dokumentenliste" hinzufügen.

Eine alternative Methode könnte darin bestehen, sich auf die Organisationseinheiten, Benutzer und Gruppen in AD zu stützen und eine separate MSSQL-Datenbank zum Speichern der verbleibenden Daten zu haben. Meine MSSQL-Datenbank müsste dann Entitäten wie "Kontakt" mit einer bestimmten Organisationseinheit oder einem Benutzer verbinden, indem sie ihren eindeutigen Bezeichner oder wie sie auch genannt wird, verwendet.

Irgendwelche Gedanken dazu? Ist es sinnvoll, komplexe Typen in AD statt in einer MSSQL-Datenbank zu speichern?

(Die Einheiten sind höchstwahrscheinlich wenige genug Leistung kein Thema in jedem Fall zu machen)

Antwort

0

Was Sie beschreiben, kann sicher durchgeführt werden. Ich habe es gesehen. Sie werden wahrscheinlich feststellen, dass AD sehr schwer und über Bord für einen solchen Einsatz ist. Das Management und die langfristige Wartung werden sehr kostspielig sein. Ich würde es nicht empfehlen. Die Verwendung einer Datenbank ist wahrscheinlich die richtige Lösung für Sie.

Alternativ können Sie Active Directory Lightweight Directory Services (AD LDS, ehemals ADAM) verwenden, wenn Sie keine vorhandene Datenbank haben oder keine hinzufügen möchten. Dies wurde als ein leichteres Verzeichnis konzipiert und arbeitet in einem eigenen Schema, sodass Sie Ihre vorhandene AD-Infrastruktur nicht ändern müssen. Ich habe das in der Vergangenheit benutzt und es ist viel einfacher zu pflegen. Der andere Vorteil ist, dass es das gleiche Framework und SDK wie AD verwendet.

+0

Wie interessant! –

+0

Ich habe diese verwendet und empfehlen ADAM über Datenbank in diesem Szenario – Raymund

+0

Raymund, vorsichtig zu beschreiben, warum Sie ADAM über Datenbank empfehlen? Um ehrlich zu sein, fällt es mir etwas schwer zu sehen, warum ich Daten in ADAM speichern sollte, nur weil 2 von 20 Entitäten bereits in ADAM existieren. – John