Verständnisfrage zur DB-Erstellung

Diskussionen zur Bedienung von KeyHelp.
User avatar
24unix
Posts: 1650
Joined: Sun 21. Jun 2020, 17:16
Location: Kollmar
Contact:

Re: Verständnisfrage zur DB-Erstellung

Post by 24unix »

Alexander wrote: Mon 14. Aug 2023, 10:49 Habe es nie benutzt etc. würde bei der Größe/Bekanntheit der Anwendung aber davon ausgehen, dass sie gute Gründe für die Entscheidung '3 Datenbanken zu nutzen' haben.
Ich würde sagen, es ist schlicht Bequemlichkeit (ein ähnliches Wort habe ich mir mal erspart :-) )
Separation of Concerns lässt sich problemlos in einer DB regeln, mit unterschiedlichen Benutzern.
Kostet halt etwas mehr Aufwand und Planung. Aber in Zeiten, wo DB Instanzen nichts mehr kosten ist das egal.

Ich hätte Ende der 90er ganz schön einen auf den Deckel bekommen, wenn ich ohne wirklich validen Grund 3 Oracle Instanzen statt einer hätte budgetieren lassen wollen,
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
CaseF
Posts: 12
Joined: Fri 12. Jan 2018, 02:04

Re: Verständnisfrage zur DB-Erstellung

Post by CaseF »

Alexander wrote: Mon 14. Aug 2023, 09:53
technotravel wrote: Fri 11. Aug 2023, 11:24 Warum sollte derselbe Benutzer nicht mehrere DB mit unterschiedlichen Namen erstellen können?

Gibt es eine Möglichkeit, diese Einschränkung auszuschalten?

Ich hab das Thema in der Theorie über die Jahre hinweg immer mal wieder im Kopf durchgespielt. Ich bin jedes mal zu dem Schluss gekommen, das es den Aufwand nicht wert ist. Ich rede jetzt nicht vom Aufwand bei mir, der wäre egal. Ich meine den Aufwand der Kunden, die die UI nutzen müssen.

Aktuell ist alles sehr straight forward, man hat eine Übersichtsseite, ein paar Eingabefelder fertig. Wenn man ein System mit Nutzern + beliebig vielen Datenbanken einführt, würde es die UI entsprechend aufblähen. Das wäre prinzipiell verschmerzbar, aber, wieviele Leute würden so ein Feature unbedingt brauchen?
Am Ende wird es für 95% der Nutzer verkompliziert und für 5% stellt es eine Erleichterung dar. Da tendiere ich dann (Stand jetzt) doch eher dazu, das 5% in den sauren Apfel beißen müssen und einfach einen 2. Datenbankbenutzer + Datenbank anlegen, als das ich 95% mit der UI "nerve" :).

Stand jetzt würde ich es eher nicht umsetzen wollen, das kann sich im Laufe der Zeit natürlich ändern.

---

Oder hast du ein bestimmtes Szenario im Kopf, bei dem du so ein Feature brauchen würdest, was aber durch die aktuelle Umsetzung dich vor Probleme stellt? Gern einmal beschreiben, damit ich den use case verstehe.
Wie würde es sich denn verhalten, wenn man die Möglichkeit eines (Accountweiten) DBA implementiert. Diese Funktion könnte man dann für Kundenaccounts Aktivieren bzw. Deaktivieren. Somit hätte man wie bisher auch immer pro Datenbank einen User, aber eben auch einen weiteren User der Zugriff auf alle DBs des Kundenaccounts hat.

Wäre halt in puncto Sicherheit nicht so geil, wenn dieser DBA dann in irgendwelchen config files landen würde, aber zumindest würde man dem Kunden die Möglichkeit geben, seine Datenbanken auch in irgendeiner Form übergeordnet zu administrieren.
Post Reply