[PHP] mehrere UPDATES zusammenfassen

[forTeesSake]

<< tabelle formularfelder >>


+--------------------------------------------+

|formID  | fieldID | fieldName | fieldValue  |

+--------------------------------------------+

|   1	 |   1      | name     | 'müller'    |

|   1	 |   2      | strasse  | 'baumstr. 6'|

|   1	 |   3      | telefon  |  '7766555'  |

+--------------------------------------------+

hi und hallo,

oben stehende tabelle ist für eine

 anwendung die folgendermassen funktioniert:

- ein benutzer kann neue formulare unterschiedlicher typen anlegen

- z.b. ein formular vom typ "person" oder "auftrag" usw.

- es gibt formular templates, die für jeden typ alle felder enthalten

- beim erzeugen eines neuen formulars werden dann einfach die felder des templates kopiert und in der tabelle eingefügt.

- nun hat der anwender also das html formular basierend auf den feldern der datenbank vorliegen und will speichern

der $query dafür sieht dann (in worten) folgendermassen aus:

1. hole alle felder [fieldName] aus der datenbank deren formID die übergebene [$_POST] ist.

2. {while] solange datensätze vorhanden => $line

3. [uPDATE] schreibe alle feldwerte [fieldValue] in die tabelle << formularfelder >> wo

- die formID die übergebene [$_POST] ist

