Ein DB-Account für alle user?

hallo, ich hab da mal ne interessante frage zum datenbank-entwurf für bg's.
sollte man alle user über ein und denselben "general"-account auf die db zugreifen lassen oder soll jeder user seinen eigenen db-account bekommen mit speziellen views etc. ?
variante 1 ist natürlich einfacher umzusetzen, aber ich weiß nicht ob das später nicht eventuell probleme gibt...
ich bin am überlegen ob bauaufträge in eine gemeinsame tabelle (für alle user einsehbar) stehen oder ob jeder user seine eigene tabelle für bauaufträge haben soll...

Interessante Sichtweise
Finde ich aber trotzdem nicht sinnvoll.
Es macht mehr Sinn einen Account für alle Spieler zu haben bei welchem die Rechte gestutzt sind und einen für den Adminaccount.
Alternativ dazu kann man ja noch Accounts für Supporter etc. machen.

benutz lieber für alle user einen account
denn dann müsstest du ja für jeden user die nutzer der db auch neu eintragen
und bei 10.000 spielern hast du dann auch noch 10.000 db accounts
oder habe ich dich falsch verstanden?

ja hast du richtig verstanden, hab ich mir auch schon gedacht, dass das dann nicht so sinnvoll ist...
aber ich brauch dann wohl 2 accounts: also 1x admin und 1x general-account für alle spieler..

Also ich hab noch keine Webapplication, die mehr als einen DB User benutzt. Auch sicherheitstechnisch ist die nicht unbedingt erforderlich, weil niemand sich direkt an die DB hängt sondern immer nur über deine Webapp (PHP oder was halt sonst) darauf zugreifst und man die Zugriffsrechte da regeln kann.
Ich kenn das nur wenn die Benutzer direkt mit nem Client auf die DB zugreifen und hab festgestellt, dass es um einiges mehr Aufwand ist die rechte so einzurichten, dass die User nur dass bekommen können was sie sollen.

Bei uns sind sogar mehrere Accounts pro Applikation vorgeschrieben.
ReadOnly
Admin
Support
Und je nach Funktionsgruppierung auch noch Sonderaccounts.
Wir haben Datenbanken wo mehr als 50 Accounts drauf hängen. Teilweise sind die extrem restriktiv gehandhabt.
Das sind sowohl Accounts die direkt einen Datenbankzugriff haben, als auch Anwendungsaccounts für die verschiedenen Webanwendungen.
Hat sich bisher als sehr nützlich und sinnvoll gezeigt bei uns.

Original von Tesla2k
Also ich hab noch keine Webapplication, die mehr als einen DB User benutzt. Auch sicherheitstechnisch ist die nicht unbedingt erforderlich, weil niemand sich direkt an die DB hängt sondern immer nur über deine Webapp (PHP oder was halt sonst) darauf zugreifst und man die Zugriffsrechte da regeln kann.

Es geht doch darum im Falle einer Übernahme oder SQL-Injection den Schaden gering zu halten.
Wenn man dann aber jedem User noch eigene Tabellen verpasst, gibt es bei Listen (z.B. Highscores) aber leider eine Join-Katastrophe. Ich weiß leider nicht, wie man den Zugriff Zeilenweise erlauben kann. Das Stichwort "Views" ist gefallen und das werde ich mir noch mal ansehen...

ja ne, also wenn jeder user einen datenbank account (somit ein eigenes schema) hat würde jeder user auch eine view zb. auf die tabelle "gebaeude" bekommen welches im allgemeinen schema gespeichert ist. also alle allgemein einsehbaren sachen wären in diesem schema gespeichert...
nur hätte jeder user halt seine eigene tabelle "bauaufträge" (oder ähnliches) nur in seinem eigenen schema.
also eine "highscores"-tabelle wäre wohl im allgemeinen schema gespeichert, wo jeder user eine view drauf hat...

Ganz ehrlich?
Viel zu aufwändig... mit unterschiedlichen Zugängen, z.B. Nur lesend, Admin, etc pp, das macht schon Sinn, aber wirklich für jeden User eigene Tabellen anzulegen halte ich nicht unbedingt für sinnvoll. Die Datenbank wird ab einer gewissen Userzahl sehr unübersichtlich werden und es ergeben sich für mich keine erkennbaren Vorteile durch ein solches Verfahren.
Gruß,
Marc

