State-Of-The-Art bei Datenbankzugriffen

[Samson_Miller]

Was ist für das folgende Szenario am sinnvollsten:

--
Ein Benutzer meldet sich mit Benutzername und Passwort an einer Web-Anwendung an. Danach werden Informationen aus der Datenbank ausgelesen und angezeigt.
--

Wie sollte die Verbindung zur Datenbank aufgebaut werden? Mit dem Benutzername und das Passwort, mit der der Benutzer sich schon an der Anwendung angemeldet hat, oder lieber mit einem technischen User, der für alle Benutzer der gleiche ist und sichtbar ist?

 

[bronks]

... mit einem technischen User, der für alle Benutzer der gleiche ist und sichtbar ist?

Bei Webapps mit einem technischen Benutzer, dessen Namen der Benutzer nie erfahren wird.

 

[byte]

Ich hoffe, die Frage ist nicht ernst gemeint... Du hast natürlich einen Zugang zur DB, der gänzlich unabhängig von den Usern Deiner Anwendung sind. Oder willst Du, dass sich ein User mit seinen Daten per DB-Client direkt mit Deiner DB connected und alle Daten manipuliert?

 

[maki]

Hatte mal ein "interessantes" Gespräch mit 'nem Oracle (oder war es ein SAG'ler? egal) Vertreter, der darauf beharrte pro User einem DB Account zu haben, der Lizenzen und seinem Bonus wegen... inkompetente Verkaufsschlampen...

 

[homer65]

Da kann man geteilter Ansicht sein. Beides hatt Vor- und Nachteile. Die Variante mit dem technischen User ist einfacher zu realisieren und erfordert weniger Verwaltungsaufwand. Man weiss dann allerdings nicht mehr welcher Benutzer welche Aktionen macht.

 

[Samson_Miller]

@homer65

genau das sind die beiden Aspekte die ich gegeneinander abwägen muss. Im Prinzip halte ich aber einen technischen User für sinnvoller.

 

[tfa]

Aber eine Webanwendung läuft doch auf einem Server. Eine Authentisierung bzw. Autorisierung ist Bestandteil oder ein Dienst der Serveranwendung. Warum sollen da DB-User ins Spiel gebracht werden?

 

[ARadauer]

fänd ich interessant, wenn die datenbank hinter diesem forum für jeden von uns einen eigenen db benutzer verwalten würde... sinnlos... der benutzer der datenbank ist die webanwendung.

 

[Zed]

Da kann man geteilter Ansicht sein. Beides hatt Vor- und Nachteile. Die Variante mit dem technischen User ist einfacher zu realisieren und erfordert weniger Verwaltungsaufwand. Man weiss dann allerdings nicht mehr welcher Benutzer welche Aktionen macht.

Verstehe ich nicht gnaz warum soll man das nicht nachvollziehen können. Datenbankzugriffe erfolgen über die Anwendung d.h. es gibt DAOs diese daos können doch jeden DB zugriff protokollieren. Zum identifizieren log man einfach den Benutzernamen mit.

Aber einen Sinn sehe ich bei einem z.B. Portal wo der User nur Daten abruft eher nicht.

 

[Guest]

Verstehe ich nicht gnaz warum soll man das nicht nachvollziehen können. Datenbankzugriffe erfolgen über die Anwendung d.h. es gibt DAOs diese daos können doch jeden DB zugriff protokollieren....

Je nach Datenbank/Betriebssystem kann ein technischer User statt vielen Db Usern ein Informationsverlust sein. Alleine beim DB-Monitoring kann es manchmal hilfreich sein, den User zu wissen, der z.B. viele langsame Statements erzeugt. Auch bei Transactionjournalauswertungen (z.B. auf DB2 auf IBM System i/z) ist so ein User manchmal praktisch. Klar kann man da vieles selber mitprotokollieren, aber manch einer ist noch von den nativen Programmupdates verwöhnt, bei welchen auf IBM Mainframes (DB2) nicht nur der User, sondern auch die Terminlsitzung und das Programm protokolliert wird - ohne dafür irgendetwas im Programmcode dafür tun zu müssen.

Wie auch immer, bei einer modernen Webapplikation ist das denkbar ungünstig - Stichwort: Connectionpool. Bei Webanwendungen gebe auch ich einem technischen User den Vorzug. Aber ich kann das "Nachweinen" zur Multiuserdatenbank durchaus verstehen.

/Robert

 

[didjitalist]

für web anwendungen sind wohl automatisch verwaltete connection pools state of the art, wie sie alle application server mitbringen. kommt aber immer auch auf die art der anwendung an. in systemen, die zugriff auf dieselbe datenbank mittels web anwendung, web services und fat clients anbieten, können DB user durchaus vorteilhaft sein. trigger, views und was nich alles, sind halt immer noch gängige mittel. und die sind nunmal am einfachsten zu realisieren, wenn man echte DB user hat.