Thomas: Performance oder Wartbarkeit

Hallo.

Ich würde mal gerne von anderen wissen, wie sie Programme technisch verwalten. Nehmen wir z. B. eine Website, die aus verschiedenen PHP-Skripts besteht und Einträge in einer DB verwaltet. Vielleicht hat sie eine Spalte in der Datenbank, aus der auf einer Seite ein Optionsfeld (select) erstellt werden soll. In der Datenbank werden die Einträge des Optionsfeldes in einem (My-SQL-)Enum-Feld gespeichert: Auswahl 1, Eintrag 2, stelle3, wie auch immer. Eine Möglichkeit wäre, vor der Ausgabe des Optionsfeldes alle Einträge in der Datenbank abzufragen und dann das Select-Feld dynamisch zu befüllen. Als ehemaligem Assembler-Programmierer geht mir sowas aber gehörig gegen den Strich, wenn ich weiß, die Einträge bleiben immer gleich. Eine andere Möglichkeit wäre dann, die Einträge direkt im Skript zu speichern.

Was aber, wenn sich nun doch einmal etwas ändert? Richtig, der Code muß geändert werden. Wird das Optionsfeld oder Einträge daraus an verschiedenen Stellen und in verschiedenen Skripts gebraucht, muß das auch an allen Stellen geändert werden. Das verursacht Arbeit, und es ist nicht unwahrscheinlich, daß irgend etwas vergessen wird. Wären die Optionsfelder dynamisch befüllt worden, hätte eine simple Änderung an der Datenbank gereicht.

Ich weiß, es ist wahrscheinlich eine verdammt dumme Frage, aber ich habe in einer Zeit das Programmieren gelernt, als man z. B. Berechnungen für Bewegungen im voraus anstellte und die Ergebnisse in einer Tabelle ablegte, um maximale Programmbeschleunigung zu erreichen. Die Berechnungen während der Programmausführung durchzuführen wäre viel zu langsam gewesen. Heute ist das wohl kaum noch nötig. Leider komme ich da nicht aus meiner Haut. Ich sehe ja, bei einer kleinen Website ist es ziemlich egal, ob ich eine Select-Anfrage mehr oder weniger an die Datenbank schicke, doch mein Gedanke ist immer, was ist, wenn die Site mal größer wird. Das einzige, was man noch tun könnte, unnötige Datenbankabfragen zu vermeiden, ist, Inhalte, die mehrfach verwendet werden oder die womöglich irgendwann geändert werden müssen, in einer inkludierten Datei abzulegen.

