MYSQL Tabellen dynamisch anlegen - Sicherheitsproblem?

[emtrion]

Hallo zusammen,

ich code im Moment ein kleines CMS System, das einige Sonderfunktionen hat, die von den verfügabren CMS Systemen nicht unterstützt werden.

Dazu habe ich von unserem IT-Administrator einen Server und eine MYSQL Datenbank zur Verfügung gestellt bekommen. Für die Datenbank habe ich zwei Benutzeraccounts. Einen mit Administrationsrechten und einen mit weniger Rechten, der dann später von der Webseite benutzt werden soll.
Jetzt kann dieser Nutzer mit weniger Rechten aber keinen Tabellen anlegen (create table). In meinem Konzept ist das aber so vorgesehen, dass Tabellen dynamisch angelegt und auch wieder gelöscht werden.

Wie löst ihr so etwas mit Blick auf die Sicherheit? Legt ihr Tabellen überhaupt dynamisch an oder "tut man das nicht"? Welche Rechte hat der Nutzer mit dem ihr auch auf der Datenbank einloggt?
Gibt es spezielle Dinge die ich beachten sollte wenn ich trotzdem Tabellen dynamisch anlege (mal abgesehen von "mysql_real_escape_string()")?

Grüße,
Stephan

[Duddle]

In meinem Konzept ist das aber so vorgesehen, dass Tabellen dynamisch angelegt und auch wieder gelöscht werden

Könntest du einen Anwendungsfall beispielhaft illustrieren, bei dem das tatsächlich notwendig ist?

Ich könnte mir jetzt spontan PlugIns mit eigenen Tabellen vorstellen, aber die würden dann ja auch von einem Administrator installiert und könnten mit einem anderen DB-Account angelegt werden.



Duddle

[Feedback]

Die Struktur einer Datenbank sollte sich so wenig wie möglich ändern. Soll heißen, Tabellen anlegen, ändern und entfernen sollte nur dann passieren, wenn Programmteile hinzugefügt oder entfernt werden (wie oben gesagt, zB neues Plugin). Zur Laufzeit irgendwelche Tabellen erzeugen und entfernen ist nicht wirklich guter Stil.

Wenn du das also ständig während der Laufzeit tun willst, dann würd ich an deiner Stelle vielleicht das Datenbank-Design nochmal überdenken.

Beim normalen Betrieb (also nicht Admin-Modus) mit einem Benutzer auf der Datenbank arbeiten der CREATE, ALTER und DROP Rechte besitzt ist auch ein nicht zu unterschätzendes Risiko.

[emtrion]

Der aktuelle Anwendungsfall sieht wie folgt aus:

Ich habe mehrere Produkte die eine Vielzahl von Funktionen haben können. Da können dann pro Produkt ca. 200 Einträge entstehen. Deshalb wollte ich aus Gründen der Performance eine große Tabelle für alle Produkte vermeiden. Sonst wären das bei 20 Produkten gleich mal 4000 Einträge in der Tabelle.
Gleichzeitig wird bei jeder Änderung der Produkteigenschaften die Historie gespeichert. Es enstehen also noch mehr Einträge.
Deshalb war meine Idee, dass ich bei dem Erstellen eines neuen Produkts einfach eine neue Tabelle anlege in der nur die Einträge für dieses Produkt hinterlegt sind.

[Feedback]

Solange der Datenbank-Server auf einem ordentlichen Server installiert ist und nicht auf einem Office-PC ist eine Datenbank selbst mit mehreren Millionen Einträgen pro Tabelle noch performant. Also die 4000 Einträge sind für ne Datenbank eher Peanuts, da würd ich mir keine Gedanken machen.

In diesem Falle: Lieber eine große Tabelle anstatt vieler kleiner.

[Duddle]

4000 Einträge sind garnichts. Mach dir erst Sorgen bei 4 Millionen.


Duddle

[emtrion]

Ok, dann werd ich das mal so versuchen!

[Monk2006]

Zitat von emtrion

Ich habe mehrere Produkte die eine Vielzahl von Funktionen haben können. Da können dann pro Produkt ca. 200 Einträge entstehen. Deshalb wollte ich aus Gründen der Performance eine große Tabelle für alle Produkte vermeiden. Sonst wären das bei 20 Produkten gleich mal 4000 Einträge in der Tabelle.
Gleichzeitig wird bei jeder Änderung der Produkteigenschaften die Historie gespeichert. Es enstehen also noch mehr Einträge.
Deshalb war meine Idee, dass ich bei dem Erstellen eines neuen Produkts einfach eine neue Tabelle anlege in der nur die Einträge für dieses Produkt hinterlegt sind.

Ich würde eine Produkt-Tabelle anlegen mit den generellen Eigenschaften, die sich wahrscheinlich nicht so häufig ändern werden, denn eine verknüpfte Tabelle über eine ProduktID, die die einzelnen Funktionen aufnimmt.

Für beide Tabellen, dann eine identische Tabelle mit gleichen Feldern UND zusätzlich Timestamp und Art des Eintrages (angelegt, geändert, gelöscht...).

Die beiden Haupttabellen enthalten also die aktuell gültigen Infos, und die beiden History Tabellen protokollieren nur die Veränderungen an den Haupttabellen.

