50 Datensätze gleichzeitig speichern

[radarin]

Guten Morgen zusammen

Da ich mein Glossar selber auf unterschiedlichen Domains einsetzen und es auch Anderen zur Verfügung stellen will, habe ich gut 50 Parameter, welche ich ebenfalls in der Datenbank speichern will. Das sind vor allem die Texte für Überschriften, Feldbeschriftungen sowie verschiedene URLs.

Einfach wäre natürlich eine Tabelle mit 50 Spalten und einer Zeile, die könnte ich mit einem einfachen UPDATE speichern. Ich habe mir aber überlegt, wenn pro einstellung noch ein oder zwei weitere Parameter dazu kommen, hätte ich dann 150 Spalten. Das Formular sehr umfangreich.

Ein anderer Lösungsansatz, 1-3 Spalten und 50 Zeilen. Innerhalb vom FORM die Felder 1x in einem WHILE schreiben. Da ich vorgesehen habe, nebst der DSID jedem DS eine fixe vorgegebene REF zu geben, wäre meine spontane Überlegung, entsprechend 50 UPDATEs hintereinander zu setzen, welche die DS einzeln speichert.

Was haltet Ihr davon? Kann so etwas überhaupt von der Performance funktionieren? Oder gibt es eine elegantere Lösung? In Wordpress kann ich auch mehrere DS gleichzeitig aktualisieren, z.B. den Autor.

Ich könnte das WHILE auch um das Formular machen, dann könnte ich jeden DS einzeln speichern, hätte dann aber 50 Buttons, müsste nach jedem Feld einzeln speichern und im Formular wieder an die richtige Stelle scrollen um weiter zu machen.

Ich will auch bewusst nicht mit einer Config-Datei arbeiten. Für mich selber kein Problem, möchte das aber nicht dem ungeübten Anwender zumuten.

Euch einen schönen Tag, Gruß René

[Dormilich]

Was haltet Ihr davon?

Nichts.

Oder gibt es eine elegantere Lösung?

https://en.wikipedia.org/wiki/Entity...%93value_model

Geht zwar nicht alles mit einem einzelnen Update zu aktualisieren, dafür ist das Datenmodell recht flexibel.

[protestix]

Ich will auch bewusst nicht mit einer Config-Datei arbeiten. Für mich selber kein Problem, möchte das aber nicht dem ungeübten Anwender zumuten.

Der Anwender sollte von der Datenhaltung nichts mitbekommen, es geht ihn schlicht nichts an.

Um die Perfomance muss du dir bei so wenigen Bytes im Übrigen keine Gedanken machen.

[radarin]

Danke für den Link, ich versuche das mal zu verstehen. Sonst muss dann halt doch jeder Eintrag einzeln bearbeitet und gespeichert werden. Anders wäre es mir lieber, aber ich kann auch damit leben.

Der Anwender ist in diesem Fall der Webmaster, der kriegt sowieso alles zu sehen wenn er will. Es ist auch für den Admin die elegantere Lösung, Formulare auszufüllen, als in Textdateien rum zu fummeln. Da in diesen Dateien nebst den eigentlichen Werten auch noch etwas PHP Code drin ist, besteht auch die Möglichkeit von Fehlern. Das will ich auch vermeiden. Da Plugin soll in WP eingesetzt werden, da sich die Admins einfach verwöhnt.

Bei der Performance denke ich vor allem daran, wenn ich praktisch die Datenbank gleichzeitig mit 50 UPDATE TABLE WHRE ID = xy bombardiere.

[hellbringer]

Bei der Performance denke ich vor allem daran, wenn ich praktisch die Datenbank gleichzeitig mit 50 UPDATE TABLE WHRE ID = xy bombardiere.

Gibt es denn überhaupt Performanceprobleme? Oder versuchst du Probleme zu lösen, die nicht existieren?

[radarin]

@hellbringer, ich weiss nicht ob das ein Problem ist, wenn nein, ist es mir noch so recht. Deshalb frage ich, nicht dass es später heisst, welcher Teufel hat dich geritten. Dormilich hält jedenfalls nichts davon.

[protestix]

Ich glaube Dormich bezog sich auf diese Aussage

Einfach wäre natürlich eine Tabelle mit 50 Spalten und einer Zeile,

und das ist Unfug, daher hat er dir auch den Link gegeben, damit du dort Liest und es verstehst wie man es richtig macht.
.

[radarin]

:/ verstehen? nicht wirklich.

Ich hab jetzt meine 50 Datensätze und kümmere mich erst mal um das Formular zur Bewirtschaftung.

[drsoong]

Hm, Tabellen mit 50 oder vlt. 150 Spalten?! Ich glaube, Du solltest wirklich mal erst 'ne Woche in einen soliden Grundkurs "PHP/MySQL/Datenbankdesign" investieren. Gibt's alles im Netz kostenlos.

[VPh]

Naja, den Nachteil des Ansatzes hat radarin ja auch schon selbst erkannt und dazu noch eine weitere Idee geäußert. Die imo auch nach EAV aussieht, aber komisch beschrieben ist.

[radarin]

imo? EAV? (Banküberfall?)

Mein Formular lädt alle 50 Datensätze. Den Feldnamen hab ich einfach noch die DSID angehängt. Wenn die SQL Anweisung UPDATE mit der ID bestückt werden kann, sollte das dann eigentlich auch funktionieren. Werde ich aber wohl erst heute Abend testen können. Jetzt geht es erst mal ans Lauberhorn. Die Patrouille Suisse will da zusammen mit einem Airbus A320 ihre Kurven fliegen. Immer wieder ein Spektakel.

[radarin]

Ich sehe gerade, ich versuche wieder eine Variable im Array zu verarbeiten, da habe ich eine böse Vorahnung.

array(
            'settings_value'  => $_POST['settings_value']
 ) 

An das $_POST['settings_value'] muss noch $_POST['settings_ID'] angehängt werden. So dass aus settings_value z.B. settings_value1 wird.

[drsoong]

imo? EAV? (Banküberfall?)

imo = in my opinion, oft auch imho = in my humble opinion.

Ich vermute, EAV meint eigentlich EVA(-Prinzip) = Eingabe - Verarbeitung - Ausgabe.

[Dormilich]

Ich vermute, EAV meint eigentlich EVA(-Prinzip)

Nope. EAV = Entity-Attribute-Value. Sh. Link in Post #2.

[protestix]

EAV + Entity-Attribute-Value ist ein Datenmodell.
https://plausibolo.de/pg/Datenmodell...bute-Value.pdf