Original von raufaser
Ganz ehrlich?
Viel zu aufwändig... mit unterschiedlichen Zugängen, z.B. Nur lesend, Admin, etc pp, das macht schon Sinn, aber wirklich für jeden User eigene Tabellen anzulegen halte ich nicht unbedingt für sinnvoll. Die Datenbank wird ab einer gewissen Userzahl sehr unübersichtlich werden und es ergeben sich für mich keine erkennbaren Vorteile durch ein solches Verfahren.
Gruß,
Marc

Tjo.. was soll ich sagen.. ich arbeite in einer Großbank... da ist das PFLICHT so zu arbeiten. Und wenn du mal ein bissle drüber nachdenkst, dann stimmst du mir zu das das so gut ist und einen Sinn hat

Bei euch in der Bank werdet ihr aber auch eine ganz andere Datentechnik als MySQL einsetzten. Bei der iSeries von IBM z. B. ist sowas auch ganz normal.

Original von progs
Bei euch in der Bank werdet ihr aber auch eine ganz andere Datentechnik als MySQL einsetzten. Bei der iSeries von IBM z. B. ist sowas auch ganz normal.

Wir dürften so ziemlich jeden Datenbanktyp im Einsatz haben. Nicht nur die großen wie DB2, Oracle, SQL-Server, MQSeries und wie sie sich alle nennen.
Ein Kollege hat zum Üben mal MySQL verwendet. Wir haben das dann aber wieder rausgeworfen.
Grund: Uns fehlte die Zeit / das Geld um alles zum Thema GPL zu prüfen. Von daher wird grundsätzlich NUR Kaufsoftware eingesetzt wenn es notwendig wird.
Das Risiko ist einfach zu groß.
Das beste Beispiel ist Joomla im Moment. Siehe heise.de

Tjo.. was soll ich sagen.. ich arbeite in einer Großbank... da ist das PFLICHT so zu arbeiten. Und wenn du mal ein bissle drüber nachdenkst, dann stimmst du mir zu das das so gut ist und einen Sinn hat

Ja im Kontext einer Großbank mag das Sinn machen.
Aber wir reden hier nicht über die Anwendungen einer Großbank, die auf einem Mainframe laufen, sondern über ein Browsergame.
Äpfel und Birnen und so...
Ich hab vor einiger Zeit ein Redaktionssystem programmiert, dass Mandantenfähig war und für jeden Mandanten eigene Tabellen angelegt hat, wobei einige Tabellen Zentraltabellen waren. Bei einer Installation waren es mal ca. 70 Mandanten und aus dieser Erfahrung heraus sage ich, dass es unübersichtlich wird, schwierig zu debuggen, blablabla... jedenfalls würde ich es heute nicht mehr so machen.
Ich sage nicht, dass es keine Vorteile hat, natürlich hat es Vorteile das liegt ja auf der Hand, aber es gibt eben auch Nachteile und die gilt es nun gegeneinander abzuwägen, und dann sollte jeder selbst entscheiden was er macht...
Gruß,
Marc

Dann sind wir uns ja einige. Ich wollte nur die Aussage grade rücken, daß es keinen Sinn macht sowas zu machen.

Original von MrMarco
Dann sind wir uns ja einige. Ich wollte nur die Aussage grade rücken, daß es keinen Sinn macht sowas zu machen.

Naja das war etwas ungeschickt und nicht umfassend genug ausgedrückt von mir. Sorry.
Gruß,
Marc

Original von progs
Bei der iSeries von IBM z. B. ist sowas auch ganz normal.

Was? Die iSeries ist ne Hardwaretechnologie...
Hat erstmal fuer sich alleine nichts mit Datenbankensoftware zu tun. Darauf kannst du auch mySQL einsetzen :p
Wobei in der Preisklasse natuerlich ne Vektordatenbank geschickter waere (je nach Anwendungsfall eben). Aber wie auch immer...
Datenbankzugriff vergibt man immer nach Anwendungsfaellen: jeder User darf nur so viele Rechte haben wie er benoetigt. Globale Dinge fallen immer komplett weg. Notfallaccounts wie Admin, sperrt man normal immer bis zur Verwendung. Anwendungen machen normal so ne Art "Portknocking" im Uebertragenen Sinne bei Datenbanken. Auf die richtige Sequenz wird dann der Admin Account freigegeben.
Benoetigt man den Admin-Account oefters, sollte man sich ne andere Sicherung einfallen lassen. Minimum ist: kein Netzwekzugriff per Admin-Account. MySQL hat uebrigens ne SSL Funktion, die sollte immer aktiv sein.