Performancefrage: x Defines vs. Datenbankabfrage

[jwe]

Ich habe einen Datenbank, die einmal pro Nacht aktualisiert wird.
Grundsätzlich stellt sich mir nun folgende Frage, was eine höhere Performance bringt:
a) der normale Weg per SQL-Statements ('SELECT id,name FROM TAB_NAME') die Daten auszulesen, oder
b) direkt nach der Datenaktualisierung die Tabelleninhalte in einer include-Datei als Konstanten zu definieren.

Define ('TAB_NAME',array(
    1 => 'Peter',
    2 => 'Klaus',
    3 => 'Dieter')
      ); 

Da der Quelltext ja compiliert wird und dann bei häufigem Gebrauch auch im Speicher bleibt, sollte doch Variante b) (zumindest ab dem zweiten Zugriff) extrem schneller werden als Variante a).

Hat einer Erfahrungen mit sowas?
Was passiert, wenn der Quelltext (mit Mamut-DEFINE-Anweisungen) dann auf einmal 5, 50 oder 500 MB groß wird?
Was passiert, wenn diese includes von mehreren Scripten eingebunden werden müssen, die zeitgleich laufen? Sind die Includes (bzw. der daraus generierte Konstantenstamm) dann auch n-mal im Speicher?
Was muss ich beachten? Irgendwelche Tipps?

[h3ll]

Die Frage ob Konstanten oder nicht sollte nicht von der Performance, sondern vom Programmaufbau abhängig sein. Im Grunde sollte man nicht mehr globale Konstanten verwenden, als unbedingt nötig. Am besten gar keine.

Wenn du Sorgen wegen der Performance hast (obwohl ich es hier für unbegründet halte) verwende ein Caching wie zB. Zend_Cache.

Zu deinem Beispiel: Konstanten können kein Array beinhalten. Konstanten sind auch nicht zur Datenspeicherung gedacht und denkbar ungeeignet dafür.

[jwe]

Na ist schon klar, dass es bei so wenig Daten und dieser Struktur das völlig unwichtig ist. Ich sehe nur hin und wieder, dass z.B. mehrsprachige Programme ihre Texte zwar in einer Datenbank pflegen, diese dann aber in Konstanten (const.nl, const.gb, const.de usw.) überführt werden.

Laut PHP Buch sollten doch auch Arrays in einer Konstanten gespeichert werden können?!? Oder verstehe ich da folgende Definition falsch:

bool define ( string $name , [COLOR=#0000ff]mixed[/COLOR] $value [, bool $case_insensitive = false ] )

Ok, statt globale Konstanten können es ja auch normale Arrays werden also "$tab_name = array (...);"

Aber trotzdem schon mal Danke für den Tipp mit dem Zend_Cache - werde ich mich mal einlesen ...

[h3ll]

Na ist schon klar, dass es bei so wenig Daten und dieser Struktur das völlig unwichtig ist. Ich sehe nur hin und wieder, dass z.B. mehrsprachige Programme ihre Texte zwar in einer Datenbank pflegen, diese dann aber in Konstanten (const.nl, const.gb, const.de usw.) überführt werden.

Weil die nicht wissen, wie man es richtig macht. Für Mehrsprachigkeit gibts gettext, Zend_Translate und andere Möglichkeiten.

Laut PHP Buch sollten doch auch Arrays in einer Konstanten gespeichert werden können?!? Oder verstehe ich da folgende Definition falsch:

The value of the constant; only scalar and null values are allowed. Scalar values are integer , float , string or boolean values. It is possible to define resource constants, however it is not recommended and may cause unpredictable behavior.

http://de.php.net/manual/en/function.define.php

Ok, statt globale Konstanten können es ja auch normale Arrays werden also "$tab_name = array (...);"

Kommt drauf an. Es macht zB. keinen Sinn tausende Datensätze in ein Array zu schreiben, wenn man nur 20 Stück davon braucht.

[jwe]

Danke!
Ich glaube, der Hinweis mit dem Zend_Cache hat mir weiter geholfen!
Hab zwar unter dem Begriff nix gefunden, aber mit memcache_pconnect kann man wohl auch Daten über das Scriptende hinaus im Speicher behalten und mit anderen Scripten drauf zugreifen?! Sogar zeitlich unbegrenzt, sodass ich bei meiner nächtlichen Aktualisierung, die Daten da direkt reinschreiben kann und bis nächste Nacht drin lassen kann und dann wieder überschreiben ...

[h3ll]

Danke!
Ich glaube, der Hinweis mit dem Zend_Cache hat mir weiter geholfen!
Hab zwar unter dem Begriff nix gefunden, aber mit memcache_pconnect kann man wohl auch Daten über das Scriptende hinaus im Speicher behalten und mit anderen Scripten drauf zugreifen?! Sogar zeitlich unbegrenzt, sodass ich bei meiner nächtlichen Aktualisierung, die Daten da direkt reinschreiben kann und bis nächste Nacht drin lassen kann und dann wieder überschreiben ...

Die Frage ist halt, ob das wirklich notwendig ist. Hast du Zeitmessungen gemacht?

MySQL hat selber schon einen Query-Cache, der eigentlich sehr gut funktioniert. Man muss die Daten nicht unbedingt doppelt cachen. Doppeltes Caching verbraucht mehr Ressourcen als einfaches Caching. Also vorher immer genau überlegen, was man damit überhaupt bezwecken will.

Wenn du die Datenbank entlasten möchtest, solltest du bei den Datenbankabfragen anfangen, die am meisten Performance benötigen und nicht bei irgendwelchen Abfragen, die kaum von Bedeutung sind. Das ist sonst verschwendete Zeit, die du da rein steckst.

[jwe]

Sicher kann man viel zeit sparen, wenn die DB perfekt strukturiert ist und die Abfragen entsprechend formuliert werden. Leider kann ich aber nicht immer alles in der DB filtern bzw. zusammenstellen lassen - selbst nicht mit stored Procs. Daher habe ich manchmal relativ viel Daten, die zwischen MySQL und PHP hin und her geschoben werden. Solange beides auf einem Windows-System läuft, geht das über NamedPipes ja im Speicher, also zügiger als über das TCP/IP-Protokoll.
Mein Projekt ist eine Intranet-Anwendung die fette Auswertungen machen muss. Teilweise mit Laufzeiten bis 4 Minuten. Mein Ziel ist es eigentlich jeden Ergebnis in ca. 10 Sekunden liefern zu können. Denn wenn aus 100 Filialen um 19:55 Uhr alle "mal eben" ihre Umsätze/Bestände/Zielerreichungen usw. abfragen, dann wird's knapp bis Feierabend

Auf jeden Fall werde ich noch den einen oder anderen Punkt von dir mir morgen im Garten auf der Liege durch den Kopf gehen lassen, bevor ich anfange zu proggen ... hast mir schon ganz gut geholfen.