Ich würde das auch so machen (GRANT / REVOKE) nutzen
- Ja
- Nein
- Weiss Nicht (girls only)
0 Teilnehmer
Nehmen wir mal an ich will eine klassische C/S-Architektur bauen … mit - wie man heute so schön sagt - einem Rich-Client und eben einer DB als Backend. (früher nannten wir sowas lapidares auch einen Monolithen - C/S fing da an wo man auch was mit Application-Server drauf schreiben konnte)
Für Nutzer-Verw. und Anmeldung sehen die häufigsten 0815 Lösungen ja so aus, dass man dem Client irgendwo ein mehr oder minder einheitliches Login bereit hält, mit dem sicher Client an der DB anmeldet. Notwendigerweise darf jeder Client auf der DB das gleiche. Der Nutzer authentifiziert sich dann über irgendeine selbstgestrickte Nutzer-Anmeldung die gegen irgendeine selbstgestrickte Nutzer-Tabelle evaluiert.
Ich habe mir nun überlegt, dass man die vorgehaltenen Login-Daten am Client (registry / cfg-file / ect) vermeiden kann, wenn die Nutzer-Verwaltung der Anwendung auch GRANT und REVOKE verwendet und fuer den Nutzer der Anwendung auch ein DB-Nutzer zu erzeugen - mit dem selben pwd usw.
Im Moment sammle ich noch Informationen, um abschätzen zu können, was ich mir für Probleme einhandle, wenn ich so arbeite. Immerhin würden die erzeugten Objekte in der DB dem Nutzer gehören usw.
Irgendwelche Gedanken / Ideen / Zweifel? Ja - Diesmal dürfens auch gern Zweifel sein 