Aber da diese Infos ja nicht so permanent abgerufen werden dürften, wie bei der Arbeit mit den aktuellen Produktinfos, macht das wirklich nicht viel aus.

Weiter würde ich aber mit der Normalisierung nicht gehen.

Und wegen ein paar Tausend Datensätzen würde ich mir keinen Kopf machen wegen Performance ... frage, doch mal, wieviel Millionen Datensätze hier für diese Site laufend von Tausenden gleichzeitig abgerufen werden ^^

MySQL ist ja extra für große Datenmengen und schnelle Verarbeitung ausgelegt - nicht umsonst es es eine der verbreitesten DB Systeme im Internet.

LG Moni

[exo]

Hmm ich würd vielleicht doch noch auf 3 tabellen gehen...habe auch schon viel mit shopsystemen zu tun gehabt und als eine gute lösung wäre doch folgender Ansatz:

1. Tabelle: Produkte mit generellen Eigenschaften wie name etc.
2. Tabelle: Eigenschaften_von_Produkten: wie gewicht, größe etc.
3. Tabelle: Produk_eigenschaft_wert: Hier wird der eigentliche wert gespeichert und die Produkt-ID mit der Eigenschafts-ID verknüpft.

Damit solltest du eigentlich relativ wenig overhead produzieren.

Selbst wenn man hier schon von millionen einträgen spricht, solltest du dennoch versuchen so sparsam wie möglich mit den daten umzugehen, da du irgendwann auch einmal an einem Punkt kommst wo du dir dann denkst, mensch, hättest dir damals einfach die arbeit gemacht, dann wärs jetzt einfacher

Also würden die 3 Tabellen so ausschauen:

Produkt
ID | Name | Preis

produkt_eigenschaften
ID | Name

eigenschaften_werte
ID | produkt_id | eigenschaft_id | wert

für die History könntest du dann zwei tabellen machen, eine, wo du die ganzen Aktionen vordefinierst und eine für die entsprechende Art der Aktion

History_aktionen
ID | Aktion

History_entrys
ID | aktion_id | parent_id | date |.... usw usw usw

Anhand der Aktion kannst du ja später im Script entscheiden, wo die Aktion durchgeführt wurde (bei produkt oder sonst wo) und die parent_id zielt dann zb auf das jeweilige element welches geändert wurde.
Also wenn die Aktion_ID als Name "Produktname geändert" hat, dann würde nachher in deinem Script die parent_id gleich der Produkt-ID entsprechen, welche geändert wurde.

Ach und wenn du Zeitstempel speichern willst, würde ich dir der Einfachkeit halber empfehlen, diese als DATETIME zu speichern, aus erfahrung kann ich dir sagen, dass du dir viel arbeit sparst beim thema Datumsfunktionen usw usw ...

[Wellenbrecher1963]

du kannst auch Tabellen anlegen, die Daten temporär rein schreiben und nach der Nutzung, wenn sie nicht gebraucht werden wieder entfernt werden können, ohne die Stammdaten anzufassen.

Ich hatte mal eine Art Einkaufspassage gebaut. Da musste eine Haupttabelle mit Artikeln existieren. Nun konnte sich ein Shopbetreiber in die "Ladenkette" einmieten und einen eigenen Shop aufbauen mit Produkten aus der Haupttabelle, die er haben wollte. Wenn er nur Weine brauchte, weil er einen Weinshop hatte, wurden in die spezielle Tabelle nur die ID der Artikel von der Haupttabelle eingetragen. Beim Anzeigen der Datensätze habe ich dann nur diese ID genommen und die restlichen Daten aus der Haupttabelle genommen und angezeigt.

Somit blieben die Daten des Stammes unangetastet und nur die Tabelle zu den jeweiligen Shops änderten sich.

Später konnten die Shopbetreiber auch eigene Produkte anbieten, die auch andere Shopbetreiber anbieten durften, also sowas wie B2B Produkte für Reseller. Diese habe ich dann auch wieder in eine separate große Haupttabelle untergebracht. Diese konnte dann auch ausgelesen werden und füllten (nur die ID und spezieller Zusatzvermerk) die speziellen Tabellen der Shopinhaber, wenn die das wollten.

Jeder hatte ein BackOffice, in dem die Produkte angezeigt wurden, die er auswählen durfte.
Und ich hatte auch noch die Möglichkeit, den einzelnen Shopinhabern einzelne Produkte vorzuenthalten, da zum Beispiel einige Marken nicht zusammen im Shop verkauft werden durften. Das passiert bei Nahrungsergänzungsangeboten sehr oft.

Naja, vielleicht hilft Dir das als Gedankliche Stütze.
v.G. Sylvio

[emtrion]

Vielen Dank für die vielen ausführlichen Antworten!

Mein erstes Konzept bestand ziemlich genau aus einer Mischung allen eurer Vorschläge, nur dass ich immer wieder neue Tabellen für einzelne Produkte angelegt hatte.
Ich habe jetzt einfach alle dynamischen angelegten Tabellen für die Produkteigenschaften weggelassen und eine große angelegt die dann zusätzlich noch die Produkt-ID aus der Haupttabelle enthält.Gleiches gilt für die Historie.

Da alles schon etwas fortgeschritten war, konnte ich nicht mehr das ganze Konzept über den Haufen werfen, aber diese Änderungen waren schnell gemacht! Danke für die Denkanstöße!

Grüße,
Stephan