[DOCUMENTATION] French:

 - add new translation

git-svn-id: http://framework.zend.com/svn/framework/standard/trunk@18859 44c647ce-9c0f-0410-b52a-842ac1e357ba

documentation/manual/fr/module_specs/Zend_Test-PHPUnit-Db-Adapter.xml

@@ -73,8 +73,7 @@ $stmt = $adapter->query("SELECT * FROM bugs");
 $qp = $adapter->getProfiler()->getLastQueryProfile();
 
 echo $qp->getQuerY(); // SELECT * FROM bugs
-]]>
-    </programlisting>
+]]></programlisting>
 
     <para>
         L'adaptateur de test ne vérifie jamais si la requête spécifiée est réellement de type SELECT, DELETE,

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

@@ -0,0 +1,113 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- EN-Revision: 16565 -->
+<!-- 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_walk()</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_walk($values, array($adapter, 'quoteInto'))
+);
+]]></programlisting>
+        </sect3>
+    </sect2>
+</sect1>