nikosch

Weil für die Persistenz der Ausgabe eben auch View-Caching zuständig ist.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Mister Ad

mepeisen

Von der Domäne betrachtet hast du Recht, Nikosch. Insofern ein ungeschicktes Beispiel mit dem Forum, gebe ich zu. Es ist ja auch von Design, Template und und und abhängig Caches sind im Prinzip nichts anderes als redundant abgelegte Versionen eines Datenbestandes. Die Umrechnung des gewichtes ist im Grunde nichts anderes als ein kleiner Mini-Cache.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

mermshaus

„DECIMAL“ in PHP: http://www.php.net/manual/en/book.bc.php (BC Math)

Den höheren Speicherverbrauch zwischen FLOAT/DOUBLE und DECIMAL halte ich für kein ausschlaggebendes Argument.

Die Frage sollte sein, ob du mit Fließkommazahlen arbeiten kannst/willst/darfst oder nicht.

Fließkommazahlen sind eben potentiell unexakt und machen Prüfungen auf Gleichheit schwierig.

- http://dev.mysql.com/doc/refman/5.1/...ith-float.html

Ich würde sie hier nicht einsetzen.

Edit: @mepeisen/nikosch: Ich find's recht sinnvoll, die für den Ausgabekontext HTML gerenderte Version eines Posts/Blogeintrags/… einzeln zu cachen. Das kann ja in einer Extratabelle post_cache_html oder so geschehen (wäre also praktisch die DB als Caching-Backend). Gerade das Umwandeln von BBCode oder so nach HTML ist doch sehr teuer, wenn etwa Syntax Highlighting betrieben werden muss.

__________________
Blog | Buch | Kaloa

Trainmaster

Mein ursprüngliches Anliegen war und ist die persistente Speicherung von metrischen Daten. Potentiell nicht-exakte Werte sehe ich als Gift. Primär will ich dieses System für einen kleinen Shop einsetzen. Mit Sicherheit ist dies völlig überdimensioniert. Dennoch möchte ich parallel ein universelles System entwickeln, dass in der Zukunft für diverse Zwecke eingesetzt werden kann. Lieber mache ich mir einmal mehr Gedanken, als dann ständig Probleme zu haben. Wie auch immer, was ich einsetzen darf und will ist mir überlassen.

So wie es scheint, komme ich um den DECIMAL-Datentyp nicht herum. Die Idee von nikosch, Ganzzahlen mit Exponenten zu speichern und damit in der Datenbank zu rechnen / vergleichen, wird wohl nicht funktionieren. Es gibt keinen Datentyp, der sich dafür eignet, schade eigentlich. Über weitere Anregungen oder Ideen zur Thematik würde ich mich freuen. Ansonsten sehe ich das Thema als erledigt. Danke soweit.