Die folgenden Fragen habe ich:
- Gibt es noch weitere Möglichkeiten?
- Welche Der beiden Überlegungen bietet den besseren Datenschutz ?
- Gibt es bei einer der Überlegungen Performance Probleme beim Suchen nach Datensätzen ?
Was könnt Ihr mir aus euren Erfahrungen heraus erzählen?
Bei Firebird könnte man das relativ simpel und sicher über updatable views lösen, auf denen kannst du
select/insert/update/delete wie auf jeder Tabelle machen, die trigger packen schreibende Operationen
das dann in echte tabellen, beim select source des views hinterlegst du dann zB abhängig vom
current_user eine einschränkung auf die foreign key regel, was für wen sichtbar ist.
Am view bekommen die user dann rechte, die views selber bzw trigger da drauf haben die rechte an den
erforderlichen Tabellen, an denen dann aber die user keine rechte haben
großer vorteil: ein mal so umgesetzt brauchst du dir in keiner client app irgendwelche Gedanken
machen, was der User dann sieht und warum. Das regelwerk ist an einer Stelle in der
db
hinterlegt und kann jederzeit geändert werden.
Die Lösung mit eine Tabelle pro user würde ich niemals so machen, weil ich mit so einer
Konstruktion mal bei einem Kunden zu tun hatte, der Software für Speditionen
machte und dabei jede Preisliste variante in abhängigkeit von entfernung/gewicht/...
in eine eigene Tabelle gepackt hat. in einer Datenbank waren alleine dafür schon 2400
Tabellen enthalten, die teilweise aufgrund historischer gründe unterschiedliche
Metadaten hatten. Das war schon auf der Ebene ein unbenutzbares Monstrum ....
Ich weiss das postgres updatable views kann, wenn auch nicht annähernd mit den Möglichkeiten,
was da bei firebird/interbase seit 30 Jahren geht, aber ob
mysql das überhaupt kann, keine Ahnung