Deshalb würde ich gern mal wissen, ob Ihr auch solche Überlegungen anstellt, oder aus ökonomischen Gründen auf maximale Wartbarkeit Wert legt, sprich alles in einer Datenbank ablegt, egal ob das zusätzliche, unnötige Datenbankabfragen bedeutet.

  1. hi,

    Eine Möglichkeit wäre, vor der Ausgabe des Optionsfeldes alle Einträge in der Datenbank abzufragen und dann das Select-Feld dynamisch zu befüllen. Als ehemaligem Assembler-Programmierer geht mir sowas aber gehörig gegen den Strich, wenn ich weiß, die Einträge bleiben immer gleich. Eine andere Möglichkeit wäre dann, die Einträge direkt im Skript zu speichern.

    Was aber, wenn sich nun doch einmal etwas ändert?

    Dann war ja die ursprüngliche Annahme, sie blieben _immer_ gleich, falsch.

    Als Programmierer in einer komplierten Sprache müsstest du jetzt sogar wieder den Compiler anwerfen, das Programm neu ausrollen, etc. - _das_ kann's ja eigentlich auch nicht sein.

    Richtig, der Code muß geändert werden. Wird das Optionsfeld oder Einträge daraus an verschiedenen Stellen und in verschiedenen Skripts gebraucht, muß das auch an allen Stellen geändert werden. Das verursacht Arbeit, und es ist nicht unwahrscheinlich, daß irgend etwas vergessen wird. Wären die Optionsfelder dynamisch befüllt worden, hätte eine simple Änderung an der Datenbank gereicht.

    Ebend :-)

    Programmlogik und Daten sollten grundsätzlich getrennt werden.

    Gut begründete Abweichungen von dieser Maxime sind natürlich denkbar (wie bei allen anderen Maximen auch).
    Dann wäre aber zu überlegen, wie man das Ganze gegen das erwähnte "Vergessen" von Änderungen und ähnliche Fehlerquellen absichert, welche Schritte bei einer Änderung zu dokumentieren sind, um eben "Vergessen" weitgehend ausschliessen zu können, etc.

    Ich weiß, es ist wahrscheinlich eine verdammt dumme Frage, aber ich habe in einer Zeit das Programmieren gelernt, als man z. B. Berechnungen für Bewegungen im voraus anstellte und die Ergebnisse in einer Tabelle ablegte, um maximale Programmbeschleunigung zu erreichen. Die Berechnungen während der Programmausführung durchzuführen wäre viel zu langsam gewesen. Heute ist das wohl kaum noch nötig.

    Mit Ressourcen allzu verschwenderisch umzugehen, ist trotzdem nicht angebracht.

    Gerade bei komplexeren Berechnungen, deren Ergebnisse "statisch" bleiben, so lange sich auch die Eingabedaten nicht ändern, ist ein "Caching" der Ergebnisse natürlich oftmals sinnvoll.

    Das einzige, was man noch tun könnte, unnötige Datenbankabfragen zu vermeiden, ist, Inhalte, die mehrfach verwendet werden oder die womöglich irgendwann geändert werden müssen, in einer inkludierten Datei abzulegen.

    Das kann man ja zu einem Kompromiss kombinieren.
    Die eigentlichen Daten werden in der Datenbank vorgehalten, und auch dort ggf. geändert.
    Von diesen zieht man dann ein "Abbild" - im PHP-Umfeld könnte das bspw. eine entsprechend serialisierte, oder auch gleich als parse-barer Code in einer Include-Datei abgelegte Datenstruktur sein - die wird einfach eingebunden, und steht sofort zur Verfügung.
    Natürlich muss dieses Include dann neu generiert werden, wenn sich die Daten auf der Datenbank ändern. Auch hier ist wieder zu überlegen, wie man das verlässlich triggern kann.

    Deshalb würde ich gern mal wissen, ob Ihr auch solche Überlegungen anstellt, oder aus ökonomischen Gründen auf maximale Wartbarkeit Wert legt, sprich alles in einer Datenbank ablegt, egal ob das zusätzliche, unnötige Datenbankabfragen bedeutet.

    Wenn man mehrere Faktoren zu berücksichtigen hat, welche die Gesamteffizienz eines Systems in unterschiedliche Richtungen beeinflussen, dann wird man in aller Regel nicht in einer bestimmten Hinsicht "optimieren", weil das sich auf die anderen Faktoren ungünstig auswirkt - sondern auch hier einen Kompromiss suchen, der alle Faktoren möglichst ausgewogen berücksichtigt, um ein stimmiges Gesamtbild zu erhalten.

    Eine Applikation, die von einem Vierjährigen zu warten wäre, aber in Punkto Performance und Bedienbarkeit durch den Endanwender stark zu wünschen übrig lässt, ist genauso ein Rohrkrepierer, wie eine mit der einfachsten und effizientesten Datenhaltung, die aber nur von einem Spezialisten gewartet werden kann, der selbst für die Übersetzung der Textausgabe "hello world" in eine andere Sprache fünf Tage lang ins System eintauchen muss ...

    gruß,
    wahsaga

    --
    /voodoo.css:
    #GeorgeWBush { position:absolute; bottom:-6ft; }
    1. Hi,

      Programmlogik und Daten sollten grundsätzlich getrennt werden.

      Ja.

      Gut begründete Abweichungen von dieser Maxime sind natürlich denkbar (wie bei allen anderen Maximen auch).

      Eben.

      Dann wäre aber zu überlegen, wie man das Ganze gegen das erwähnte "Vergessen" von Änderungen und ähnliche Fehlerquellen absichert, welche Schritte bei einer Änderung zu dokumentieren sind, um eben "Vergessen" weitgehend ausschliessen zu können, etc.

      Dokumentieren ist wichtig, schon klar.

      Mit Ressourcen allzu verschwenderisch umzugehen, ist trotzdem nicht angebracht.

      Das beruhigt mich, d. h. vollkommen überholt ist mein Gedankengang nicht.

      Gerade bei komplexeren Berechnungen, deren Ergebnisse "statisch" bleiben, so lange sich auch die Eingabedaten nicht ändern, ist ein "Caching" der Ergebnisse natürlich oftmals sinnvoll.

      Das einzige, was man noch tun könnte, unnötige Datenbankabfragen zu vermeiden, ist, Inhalte, die mehrfach verwendet werden oder die womöglich irgendwann geändert werden müssen, in einer inkludierten Datei abzulegen.

      Das kann man ja zu einem Kompromiss kombinieren.
      Die eigentlichen Daten werden in der Datenbank vorgehalten, und auch dort ggf. geändert.
      Von diesen zieht man dann ein "Abbild" - im PHP-Umfeld könnte das bspw. eine entsprechend serialisierte, oder auch gleich als parse-barer Code in einer Include-Datei abgelegte Datenstruktur sein - die wird einfach eingebunden, und steht sofort zur Verfügung.
      Natürlich muss dieses Include dann neu generiert werden, wenn sich die Daten auf der Datenbank ändern. Auch hier ist wieder zu überlegen, wie man das verlässlich triggern kann.

      Genauso dachte ich mir das.

      Deshalb würde ich gern mal wissen, ob Ihr auch solche Überlegungen anstellt, oder aus ökonomischen Gründen auf maximale Wartbarkeit Wert legt, sprich alles in einer Datenbank ablegt, egal ob das zusätzliche, unnötige Datenbankabfragen bedeutet.

      Wenn man mehrere Faktoren zu berücksichtigen hat, welche die Gesamteffizienz eines Systems in unterschiedliche Richtungen beeinflussen, dann wird man in aller Regel nicht in einer bestimmten Hinsicht "optimieren", weil das sich auf die anderen Faktoren ungünstig auswirkt - sondern auch hier einen Kompromiss suchen, der alle Faktoren möglichst ausgewogen berücksichtigt, um ein stimmiges Gesamtbild zu erhalten.

      Eine Applikation, die von einem Vierjährigen zu warten wäre, aber in Punkto Performance und Bedienbarkeit durch den Endanwender stark zu wünschen übrig lässt, ist genauso ein Rohrkrepierer, wie eine mit der einfachsten und effizientesten Datenhaltung, die aber nur von einem Spezialisten gewartet werden kann, der selbst für die Übersetzung der Textausgabe "hello world" in eine andere Sprache fünf Tage lang ins System eintauchen muss ...

      gruß,
      wahsaga

      Ich ziehe daraus die Erkenntnis, man sollte einen Kompromiß, der Performance und Wartbarkeit unter Einbeziehung der Applikationsanforderungen optimal vereint, schließen.

      Früher war das ganz anders. Funktionen, die sich während des Programmablaufs selbst verändern, waren da ganz normal. Da wurde jeder Taktzyklus genau durchgerechnet. Da wäre es einfach undenkbar gewesen, Zugeständnisse in Richtung Lesbarkeit oder Wartbarkeit des Codes zu machen. Das genaue Gegenteil von OOP heute.

      Gruß
      Th.

      1. [...]

        Ich ziehe daraus die Erkenntnis, man sollte einen Kompromiß, der Performance und Wartbarkeit unter Einbeziehung der Applikationsanforderungen optimal vereint, schließen.

        Ja, sehe ich auch so, Du mußt halt abwägen, was im konkreten Fall die größten Prioritäten genießt.

        Früher war das ganz anders. Funktionen, die sich während des Programmablaufs selbst verändern, waren da ganz normal. Da wurde jeder Taktzyklus genau durchgerechnet. Da wäre es einfach undenkbar gewesen, Zugeständnisse in Richtung Lesbarkeit oder Wartbarkeit des Codes zu machen. Das genaue Gegenteil von OOP heute.

        Das klingt so, als hättest Du nicht nur in Assembler, sondern hardwarenah, technisch oder zeitkritisch programmiert?

        Selbstmodifizierter Code ist ansonsten nämlich der Killer beim Bugfixen und späterem Warten von Code.

        Und bei kaufmännischen Anwendungen, z.B. in COBOL, geht's bereits in Richtung Wartbarkeit und nicht Rausquetschen des letzten Quentchens Performance der aktuellen Prozessorarchitektur. Wenn man mal überlegt, daß Softwaresysteme durchaus mehrere Jahrzehnte (!) genutzt werden...

        Nick

        --
        --------------------------------------------------
        http://www.xilp.eu
        XILP Internet Links People
        Dein persoenliches privates Netzwerk
        aus Freunden, Verwandten, Bekannten und Kollegen.
        --------------------------------------------------
        Hamburg Berlin München
        1. [...]

          Ich ziehe daraus die Erkenntnis, man sollte einen Kompromiß, der Performance und Wartbarkeit unter Einbeziehung der Applikationsanforderungen optimal vereint, schließen.

          Ja, sehe ich auch so, Du mußt halt abwägen, was im konkreten Fall die größten Prioritäten genießt.

          Früher war das ganz anders. Funktionen, die sich während des Programmablaufs selbst verändern, waren da ganz normal. Da wurde jeder Taktzyklus genau durchgerechnet. Da wäre es einfach undenkbar gewesen, Zugeständnisse in Richtung Lesbarkeit oder Wartbarkeit des Codes zu machen. Das genaue Gegenteil von OOP heute.

          Das klingt so, als hättest Du nicht nur in Assembler, sondern hardwarenah, technisch oder zeitkritisch programmiert?

          Halt die alten Sachen. 6502, Motorola ... Damals war Assembler und Maschinensprache ein Synonym. Hardwarenah war das sowieso.

          Selbstmodifizierter Code ist ansonsten nämlich der Killer beim Bugfixen und späterem Warten von Code.

          Ist klar.

          Und bei kaufmännischen Anwendungen, z.B. in COBOL, geht's bereits in Richtung Wartbarkeit und nicht Rausquetschen des letzten Quentchens Performance der aktuellen Prozessorarchitektur. Wenn man mal überlegt, daß Softwaresysteme durchaus mehrere Jahrzehnte (!) genutzt werden...

          Nick

          Performance und Wartbarkeit stehen sich leider oft diametral entgegen. Ein Kompromiß klingt mir (für heutige Verhältnisse) auch am vernüntigsten.

          1. [...]

            Früher war das ganz anders. Funktionen, die sich während des Programmablaufs selbst verändern, waren da ganz normal. Da wurde jeder Taktzyklus genau durchgerechnet. Da wäre es einfach undenkbar gewesen, Zugeständnisse in Richtung Lesbarkeit oder Wartbarkeit des Codes zu machen. Das genaue Gegenteil von OOP heute.

            Das klingt so, als hättest Du nicht nur in Assembler, sondern hardwarenah, technisch oder zeitkritisch programmiert?

            Halt die alten Sachen. 6502, Motorola ... Damals war Assembler und Maschinensprache ein Synonym. Hardwarenah war das sowieso.

            Mhmm... 6502... steckte nicht im C64 ein Verwandter, der 6510?

            Und wenn wir pingelig sind, muesste Maschinensprache 1GL und Assembler 2GL sein... :-)

            Nick

            --
            --------------------------------------------------
            http://www.xilp.eu
            XILP Internet Links People
            Dein persoenliches privates Netzwerk
            aus Freunden, Verwandten, Bekannten und Kollegen.
            --------------------------------------------------
            Hamburg Berlin München
            1. Hi.

              Mhmm... 6502... steckte nicht im C64 ein Verwandter, der 6510?

              Und wenn wir pingelig sind, muesste Maschinensprache 1GL und Assembler 2GL sein... :-)

              Nick

              Schaust Du da: http://de.wikipedia.org/wiki/MOS_Technologies_6502

              Da stehen sogar einige Beispielsourcen:

              LDA #$FF     - füllt das Register „Akkumulator“ mit dem Hex-Zahleninhalt FF (also 255 dez.)
              LDA $C000    - füllt den Akkumulator mit dem Inhalt der absoluten Speicheradresse
                             HEX C000 (also 49152 dez.)

              LDA ($FE),x

              Wenn Du das erste LDA nimmst, wird das meinetwegen von einem Byte $77 (ich weiß das heute nicht mehr) in Maschinencode repräsentiert. Das zweite LDA ist ein ganz anderer Befehl und wird deshalb von einem ganz anderen Byte vertreten (meinetwegen $80). Das dritte LDA genauso. Darüber hinaus gab es noch weitere Varianten (LDA ($60),y, LDA ($60,x) usw.). Assembler war einfach eine Vereinfachung, Maschinencode einzugeben. Hartgesottene haben den Maschinencode direkt in Byteform eingegeben. Eine Unterscheidung in 1GL und 2GL macht da keinen Sinn.

      2. hi,

        Früher war das ganz anders. Funktionen, die sich während des Programmablaufs selbst verändern, waren da ganz normal.

        Das hat aber mit "Wartbarkeit" wenig bis gar nichts gemein.
        Und sowas debuggt sich selbst für einen Kenner ziemlich eklig.

        Da wurde jeder Taktzyklus genau durchgerechnet. Da wäre es einfach undenkbar gewesen, Zugeständnisse in Richtung Lesbarkeit oder Wartbarkeit des Codes zu machen. Das genaue Gegenteil von OOP heute.

        Ganz so sparsam muss heute mit den Ressourcen idR. nicht mehr umgegangen werden - das war "früher", als die "Computer" in etwa die Kapazität hatten, mit der heute programmierbare Taschenrechner verkauft werden (wenn überhaupt), natürlich anders.

        gruß,
        wahsaga

        --
        /voodoo.css:
        #GeorgeWBush { position:absolute; bottom:-6ft; }
        1. *seuftz*

          Ganz so sparsam muss heute mit den Ressourcen idR. nicht mehr umgegangen werden - das war "früher", als die "Computer" in etwa die Kapazität hatten, mit der heute programmierbare Taschenrechner verkauft werden (wenn überhaupt), natürlich anders.

          Ja, ich erschrecke mich immer wieder wenn ich darueber nachdenke das jede 20 Euro Grafikkarte mehr Power hat als mein erster PC. Ueberlegt mal was ihr mit der Power einer heute gaengigen Grafikkarte mit 2 Prozessoren vor 20 Jahren haettet anstellen koennen... In nen Grossrechenzentrum gehen das Ding aufn Tisch knallen und sagen: 'Baut den Krempel ab, das hier ist unser neues Rechenzentrum.' ...

          Allein mein USB MP3 Player laesst doch Hardware aus meinen Anfangszeiten schon alt aussehen.

          ('Mein Rechner hat 2 Megabyte Speicher und eine 20 MB Festplatte!' 'Du Wahnsinniger, das braucht kein Mensch jemals!')

          Sorry, fuer den kleinen Nostalgietrip. :)

  2. Hallo.

    Ich würde mal gerne von anderen wissen, wie sie Programme technisch verwalten. Nehmen wir z. B. eine Website, die aus verschiedenen PHP-Skripts besteht und Einträge in einer DB verwaltet. Vielleicht hat sie eine Spalte in der Datenbank, aus der auf einer Seite ein Optionsfeld (select) erstellt werden soll. In der Datenbank werden die Einträge des Optionsfeldes in einem (My-SQL-)Enum-Feld gespeichert: Auswahl 1, Eintrag 2, stelle3, wie auch immer. Eine Möglichkeit wäre, vor der Ausgabe des Optionsfeldes alle Einträge in der Datenbank abzufragen und dann das Select-Feld dynamisch zu befüllen. Als ehemaligem Assembler-Programmierer geht mir sowas aber gehörig gegen den Strich, wenn ich weiß, die Einträge bleiben immer gleich. Eine andere Möglichkeit wäre dann, die Einträge direkt im Skript zu speichern.

    Mir gefällt schon mal Dein Gedanke zur Optimierung und Wartungsfreundlichkeit.

    Was aber, wenn sich nun doch einmal etwas ändert? Richtig, der Code muß geändert werden. Wird das Optionsfeld oder Einträge daraus an verschiedenen Stellen und in verschiedenen Skripts gebraucht, muß das auch an allen Stellen geändert werden. Das verursacht Arbeit, und es ist nicht unwahrscheinlich, daß irgend etwas vergessen wird. Wären die Optionsfelder dynamisch befüllt worden, hätte eine simple Änderung an der Datenbank gereicht.

    Hier würde ich in Abhängigkeit vom konkreten Fall schauen, was besser ist. Wie wahrscheinlich ist eine Änderung der DB-Struktur? Wenn sich die DB-Struktur ändert, führt das zu weiteren Änderungen, die ohnehin eine Code-Änderung notwendig machen?

    Wie sehen die DB-Zugriffe aus, wie wird die Entwicklung für die Zukunft prognostiziert. Lohnt sich der Performancegewinn im Vergleich zum höheren Codewartungsaufwand?

    Warum man den Code (auch wenn man in PHP die Info aus der DB dupliziert) nur an einer Stelle pflegen sollte, führst Du weiter unten bereits selbst aus.

    Ich weiß, es ist wahrscheinlich eine verdammt dumme Frage, aber ich habe in einer Zeit das Programmieren gelernt, als man z. B.

    Ich halte es eher für eine überdurchschnittliche intelligente Frage. Die meisten Leute werden sich vermutlich über die Langlebigkeit und die damit verbundene wichtige Wartbarkeit ihres Codes keine Gedanken machen. Wenn ich überlege, was ich alles schon an zusammengestückelten, undokumentierten Sourcen gesehen habe... :-O

    Berechnungen für Bewegungen im voraus anstellte und die Ergebnisse in einer Tabelle ablegte, um maximale Programmbeschleunigung zu erreichen. Die Berechnungen während der Programmausführung durchzuführen wäre viel zu langsam gewesen. Heute ist das wohl kaum noch nötig. Leider komme ich da nicht aus meiner Haut. Ich sehe ja,

    Naja, früher waren interpretierte Sprachen/Systeme ja auch eher verpönt, während sie heute wieder im Kommen sind...

    bei einer kleinen Website ist es ziemlich egal, ob ich eine Select-Anfrage mehr oder weniger an die Datenbank schicke, doch mein Gedanke ist immer, was ist, wenn die Site mal größer wird. Das einzige, was man noch tun könnte, unnötige Datenbankabfragen zu vermeiden, ist, Inhalte, die mehrfach verwendet werden oder die womöglich irgendwann geändert werden müssen, in einer inkludierten Datei abzulegen.

    Das sowieso. Also die (in Assembler dann wohl eher zu Fuß zu bauenden) Konstrukte wie Funktionen auf jeden Fall im Sinn der Wiederverwendbarkeit und Wartbarkeit nutzen.

    Also im vorliegenden Beispiel entweder aus der DB die Daten aufbauen oder (Performanceplus) die Informationen aus der DB in PHP duplizieren (um DB-Zugriff zu sparen), beides aber in jedem Fall an nur einer Stelle im Code, nämlich in einer Funktion, die in einer include-Datei ausgelagert ist.

    Deshalb würde ich gern mal wissen, ob Ihr auch solche Überlegungen anstellt, oder aus ökonomischen Gründen auf maximale Wartbarkeit Wert legt, sprich alles in einer Datenbank ablegt, egal ob das zusätzliche, unnötige Datenbankabfragen bedeutet.

    Klar überlege ich... und hin- und wieder gibt's dennoch Quick'n'Dirty-Teile im Source... :-)

    Nick

    --
    --------------------------------------------------
    http://www.xilp.eu
    XILP Internet Links People
    Dein persoenliches privates Netzwerk
    aus Freunden, Verwandten, Bekannten und Kollegen.
    --------------------------------------------------
    Hamburg Berlin München
    1. Hi,

      Wenn ich überlege, was ich alles schon an zusammengestückelten, undokumentierten Sourcen gesehen habe... :-O

      Du bist Polizist und hast meine Festplatte online durchsucht?

      Elendige Schweinerei dieser Bundestrojaner ...

      Gruß, Cybaer

      --
      Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
      1. Hi,

        Wenn ich überlege, was ich alles schon an zusammengestückelten, undokumentierten Sourcen gesehen habe... :-O

        Du bist Polizist und hast meine Festplatte online durchsucht?

        Elendige Schweinerei dieser Bundestrojaner ...

        Keine Panik... dies dient nur der Abwehr von Terroristen... :-O

        Nick ;-)

        --
        --------------------------------------------------
        http://www.xilp.eu
        XILP Internet Links People
        Dein persoenliches privates Netzwerk
        aus Freunden, Verwandten, Bekannten und Kollegen.
        --------------------------------------------------
        Hamburg Berlin München
    2. Hallo.

      Hier würde ich in Abhängigkeit vom konkreten Fall schauen, was besser ist. Wie wahrscheinlich ist eine Änderung der DB-Struktur? Wenn sich die DB-Struktur ändert, führt das zu weiteren Änderungen, die ohnehin eine Code-Änderung notwendig machen?

      Muß ja nicht unbedingt immer die Struktur sein. Kann ja sein, daß sich nur Texte ändern, bspw. Kategorientitel in einem CMS.

      Berechnungen für Bewegungen im voraus anstellte und die Ergebnisse in einer Tabelle ablegte, um maximale Programmbeschleunigung zu erreichen. Die Berechnungen während der Programmausführung durchzuführen wäre viel zu langsam gewesen. Heute ist das wohl kaum noch nötig. Leider komme ich da nicht aus meiner Haut. Ich sehe ja,

      Naja, früher waren interpretierte Sprachen/Systeme ja auch eher verpönt, während sie heute wieder im Kommen sind...

      Ja, so war das.

      bei einer kleinen Website ist es ziemlich egal, ob ich eine Select-Anfrage mehr oder weniger an die Datenbank schicke, doch mein Gedanke ist immer, was ist, wenn die Site mal größer wird. Das einzige, was man noch tun könnte, unnötige Datenbankabfragen zu vermeiden, ist, Inhalte, die mehrfach verwendet werden oder die womöglich irgendwann geändert werden müssen, in einer inkludierten Datei abzulegen.

      Das sowieso. Also die (in Assembler dann wohl eher zu Fuß zu bauenden) Konstrukte wie Funktionen auf jeden Fall im Sinn der Wiederverwendbarkeit und Wartbarkeit nutzen.

      Also im vorliegenden Beispiel entweder aus der DB die Daten aufbauen oder (Performanceplus) die Informationen aus der DB in PHP duplizieren (um DB-Zugriff zu sparen), beides aber in jedem Fall an nur einer Stelle im Code, nämlich in einer Funktion, die in einer include-Datei ausgelagert ist.

      Deshalb würde ich gern mal wissen, ob Ihr auch solche Überlegungen anstellt, oder aus ökonomischen Gründen auf maximale Wartbarkeit Wert legt, sprich alles in einer Datenbank ablegt, egal ob das zusätzliche, unnötige Datenbankabfragen bedeutet.

      Klar überlege ich... und hin- und wieder gibt's dennoch Quick'n'Dirty-Teile im Source... :-)

      Nick

      Gut, das wollte ich wissen, inwieweit Performanceüberlegungen heute noch zum Tragen kommen.

      Gruß
      Thomas

      1. Hallo.

        Hier würde ich in Abhängigkeit vom konkreten Fall schauen, was besser ist. Wie wahrscheinlich ist eine Änderung der DB-Struktur? Wenn sich die DB-Struktur ändert, führt das zu weiteren Änderungen, die ohnehin eine Code-Änderung notwendig machen?

        Muß ja nicht unbedingt immer die Struktur sein. Kann ja sein, daß sich nur Texte ändern, bspw. Kategorientitel in einem CMS.

        Mhmmm, sowas wolltest Du auch in den PHP-Code duplizieren. Ich hatte jetzt eher die zulaessigen Feldinhalte von SET- oder ENUM-Felder (MySQL) im Kopf. Wenn das usergenerierter Content aus der DB ist, wuerde ich hier eher direkt aus der DB lesen... ggf. kann man ja auch einen Cache bauen.

        Nick

        --
        --------------------------------------------------
        http://www.xilp.eu
        XILP Internet Links People
        Dein persoenliches privates Netzwerk
        aus Freunden, Verwandten, Bekannten und Kollegen.
        --------------------------------------------------
        Hamburg Berlin München
        1. Hallo.

          Hier würde ich in Abhängigkeit vom konkreten Fall schauen, was besser ist. Wie wahrscheinlich ist eine Änderung der DB-Struktur? Wenn sich die DB-Struktur ändert, führt das zu weiteren Änderungen, die ohnehin eine Code-Änderung notwendig machen?

          Muß ja nicht unbedingt immer die Struktur sein. Kann ja sein, daß sich nur Texte ändern, bspw. Kategorientitel in einem CMS.

          Mhmmm, sowas wolltest Du auch in den PHP-Code duplizieren. Ich hatte jetzt eher die zulaessigen Feldinhalte von SET- oder ENUM-Felder (MySQL) im Kopf. Wenn das usergenerierter Content aus der DB ist, wuerde ich hier eher direkt aus der DB lesen... ggf. kann man ja auch einen Cache bauen.

          Nick

          War ja auch so gemeint (es geht nicht um usergenerierten Code). Wenn ein Enum-Feld die Inhalte hat Neues, Inland, Ausland, Wetter und der Eintrag "Neues" zu "Neuigkeiten" geändert werden soll, dann hat man ein Problem, wenn in den Skripts an diversen Stellen "Neues" steht.

  3. Speichere deine Möglichkeiten irgendwo zentral in einem Array und lies dies immer wieder aus. Für solche Fälle erstelle ich immer eine Datei in der ich die wenigen Arrays speichere, die ich immer wieder verwende. Gerade ein Optionsfeld lässt sich im Schema

    key => name

    wunderbar festhalten.
    Viele Grüße.

  4. Hallöchen,

    Als ehemaligem Assembler-Programmierer geht mir sowas aber gehörig gegen den Strich, ...

    willkommen im Club. ;-)

    Deshalb würde ich gern mal wissen, ob Ihr auch solche Überlegungen anstellt, ...

    Ja, unbedingt.
    Man mag dagegen halten, dass heutige Hochleistungsrechner CPU-Power im Überfluss haben und daher solche Effizienz-Betrachtungen nicht mehr angebracht sind. Allerdings darf man dann nicht vergessen, dass auf derart leistungsfähigen Rechnern auch oft Hunderte von Prozessen quasi-simultan laufen und somit die Rechenleistung bezogen auf den einzelnen Prozess gar nicht so viel höher liegt als bei den Rechnern, die man vor 20 Jahren hatte.

    oder aus ökonomischen Gründen auf maximale Wartbarkeit Wert legt, sprich alles in einer Datenbank ablegt, egal ob das zusätzliche, unnötige Datenbankabfragen bedeutet.

    Ich löse die grundsätzliche Überlegung mal von der Datenbank-Thematik, weil ich mit Datenbanken bisher wenig bis gar keine Erfahrungen gemacht habe. Allerdings versuche ich grundsätzlich, so viele Parameter wie nur möglich nicht "hartcodiert" im Programmcode zu verankern, sondern stattdessen in Tabellen und Konfigurationsdateien auszulagern.

    Die Algorithmen, die diese Daten dann verarbeiten, optimiere ich allerdings gnadenlos so gut wie eben möglich auf Effizienz. Und ich habe mir im Lauf der Zeit eine so maschinennahe Denkweise angewöhnt, dass kompakter, hochoptimierter Code für mich auch gleichzeitig optimal nachvollziehbar und damit wartbar ist. Zumindest in Assembler oder C (und syntaktisch verwandten Sprachen) ist das der Fall.

    So long,
     Martin

    --
    F: Was sagt die kleine Kerze zur großen Kerze?
    A: Ich gehe heute nacht aus!