Datenbankstruktur Aufbau

[RWarnecke]

Hallo zusammen,

im Moment habe ich einen Dienst, der ca. 200 - 300 Werte pro Tag zusammen stellt. In einem Single User Modus ist das kein Problem, da ich alles in eine Tabelle schreibe. Gehen wir nun davon aus, dass die 200 - 300 Werte pro Tag pro Benutzer erstellt werden. Wenn ich jetzt 100 Benutzer habe, kommen so pro Tag 20000 - 30000 Datensätze zusammen. In einer Woche wären es dann 140000 - 210000 Datensätze.

Keiner der Benutzer soll die Daten von einem anderen Benutzer einsehen können. Die zwei folgenden Überlegungen spiele ich gedanklich durch:

1. Alle Datensätze in einer Tabelle speichern mit einer zusätzlichen Spalte für die User-ID
2. Pro Benutzer eine eigene Tabelle anlegen und darin die erstellten Datensätze speichern.

Die folgenden Fragen habe ich:

1. Gibt es noch weitere Möglichkeiten?
2. Welche Der beiden Überlegungen bietet den besseren Datenschutz ?
3. Gibt es bei einer der Überlegungen Performance Probleme beim Suchen nach Datensätzen ?

Was könnt Ihr mir aus euren Erfahrungen heraus erzählen?

[Redeemer]

Für jeden Benutzer eine Tabelle anzulegen, würde man aus Gründen des Aufwands nicht machen. Vom Datenschutz her gewinnst du da nur, wenn du für jeden Benutzer einen eigenen Zugang anlegst, abhängig vom Benutzer den korrekten Zugang benutzt und die Rechte für die Tabelle setzt. Vielleicht sparst du ein paar Bytes pro Datensatz, wenn der Benutzer nicht mit jedem Datensatz gespeichert werden muss, sondern sich aus der Tabelle erschließt.

Bei einem guten Datenbanksystem (was ich MySQL/MariaDB allerdings abspreche) ist bei derart wenigen Datensätzen kein Performanceunterschied zu erwarten.

[IBExpert]

Zitat:

Zitat von RWarnecke (Beitrag 1500285)

Die folgenden Fragen habe ich:

1. Gibt es noch weitere Möglichkeiten?
2. Welche Der beiden Überlegungen bietet den besseren Datenschutz ?
3. 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 ;-)

[RWarnecke]

Hallo Holger,

danke für Deine Antwort. Hast Du vielleicht ein paar Links mit Anleitungen dazu, wie man den Aufbau in Firebird umsetzt ? Konnte bis jetzt nicht direkt dazu etwas finden.

[IBExpert]

IBExpert Stammtischvideo wo ich das erklär
Deutsche Doku für ibexpert zum view
Englische Doku für ibexpert zum view