repo_zf1/documentation/manual/de/ref/performance-database.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 15099 -->
<!-- Reviewed: no -->
<sect1 id="performance.database">
    <title>Zend_Db Performance</title>

    <para>
        <classname>Zend_Db</classname> ist ein Datenbank Abstraktion Layer und ist dazu gedacht eine
        gemeinsame API für SQL Operationen zu bieten. <classname>Zend_Db_Table</classname> ist ein
        Table Data Bateway, dazu gedacht übliche Tabellen-artige Datenbank Operationen zu
        abstrahieren. Wegen Ihrer abstrakten Natur und der "Magie" die Sie versteckt haben um Ihre
        Operationen durchführen zu können, können Sie manchmal auch zu Geschwindigkeitsnachteilen
        führen.
    </para>

    <sect2 id="performance.database.tableMetadata">
        <title>
            Wie kann ich den Overhead reduzieren der von Zend_Db_Table eingeführt wird um die
            Metadaten der Tabelle zu erhalten?
        </title>

        <para>
            Um die Verwendung so einfach wie möglich zu halten, und auch sich konstant ändernde
            Schemata wärend der Entwicklung zu unterstützen, macht
            <classname>Zend_Db_Table</classname> einiges an Magie unter seinem Hut: bei der ersten
            Verwendung, holt es das Tabellenschema und speichert es im Objekt. Diese Operation ist
            normalerweise sehr teuer, unabhängig von der Datenbank -- das zu einer Schwachstelle in
            der Produktion führen kann.
        </para>

        <para>
            Glücklicherweise gibt es Techniken um die Situation zu verbessern.
        </para>

        <sect3 id="performance.database.tableMetadata.cache">
            <title>Den Metadaten Cache verwenden</title>

            <para>
                <classname>Zend_Db_Table</classname> kann optional <classname>Zend_Cache</classname>
                verwenden um die Metadaten der Tabelle zu cachen. Dieser ist typischerweise
                schneller im Zugriff und nicht so teuer wie das holen der Metadaten von der Tabelle
                selbst.
            </para>

            <para>
                Die Dokumentation von <link
                    linkend="zend.db.table.metadata.caching"><classname>Zend_Db_Table</classname>
                    enthält Informationen über das Cachen der Metadaten</link>.
            </para>
        </sect3>

        <sect3 id="performance.database.tableMetadata.hardcoding">
            <title>Die Metadaten in der Tabellendefinition fix codieren</title>

            <para>
                Mit 1.7.0, bietet <classname>Zend_Db_Table</classname> auch
                <link linkend="zend.db.table.metadata.caching.hardcoding">Unterstützung für fix
                kodierte Metadaten in der Tabellen Definition</link>. Das ist ein schwierigerer
                Verwendungsfall, und sollte nur dann verwendet werden wenn man weiß das sich das
                Tabellenschema nicht ändern wird, oder das man fähig ist die Definition immer
                up-to-date zu halten.
            </para>
        </sect3>
    </sect2>

    <sect2 id="performance.database.select">
        <title>
            SQL die mit Zend_Db_Select erzeugt wurde greift nicht auf die Indezes zu; wie kann man
            das besser machen?
        </title>

        <para>
            <classname>Zend_Db_Select</classname> ist relativ gut in seinem Job. Trotzdem kann es,
            wenn man komplexe Abfragen benötigt die Joins oder Unterabfragen enthalten, sehr naiv
            sein.
        </para>

        <sect3 id="performance.database.select.writeyourown">
            <title>Selbst getuntes SQL schreiben</title>

            <para>
                Die einzige echte Antwort ist es eigenes SQL zu schreiben;
                <classname>Zend_Db</classname> erfordert nicht die Verwendung von
                <classname>Zend_Db_Select</classname>, als ist die Verwendung von eigenen, getunten
                SQL Select Statements, eine perfekte und legitime Anwendung.
            </para>
            <para>
                Lasse <code>EXPLAIN</code> auf den Abfragen laufen, und teste eine Vielzahl von
                Möglichkeiten bis man die eigenen Indezes auf dem besten und performantesten Weg
                trifft -- und dann sollte dieses SQL als Klasseneigenschaft oder Konstante fix
                kodiert werden.
            </para>

            <para>
                Wenn das SQL variable Argumente benötigt, können Platzhalter im SQL verwendet
                werden und in einer Kombination von <code>vsprintf</code> und
                <code>array_walk</code> verwendet werden um Werte in das SQL zu injizieren:
            </para>

            <programlisting role="php"><![CDATA[
// $adapter ist der DB Adapter. In Zend_Db_Table ist es durch
// Verwendung von $this->getAdapter() zu empfangen.
$sql = vsprintf(
    self::SELECT_FOO,
    array_walk($values, array($adapter, 'quoteInto'))
);
]]></programlisting>
        </sect3>
    </sect2>
</sect1>
<!--
vim:se ts=4 sw=4 et:
-->