200 Inserts in Datenbank - Performance?
0 
Felix Riesterer
0
200 Inserts in Datenbank - Performance?
Hallo zusammen,
bin gerade an einem Adminbereich für einen Onlineshop.
Es geht darum das bestimmte Personen nur die Daten von Kunden bestimmter PLZ-Gebiete ansehen dürfen. Das ganze läuft nach zweistelligen PLZ, also von 01 - 99. Das gleiche dann z.Zt. noch mit Österreich. Also sind es schonmal 200 Einträge. Weitere Länder sollen folgen.
Bis jetzt habe ich es so gehabt, das pro Recht ein neuer Eintrag in die Tabelle rechte geschrieben wird.
Allerdings wären es ja dann ggf. 200 Insert-Befehle. Wie sieht es da mit der Performance aus, bzw. kann man das ganze anders lösen?
Wäre für jeden Tipp dankbar
Gruß
GermanysNextTopfmodel
-
Liebes GermanysNextTopfmodel,
bestimmte Personen nur die Daten von Kunden bestimmter PLZ-Gebiete ansehen dürfen.
so gehabt, das pro Recht ein neuer Eintrag in die Tabelle rechte geschrieben wird.??? Wieso das denn? Warum wird nicht einfach abgefragt, welche Kunden für eine Person in Frage kommen, wenn für diese Person ermittelt werden soll, wen sie bearbeiten darf? Dazu würde ein Eintrag in der DB reichen, nämlich welchen PLZ-Bereich diese Person bearbeitet.
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Hello,
??? Wieso das denn? Warum wird nicht einfach abgefragt, welche Kunden für eine Person in Frage kommen, wenn für diese Person ermittelt werden soll, wen sie bearbeiten darf? Dazu würde ein Eintrag in der DB reichen, nämlich welchen PLZ-Bereich diese Person bearbeitet.
Unser Topfmodel schrieb "bestimmte Personen". Das können also mehrere sein, die auf einen Datensatz Zugriffsrechte haben. Und das Schlimme ist dann sogar noch, dass Topfmodel auch noch mindestens unterscheiden muss zwischen:
- nur verdeckte Abfrage (z.B. um Doubletten zu vermeiden)
- sehen
- hinzufügen
- ändern
- löschen
Diese Eigenschaften können aber trotzdem in einem Datensatz stehen.
Liebe Grüße aus Syburg
Tom vom Berg
-
- nur verdeckte Abfrage (z.B. um Doubletten zu vermeiden)
- sehen
- hinzufügen
- ändern
- löschen
Das brauche ich in meiner Struktur denke ich nicht beachten, da diese Bereiche nochmals gesondert sind, so das die jenigen, die es nicht dürfen, gar nicht erst einen Zugriff auf den jeweiligen Bereich(z.B. einfügen) bekommen.
Die Datenbak ist nachher für Callcentermitarbeiter gedacht, die zur Kundenaquise nur auf die jeweiligen Gebiete zugreifen dürfen, Änderungen an Adressen durchführen dürfen, und zu den Telefonaten Memos speichern dürfen.
Gruß,
GermanysNextTopfmodel-
Hello,
Das brauche ich in meiner Struktur denke ich nicht beachten, da diese Bereiche nochmals gesondert sind, so das die jenigen, die es nicht dürfen, gar nicht erst einen Zugriff auf den jeweiligen Bereich(z.B. einfügen) bekommen.
Die Datenbak ist nachher für Callcentermitarbeiter gedacht, die zur Kundenaquise nur auf die jeweiligen Gebiete zugreifen dürfen, Änderungen an Adressen durchführen dürfen, und zu den Telefonaten Memos speichern dürfen.
Ich habe da nur die leidvolle Erfahrung gemacht, dass es sich meistens rächt, wenn man nur halbe Sachen baut. "Das brauche ich jetzt nicht" ist kein Grund, eine technische Umsetzung in zwei Drittel aufzuteilen und das dritte Drittel unter den tisch fallen zu lassen.
Halte das Rechtesystem zusammen, indem Du alles an einer Stelle festlegst. Dann ist es im Moment vielleicht noch leicht überskaliert, aber das wird sich schnell ändern.
Liebe Grüße aus Syburg
Tom vom Berg
-
»» Halte das Rechtesystem zusammen, indem Du alles an einer Stelle festlegst. Dann ist es im Moment vielleicht noch leicht überskaliert, aber das wird sich schnell ändern.
Okay, das sehe ich ein. (wobei das Rechtesystem wesentlich größer ist, hier beziehe ich mich nur auf die plz).
Das mit den 200 Feldern in der Tabelle war ja nur gefragt, da ich die Antwort von Felix Riesterer nicht ganz verstanden hatte, bzw. so interpretiert hatte.
was mir jetzt noch eingefallen ist, wie schon geschrieben, gibt es ja nicht nur die PLZ-Berechtigungen, sondern auch andere(einsicht in Fakturierung, Aufträge erstellen usw.) Hatte eigentlich vor, kennzahl dafür zu erstellen, und eine komplette Tabelle für Rechte zu erstellen.
So wie ich es jetzt aber sehe, wäre es wohl sinnvoller beide Rechte (PLZ & allgemein) in zwei Tabellen zu packen, oder?Danke für Eure Hilfe
GermanysNextTopfmodel-
Hello,
was mir jetzt noch eingefallen ist, wie schon geschrieben, gibt es ja nicht nur die PLZ-Berechtigungen, sondern auch andere(einsicht in Fakturierung, Aufträge erstellen usw.) Hatte eigentlich vor, kennzahl dafür zu erstellen, und eine komplette Tabelle für Rechte zu erstellen.
So wie ich es jetzt aber sehe, wäre es wohl sinnvoller beide Rechte (PLZ & allgemein) in zwei Tabellen zu packen, oder?Erst einmal solltest Du überlegen, ob es sich um horizontale oder vertikale Rechte handelt. Bei den horizontalen können Dich die meisten Datenbanksysteme schon unterstützen.
Wenn Du nun in einem Script, mit dessen Hilfe der Client per HTTPs auf die Datenbank zugreifen darf, erst auf den tatsächlicne Benutzer umschaltest, dann hast Du hier schon mal eine Zusammenfassung geschafft. Hausintern könnte es ja auch möglich sein, dass ein User mittels anderer Clients auf das DBMS zugreift. Dann wäre es doch dumm, da wieder eine zusätzliche Rechtestruktur zu haben.
Und spätestens hier wird auch erkennbar, dass Dir für die vertikalen Rechte, oder eigentlich Einschränkungen der Rechte, Stored Procedures weiterhelfen können. Gestatte den Zugriff ausschließlich über diese Gates und verbiete direkten Zugriff auf Tabellen, dann sind beide Fälle erschlagen, per HTTPs und per Datenbankclient.
Informiere Dich also erst, welches Rechtesystem Dein DBMS bereits zur Verfügung stellt. Vermutlich musst Du nur die vertikalen Komponenten zusätzlich schaffen, die horizontalen werden schon vorhanden sein.
Liebe Grüße aus Syburg
Tom vom Berg
-
-
-
Hi,
Danke erstmal.??? Wieso das denn? Warum wird nicht einfach abgefragt, welche Kunden für eine Person in Frage kommen, wenn für diese Person ermittelt werden soll, wen sie bearbeiten darf?
So hatte ich mir das doch auch gedacht.(oder ich vertshe gerade nicht was Du meinst)
»»Dazu würde ein Eintrag in der DB reichen, nämlich welchen PLZ-Bereich diese Person bearbeitet.
Dann bräuchte ich doch aber eine Tabelle mit 200 Feldern, da es ja sein kann das eine Person alle 200 PLZ-Gebiete bearbeiten darf, ander jedoch nur ein Gebiet, oder 10 oder so.GermanysNextTopfmodel
-
Hello,
»»Dazu würde ein Eintrag in der DB reichen, nämlich welchen PLZ-Bereich diese Person bearbeitet.
Dann bräuchte ich doch aber eine Tabelle mit 200 Feldern, da es ja sein kann das eine Person alle 200 PLZ-Gebiete bearbeiten darf, ander jedoch nur ein Gebiet, oder 10 oder so.Nein, dann bräuchtest Du für diese Person 200 Datensätze in der n:m Tabelle
Oder Du gehst eben das mehrstufige Konzept durch, bei dem es auch Gruppen und Trustees gibt.Liebe Grüße aus Syburg
Tom vom Berg
-
-
-
Hello,
Stichworte: Gruppenzugehörigkeit, Einzelrechte, Vererbung, Vererbungssperre, Order Deny Allow, usw.
Das sind die Prinzipien von NDS und Active Directory.Das bedeutet also, dass Du hier eine n:m Beziehung aufgebaut hast?
Das wäre dann mMn der richtige Weg.Es würde sich außerdem anbieten, für den Zugriffe auf die Tabellen stored Procedures festzulegen, und nur noch über diese diese eingeschjränkten Zugriffe abzuwickeln. Dann kann es Dir nicht aus Versehen passieren, dass doch mal jemand die vollständige Tabelle zu sehen bekommt.
Liebe Grüße aus Syburg
Tom vom Berg