Eigene Tabelle in constants.php definiert - Und dann?

[S2B]

Doch wie sieht ein kombinierter SELECT/UPDATE Befehl aus?

kombiniert? Du liest am Anfang alles mit SELECT aus und speicherst später die Änderungen per UPDATE in die Datenbank.

Mal ein ganz einfaches Beispiel:
HTML:

Code: Alles auswählen

<form action="datei.php" method="post">
	<input type="text" name="wert" value="{WERT}" />
	<input type="submit" value="Speichern" />
</form>

PHP:

Code: Alles auswählen

if (isset($_POST['wert']))
{
	// Wert in der Datenbank aktualisieren
	$sql = 'UPDATE ' . CONFIG_TABLE . "
		SET config_value = '" . $db->sql_escape($_POST['wert']) . "'
		WHERE config_name = 'wert'";
	$db->sql_query($sql);
}

// aus der Datenbank auslesen
$sql = 'SELECT config_name, config_value
	FROM ' . CONFIG_TABLE;
$result = $db->sql_query($sql);

$werte = array();
while ($row = $db->sql_fetchrow($result))
{
	$werte[$row['config_name']] = $row['config_value'];
}
$db->sql_freeresult($result);

// ins Template damit:
$template->assign_var('WERT', $werte['wert']);

Hinweis: Der Code ist nicht 1:1 übertragbar und sollte in dieser Form auch nicht eingesetzt werden. Er zeigt aber ganz gut, wie das mit den Formularen genau funktioniert.

[4seven]

Vielen Dank,
kombiniert war wohl der falsche Ausdruck.

und sollte in dieser Form auch nicht eingesetzt werden

Mit anderen Worten, sofern dieses Beispiel auf phpbb3-Standard-Syntax angepasst wird, dürfte es korrekt sein. Ich denke mal, du meinst ua, das es wegen der $POST-Übermittlung unsicher wäre!?

[S2B]

• Übermittlung per $_POST
• Form-Action ohne append_sid()
• Sprachvariable fehlt

Außerdem sollte man für die Config-Tabelle nicht diesen Code, sondern die entsprechenden phpBB-Funktionen (z.B. set_config()) verwenden.

[4seven]

Jup, wird eine eigene Tabelle ansprechen und set_config ist natürlich einfach. Weiß ja nicht, ob es da eine moralische Begrenzung gibt, wieviele Einträge ein Mod dort reinschreiben darf. Ich hatte mal spaßeshalber set_config kopiert und angepasst. Ich konnte zwar Werte reinschreiben, aber beim zweiten absenden eines Eimtrags mittels set_bbcb3($config_name , $config_value), gab es Meldungenn a la

Duplicate entry '0' for key 3 [1062]
SQL
INSERT INTO phpbb3_bbcodes (bbcode_id) VALUES (0)
BACKTRACE

Es geht also scheinbar nicht nur um die reine Function set_config. Da hängt wohl ein ganzer Rattenschwanz dran, der die $config Variable zusätzlich steuert. Habs dann irgendwann aufgegeben eine "eigene" set_config zu basteln. Schade war es dennoch, weil es natürlich per global supereasy wäre.

[DerPate]

Weiß ja nicht, ob es da eine moralische Begrenzung gibt, wieviele Einträge ein Mod dort reinschreiben darf.

Sry, dass ich den Thread aus der Versenkung hole, aber diese Frage stelle ich mir auch gerade ... Ich bastel momentan an einem "etwas" umfangreicherem Mod und hab bereits über 60 neuer Werte in der CONFIG_TABLE und es kommen sicherlich noch ein paar dazu ...

Wenn da nun 2000 statt 200 Einträge enthalten sind, gehts sicherlich auf der Performace, oder? Ich könnte ein paar Sachen auf andere Tabellen verteilen, aber hätte damit 1-3 SQL-Abragen mehr/Seitenaufruf.

Was ist, ausgehend von ~100 eigenen config-Werten sinnvoller? Eigene Config-Tabelle oder die bereits vorhandene nehmen?


Noch 2 kleine Fragen ...
Gibts einfach zu konfigurierende php-Benchmarks, womit ich das ganze mal vergleichen kann?
Gibt es eine Möglichkeit statt den kompletten Cache nur bestimmte SQL-Abfragen zu löschen?

[Boecki91]

Ich finde 100 neue Einträge sind zu viel für die config.

Generell kann man nicht sagen wie man etwas besser machen könnte und wie.

Vielleicht kann man mehrere Daten in ein Feld schreiben (Bit-Codiert) oder eine eigene Tabelle anlegen. Wichtig wäre zu wissen wie oft auf die Werte zugegriffen wird, sind sie eher dynamisch oder statisch oder oder oder.

[DerPate]

Vielleicht kann man mehrere Daten in ein Feld schreiben (Bit-Codiert) ...

Toll, halben Roman geschrieben und beim schreiben kommen so die Ideen ...

Danke für den Denkanstoß! Kommagetrennt in ein Feld schreiben, was zusammen gehört und per explode/imlode weiterverwurschteln hilft mir auch schon weiter

Damit ist schonmal ein beachtlicher Teil gespart. Bleiben noch Gesamtangaben (vglb. total_posts, total_topics), Limtis (vglb. Posts/Topics pro Seite) für die Seitennummerierung und diverse ACP-Optionen. Diese Werte werden im Forum nicht benötigt, aber dafür bei jedem Aufruf einer der Modseiten. Daher glaub ich die sind in der config-Table ganz gut aufgehoben, oder?

Selbst wenn da noch 30-40 Einträge übrig bleiben sollte das, wenn man schaut, was durch diverse Andere Mods noch hinzukommen kann, nicht allzuviel ausmachen.

Die Frage der extra Tabell hat sich erledigt, ist nur noch die Frage die Daten sinnvoll zusammengefasst abzuspeichern, aber das sollte nich das Problem sein.

Danke