Datenbankstruktur für Zugriffsrechte
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
antwort
anzahl
benutzer
container
datenbank
datum
frage
information
million
performance
problem
redundante informationen
speichern
stehen
struktur
tabelle
unfall
versicherung
verstehen
zugriff
-
Hallo Leute!
Ich wollte hier mal allgemein die Struktur einer Datenbank für meine Problemstellung diskutieren:
Ich hab folgende Problemstellung:
* Es gibt verschiedene Benutzer
* Es gibt verschiedene Container
* Benutzer haben Zugriffsrechte für einzelne Container
Nun stellt sich mir die Frage was hierbei die effizientese Lösung ist:
Variante A:
* Eine User-Tabelle mit allen Usern und dessen Daten (UserID, Name, Vorname, ...)
* Eine Container-Tabelle mit allen Containern und dessen Daten (ContainerID, Größe, Erstellungsdatum)
* Eine Access-Tabelle in denen die Zugriffsberechtigungen geregelt werden (AccesID, UserID, ContainerID)
Variante B:
* User-Tabelle wie in Variante A
* Container-Tabelle wie in Variante A
* Eine Tabelle pro Container, welche jeweils die UserIDs speichert, welche zu diesem Container Zugriff haben
Variante C:
* User-Tabelle wie in Variante A
* Container-Tabelle wie in Variante A
* Eine Tabelle pro User, welche jeweils die ContainerIDs speichert, auf die der User Zugriff hat
Im Hinterkopf nun die Vorgehensweise, dass ein User sich einloggt und ihm dann nur die Container angezeigt werden, zu denen er Zugriff hat. Die Container Anzahl ist dynamisch und wird mit dem Alter der Seite wachsen, ebenso die Benutzer Anzahl.
Funktionieren würden sicherlich alle drei Varianten, aber welche ist eurer Meinung nach die effizienteste!?
Beitrag zuletzt geändert: 29.10.2010 14:31:39 von beachteam -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Zunächst musst du die Begriffe "Datenbank" und "Tabelle" unterscheiden können. Kannst du das und hast du deinen Eröffnungsbeitrag entsprechend verändert (ersetze "Datenbank" durch "Tabelle" oder meinetwegen auch durch "Datenbanktabelle"), empfiehlt sich Variante A. Alles andere ist Pfusch.
-
Hm ja natürlich spreche ich von Tabellen, sorry, is abgeändert.
Das Problem ist halt, dass dieses Access-Tabelle ja dann mit der Zeit ziemlich ausatet und es mit den getrennten Tabellen strukturierter wäre, aber rein logisch würde ich auch Variante A bevorzugen
Beitrag zuletzt geändert: 29.10.2010 14:34:17 von beachteam -
Unbedingt Variante A. "Eine Tabelle pro XXX" ist immer ein Anzeichen für schlechtes Design.
-
Beachteam, hast du vielleicht schoneinmal daran gedacht, dass Datenbanken für genau so etwas konstruiert sind? Hast du schoneinmal daran gedacht, dass ein einer Tabelle mehr als 2 Informationen stehen können? Wenn du ein Tabelle auf einem Blatt Papier anfertigst, hat diese wesentlich mehr Zeilen. Beispielsweise muss eine Versicherung viele Daten über sehr viele Personen speichern. Hat der Versicherungsnehmer sein Fahrzeug versichert und einen Unfall gehabt, muss in einer anderen Tabelle stehen, dass es diesen gab, wie hoch der Schaden ist, usw. Das kommt alles nicht in die Kundentabelle. Und denkst du etwa, dass eine Versicherung wegen jedem Unfall, der auf der Welt passiert, eine extra Tabelle, oder wie du es zuerst hattest, eine extra Datenbank anlegt?
-
Zunächst mal war das mit Tabelle/Datenbank einfach nur ein Versprecher (oder Verschreiber, wie man es auch nimmt), natürlich lege ich nicht für jede Tabelle eine eigene Datenbank an... Auch wenn ich kein Datenbankexperte bin erschließt sich mir diese Tatsache natürlich rein logisch und intuitiv, keine meiner Datenbanken für verschiedene Projekte sieht daher so aus, sondern haben eine klar Ordnung und Struktur mit durchdachten Tabellen.
Ich habe auch ein weiteres Projekt in dem ich es intuitiv nach Variante A gemacht habe, allerdings denke ich, dass man die Struktur natürlich auch immer etwas an die Problemstellung anpassen muss.
Na klar, wenn ich eine riesige Versicherung vertrete erstelle ich nicht für jeden Kunden / Unfall eine eigene Tabelle, das ist auch intuitiv klar. Trotz allem denke ich kaum, dass die Versicherung eine einzige Tabelle benutzt nach dem Motto:
Unfall_ID, Kunden_ID, Datum, Schadenshöhe, ...
Zwar eine Möglichkeit, aber dennoch glaube ich nicht, dass eine solche Tabelle mit wahrscheinlich mindestens 100 Millionen Einträgen pro Jahr die beste Performance bietet.
Deshalb bitte ich zunächst mal darum, die Antwort vielleicht nicht ganz so abfällig zu gestalten. Ich habe eine konstruktive, ehrliche Frage gestellt, die sich natürlich auf MEINE (kleine) Problemstellung bezog, und nicht auf die eines Unternehmens mit unzähligen Datenbankzugriffen pro Sekunde, sodass ich doch auch eine konstruktive, ehrliche Antwort erhalten kann, die mir keine Fakten darstellt, welche sich mir mit einem IQ eines Toasters bereits selbst erschließen. Tut mir Leid wenn ich hier nun auch etwas aggressiver klinge, aber die Antwort kam doch etwas herablassend rüber...
Zurück zum Thema...
Die Frage dabei ist einfach die Last der Tabellen zu verteilen. In wiefern hilft es der Performance 2 Tabellen mit jeweils 10 Einträgen zu haben und eine mit 1000 Einträgen. Natürlich sollte man redundante Informationen vermeiden und so zB in der Access-Tabelle keine Userdaten speichern, sondern lediglich die UserID, welche dann über die User-Tabelle weitere Informationen liefert.
Allerdings denke ich doch, dass Variante A hier nur eines von möglichen, und auch sinnvollen, Modellen darstellt, deshalb wollte ich diese Diskussion hier mal anregen.
Beitrag zuletzt geändert: 29.10.2010 17:06:43 von beachteam -
Ein Fehler den gerade Anfänger im Bezug auf Datenbanken gerne machen, ist zu denken, dass sie langsam sind.
Was man daher zuerst verstehen muss ist: Datenbankensysteme sind schnell! Es ist absolut kein Problem für eine Datenbank mit Tabellen von mehreren hundert Millionen Einträgen zu arbeiten.
Anschließend muss man verstehen, dass wenn Abfragen an eine Tabelle langsam sind, das nicht daran liegt, dass die Tabelle zu groß ist, sondern daran, dass sie falsch indiziert ist oder man einen ineffektiven SQL-Query nutzt.
Daraus lass uns folgern, dass Indizierung die Lösung für all deine Probleme ist!
PS: Abgesehen davon, mit wie großen Daten wirst du arbeiten? Sagen wir mal 1000 User und 10000 Container. Sagen wir jeder User hat Zugriff auf 3000 Container. Das sind 1000 * 3000 = 3 Mio Datensätze. Und 3 Mio. Datensätze sind wirklich nichts, was man als groß bezeichnen würde ;)
Beitrag zuletzt geändert: 29.10.2010 18:51:57 von nikic -
Ok, dann werde ich mich an Variante A halten. Das mit der Indizierung hatte ich auch schon verstanden, damit man ja keine Redundante Informationen speichert, sondern diese in verschiedene Tabellen auslagert. Habe eben keine Erfahrung mit so großen Datenbanken, hätte da doch angenommen, dass es irgendwann zu Performance Problemen kommen könnte.
Dann danke für die hilfreichen antworten! -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
