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

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

    <para>
        <classname>Zend_Db</classname> est une couche d'abstraction pour les bases de données,
        et a pour but de fournir une <acronym>API</acronym> commune pour les opérations
        <acronym>SQL</acronym>. <classname>Zend_Db_Table</classname> est un Table Data Gateway,
        dont le but est d'abstraire les opérations communes de niveau table. A cause de cette
        nature abstraite et de la manière suivant laquelle sont réalisées ces opérations, ces
        composants peuvent introduire des pertes de performances.
    </para>

    <sect2 id="performance.database.tableMetadata">
        <title>
            Comment réduire la surcharge introduite par Zend_Db_Table lors de la récupération
            des métadonnées de table&#160;?
        </title>

        <para>
            Dans le but de maintenir une utilisation la plus simple possible, et aussi de
            supporter un changement de schéma permanent au cours du développement,
            <classname>Zend_Db_Table</classname> réalise une série d'action en arrière-plan&#160;
            à la première utilisation, il analyse le schéma de la table et le stocke dans les
            propriétés de l'objet. Cette opération est typiquement coûteuse, indépendamment de la
            base de données -- ce qui peut contribuer à des goulots en production.
        </para>

        <para>
            Toutefois, ils existent des techniques permettant d'améliorer ceci.
        </para>

        <sect3 id="performance.database.tableMetadata.cache">
            <title>Utiliser le cache des métadonnées</title>

            <para>
                <classname>Zend_Db_Table</classname> peut optionnellement utiliser
                <classname>Zend_Cache</classname> pour mettre en cahce les métadonnées de la
                table. C'est typiquement plus rapide d'accès et moins coûteux que d'accéder à
                ces métadonnées directement dans la base de données.
            </para>

            <para>
                La documentation de <link
                    linkend="zend.db.table.metadata.caching"><classname>Zend_Db_Table</classname></link>
                inclue des informations concernant la mise en cache des métadonnées.
            </para>
        </sect3>

        <sect3 id="performance.database.tableMetadata.hardcoding">
            <title>Mettre en dur les métadonnées dans votre définition de table</title>

            <para>
                A partir de la version 1.7.0, <classname>Zend_Db_Table</classname> fournit aussi
                <link linkend="zend.db.table.metadata.caching.hardcoding">le support permettant
                de stocker les métadonnées en dur dans la définition de la table</link>. Ceci
                est un cas d'utilisation très avancé, et ne devrait être utilisé que lorsque
                vous êtes que votre schéma de base de données évolue rarement, ou que vous êtes
                certain de pouvoir maintenir à jour ces définitions.
            </para>
        </sect3>
    </sect2>

    <sect2 id="performance.database.select">
        <title>
            Le SQL généré avec Zend_Db_Select n'utilise pas mes index&#160;; comment améliorer
            ceci&#160;?
        </title>

        <para>
            <classname>Zend_Db_Select</classname> est plutôt bon dans son trvail. Cependant si
            vous avez des requêtes complexes requiérant des jointures ou des sous-sélections,
            il est souvent assez naïf.
        </para>

        <sect3 id="performance.database.select.writeyourown">
            <title>Ecrire votre SQL amélioré</title>
            <para>
                La seule véritable réponse est d'écrire vous même votre propre
                <acronym>SQL</acronym>&#160;; <classname>Zend_Db</classname> n'oblige pas
                l'utilisation de <classname>Zend_Db_Select</classname>, donc fournir votre
                propre instruction <acronym>SQL</acronym> de sélection est une approche
                parfaitement légitime.
            </para>

            <para>
                Effectuez un <constant>EXPLAIN</constant> sur vos requêtes, et testez plusieurs
                approches jusqu'à obtenir un indice le plus performant, ensuite écrivez en dur
                votre <acronym>SQL</acronym> en tant que propriété de la classe ou comme
                constante.
            </para>

            <para>
                Si votre <acronym>SQL</acronym> requiert des arguments variables, fournissez des
                emplacements réservés dans votre <acronym>SQL</acronym>, et utilisez une
                combinaison de <methodname>vsprintf()</methodname> et
                <methodname>array_map()</methodname> pour injecter les valeurs dans votre
                <acronym>SQL</acronym>&#160;:
            </para>

            <programlisting language="php"><![CDATA[
// $adapter est l'adaptateur de base de données. Dans Zend_Db_Table,
// vous le récupérez en appelant $this->getAdapter().
$sql = vsprintf(
    self::SELECT_FOO,
    array_map(array($adapter, 'quoteInto'), $values)
);
]]></programlisting>
        </sect3>
    </sect2>
</sect1>