- der fieldName gleich dem $line['fieldName] ist

4. ende.

soweit so gut.

leider gibt das erhebliche performance probleme. dazu habe ich auch einen post im [MAC] forum geschrieben. half aber alles nichts.

das grosse problem sind wohl die bis zu 50 updates (bei formularen mit vielen feldern).

frage:

gibt es die möglichkeit die updates auf irgendeine art und weise zu einem einzigen update bzw. datenbankzugriff zusammen zu fassen???

also sowas wird

[QUATSCH]

UPDATE formularfelder SET

fieldValue = 'test' WHERE fieldName = 'name',

fieldValue = 'test2' WHERE fieldName = 'strasse',

fieldValue = 'test2' WHERE fieldName = 'telefon'

[/QUATSCH]

natürlich geht das nicht, aber ich suche nach irgendwas, was dem nahe kommt.

oder fällt evtl. jemandem eine tabellenstruktur ein, die ein einziges UPDATE leistet?

vielen dank schonma

[Jaraz]

Welche Datenbank?

Warum fieldID und fieldName?

Fasse das ganze in einer Transaktion zusammen.

Liegen auf formID | fieldID | fieldName Indexe?

Gruß Jaraz

[Whatever]

gibt es die möglichkeit die updates auf irgendeine art und weise zu einem einzigen update bzw. datenbankzugriff zusammen zu fassen???

Nein, geht nicht.

[forTeesSake]

Welche Datenbank?

Warum fieldID und fieldName?

Fasse das ganze in einer Transaktion zusammen.

Liegen auf formID | fieldID | fieldName Indexe?

Gruß Jaraz

es ist eine mysql datenbank. der mysql server hat die version 5.0.15

<< Fasse das ganze in einer Transaktion zusammen. >>

kannst dus mir genauer erklären? das ist ja genau das, was meine frage ist.

oder meinst du in etwa so:

$query = "UPDATE table Set x = y;"

$query.= "UPDATE table Set x = y;"

$query.= "UPDATE table Set x = y;"

$query.= "UPDATE table Set x = y;"

mysql_query($query);

bringt das was?

die fieldID ist der primärschlüssel der tabelle. fieldName ist gleichzeitig der name des korrespondierenden <input> feldes

z.b. <input type="text" name="<?php echo($line['fieldName']); ?>">

[geloescht_JesterDay]

<< tabelle formularfelder >>


+--------------------------------------------+

|formID  | fieldID | fieldName | fieldValue  |

+--------------------------------------------+

|   1	 |   1      | name     | 'müller'    |

|   1	 |   2      | strasse  | 'baumstr. 6'|

|   1	 |   3      | telefon  |  '7766555'  |

+--------------------------------------------+

[...]

[QUATSCH]

UPDATE formularfelder SET

fieldValue = 'test' WHERE fieldName = 'name',

fieldValue = 'test2' WHERE fieldName = 'strasse',

fieldValue = 'test2' WHERE fieldName = 'telefon'

[/QUATSCH]

[...]

oder fällt evtl. jemandem eine tabellenstruktur ein, die ein einziges UPDATE leistet?

Öm... ja:

Tabelle:

ID

Name

Strasse

Telefon

Update Tabelle Set Name=´test´, Strasse=´test2´, Telefon=´test3´ where ID = X

Oder warum hast du Name, Strasse, Telefon jeweil als eigenen Satz?

[geloescht_JesterDay]

<< Fasse das ganze in einer Transaktion zusammen. >>

kannst dus mir genauer erklären? das ist ja genau das, was meine frage ist.

Eine Transaktion ist nicht genau was du meinst Mit einer Transaktion kannst du eine beliebige Anzahl an DB-Updates (Deletes, Inserts) quasi Aufzeichnen und erst am Ende mit einem Commit wirklich durchführen. Die einzelnen Updates (in deinem Fall) würden dennoch alle einzeln an den Server geschickt und von dem einzeln aufgenommen.

EDIT:

Wenn es bei der Verarbeitung zu Fehlern kommt, kannst du bei einer Transaktion mit einem Rollback alle Änderungen wieder rückgängig machen. Das ist immer dann Hilfreich, wenn mehrere Tabellen geändert werden, aber alle Änderungen zusammenhängen. Wenn die letzte Aktion schief geht würde z.B. irgendwas mit den Daten nciiht mehr klappen. Mit einer Transaktion kannst du sicherstellen, dass alle deine Änderungen auch wirklich korrekt auf der DB angekommen sind.

[forTeesSake]

Öm... ja:

Tabelle:

ID

Name

Strasse

Telefon

Update Tabelle Set Name=´test´, Strasse=´test2´, Telefon=´test3´ where ID = X

Oder warum hast du Name, Strasse, Telefon jeweil als eigenen Satz?

nein das stimmt nicht, denn name, strasse, telefon sind ja keine felder sondern die feldinhalte des feldes fieldName...

als eigenen satz brauche ich die, weil sich ein formular ja aus seinen feldern aufbaut

[geloescht_JesterDay]

als eigenen satz brauche ich die, weil sich ein formular ja aus seinen feldern aufbaut

Also sind die Formulare immer dynamisch oder sind die das nur so halb? Wenn deine Maske zwar ansich nicht "starr" sein soll, die Werte für einzelne Daten aber dennoch immer gleich sind (z.B. Daten einer Person), kannst du das ja in 2 Tabellen aufteilen.

Eine Tabelle enthält die Daten selber (wie in meinem Beispiel) und darauf machst du die updates, und die andere enthält alle Felder, die du für dein Formular brauchst (die müssen natürlich der Tabelle entspr.).

EDIT:

Die zweite Tabelle wäre also praktisch deine jetzige

Somit sind die Formulare schon dynamisch, aber deine Updates dennoch "starr".

[forTeesSake]

Also sind die Formulare immer dynamisch oder sind die das nur so halb? Wenn deine Maske zwar ansich nicht "starr" sein soll, die Werte für einzelne Daten aber dennoch immer gleich sind (z.B. Daten einer Person), kannst du das ja in 2 Tabellen aufteilen.

Eine Tabelle enthält die Daten selber (wie in meinem Beispiel) und darauf machst du die updates, und die andere enthält alle Felder, die du für dein Formular brauchst (die müssen natürlich der Tabelle entspr.).

EDIT:

Die zweite Tabelle wäre also praktisch deine jetzige

Somit sind die Formulare schon dynamisch, aber deine Updates dennoch "starr".

ja, du hast recht. mit "meiner" lösung ist es halt sehr einfach formulare zu erweitern.

mit der "normalisierten" lösung muss ich nun für jedes formular eine eigene tabelle anlegen. und dort müssen alle spalten für jedes einzelne feld angelegt werden.

und: daraus resultiert dann, dass meine save routine immer auf das jeweilige formular angepasst werden muss.

bis jetzt konnte ich ja immer über "fieldName" und "formID" rausfinden um welches feld es geht.

das ist bei mehreren tabellen mit unterschiedlichen feldbezeichnungen dann ja leider nicht mehr möglich *heul*

somit muss ich für jedes formular einen eigenen query anlegen und wenn das formular erwitert wird auch wieder den query anpassen ;(

schade schade. aber da muss wohl alles umgeschrieben werden. blöder mac....(oder blöder programmierer??) hihi

[Jaraz]

Sollte der Tabellentyp Innodb sein, schreibt mysql nach jedem Update die Daten auf Platte, das bedeutet bei 50 Updates 50 Mal auf Platte schreiben, also min. 50 Umdrehungen der Platte.

Das ganze als Transaktion, muss nicht sein. Du solltest aber autocommit ausschalten und commit am Ende deiner Updates von Hand aufrufen.

Und wie gesagt, warum fieldID und fieldName?

Organisiere deine updates auf die fieldID und setze auf die Spalte einen Index.

Wenn du das so umsetzt, sollte es mich wundern wenn es nicht performant genug wäre.

Natürlich ist ein einzelnes update schneller aber wenn man eine dynamische Anzahl von Formularfeldern verwalten will, gehts halt nicht anders.

Gruß Jaraz

[geloescht_JesterDay]

ja, du hast recht. mit "meiner" lösung ist es halt sehr einfach formulare zu erweitern.

mit der "normalisierten" lösung muss ich nun für jedes formular eine eigene tabelle anlegen. und dort müssen alle spalten für jedes einzelne feld angelegt werden.

[...]

und: daraus resultiert dann, dass meine save routine immer auf das jeweilige formular angepasst werden muss.

Nein, du hast eh eine Tabelle mit den Daten (z.B. Personen). Für die Formulare legst du dann nur eine weitere Tabelle an, nennen wir sie mal Forms, die würde ung. so aussehen:

#Forms

  ID

  Formname

  TableName

  FieldName

  DisplayName

Darin hättest du die Infos für all deine formulare und all deine Tabellen. Eine ID als eindeutiger Schlüssel ist immer gut. Formname, für den Namen des jeweiligen Formulars. TableName um den bezug zu einer Tabelle herzustellen. Fieldname beschreibt das jeweilige Feld und DisplayName ist die bezeichnung, die das Feld in der Anzeige des Formulars haben soll. Für deine Personen würden die Einträge für das Formular z.B. so aussehen (mit meiner Tabelle für die Daten):

ID | Formname | TableName | FieldName | DisplayName

1  |  FrmPerson| Personen    | Name      |  Name

2  |  FrmPerson| Personen    | Strasse   |  Strasse

3  |  FrmPerson| Personen    | Telefon    |  Telefon

Damit kannst du dir auch dynamisch ein Formular aufbauen und auch die SQLs gehen dynamisch damit. Du kannst sogar für ein Formular (z.B. FrmPerson2) nur die Felder Name und Telefon nehmen aus der Tabelle Personen.

Du bist damit total flexibel mit deinen Formularen und hast dennoch einen Datenbestand, der aufgeräumt ist und sich somit auch leichter mit anderen Tools bearbeiten läßt.

Für jedes neue Formular müssen dann nur ein Paar Einträge in eine Tabelle gemacht werden und das könntest du ja auch über ein eigenes Verwaltungsformular machen.

Auch die Save Routine müsste nicht angepasst werden für jedes Formular, du musst dir nur die Infos zum Formular beim aufbauen irgendwo merken (also das was du aus der Forms-Tabelle ausliest).

EDIT:

Ausserdem könntest du in der Tabelle Forms auch noch für jedes Feld Informationen wie z.B. den Feldtyp (also checkbox, text...) und die Größe (falls nötig) angeben. Damit wären deine Formulare wirklich dynamisch.

Auch ein Formular aus mehreren Tabellen sollte möglich sein.

[forTeesSake]

oki doki. ich werde das ganze mal ausprobieren.

der tabellentyp ist übrigens MYISAM

Organisiere deine updates auf die fieldID und setze auf die Spalte einen Index.

fieldID ist bei mir der primärschlüssel der tabelle. kann ich das noch optimaler machen?

vielen dank!

[Jaraz]

Einen extra Primärschlüssel brauchst du doch gar nicht.

Ich würde das so machen:

CREATE TABLE felder (

feldid int(11) NOT NULL,

feldname varchar(255) NOT NULL,

PRIMARY KEY (feldid)

)

CREATE TABLE felderwerte (

formid int(11) NOT NULL,

feldid int(11) NOT NULL,

wert varchar(255) NOT NULL,

PRIMARY KEY (formid,feldid)

)

Und dann das update so:

update felderwerte set wert = 'Schulz' where formid=1 and feldid=2

Wie groß ist denn überhaupt die Tabelle?

[forTeesSake]

hi und hallo

update felderwerte set wert = 'Schulz' where formid=1 and feldid=2

hätte mir in dem fall leider nichts gebracht, denn das ist das selbe das ich schon hatte und bedint dann wieder

update felderwerte set wert = 'Schulz' where formid=1 and feldid=2

update felderwerte set wert = 'Meier' where formid=1 and feldid=3

update felderwerte set wert = 'Hempel' where formid=1 and feldid=4

update felderwerte set wert = 'Ziegler' where formid=1 and feldid=5

und genau das macht ja die geschwindigkeitsprobleme aus ;(

aber ich hab nun nochma drüber geschlafen und mache das ganze folgendermassen:

ich splitte meine html/php seite in zwei frames, eines davon 0% auf.

beim speichern wird auf das 0% frame gepostet und im aktuellen frame die nächste seite angezeigt.

somit kann der benutzer gleich weiter arbeiten und es wird im hintergrund gesaved.

beim nächsten mal muss ich mir wohl beim anlegen der tabellen ein paar mehr gedanken machen...

vielen dank für alles

[kills]

Hi,

verwende besser AJAX, dann brauchst du den Extra Frame nicht.

Gruß,

Markus

[forTeesSake]

Hi,

verwende besser AJAX, dann brauchst du den Extra Frame nicht.

Gruß,

Markus

jupp! vielen dank. dad haben wir dann gestern noch per AJAX gelöst. endlich..