[translation]ja:performance_guide:database

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

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

@@ -5,13 +5,12 @@
     <title>Zend_Dbパフォーマンス</title>
 
     <para>
-        <classname>Zend_Db</classname>はデータベースを抽象化するレイヤーで、SQL操作のための
-        共通APIを提供する意図があります。
-        <classname>Zend_Db_Table</classname>はテーブルデータのゲートウェィで、抽象的な
-        共通のテーブルレベルでのデータベース操作を提供する意図があります。
-        Due to their abstract nature and the "magic" they do under
-        the hood to perform their operations, they can sometimes introduce
-        performance overhead.
+        <classname>Zend_Db</classname>はデータベースを抽象化するレイヤーで、
+        SQL操作のための共通APIを提供する意図があります。
+        <classname>Zend_Db_Table</classname>はテーブルデータのゲートウェイで、
+        テーブルレベルでの抽象的な共通のデータベース操作を提供する意図があります。
+        それらの抽象的な性質とそれらの操作を行なうために隠れて行なうマジックのせいで、
+        しばしばパフォーマンスのオーバーヘッドをもたらします。
     </para>
 
     <sect2 id="performance.database.tableMetadata">
@@ -19,16 +18,16 @@
         オーバーヘッドをどのようにしたら減らせますか？</title>
 
         <para>
-            In order to keep usage as simple as possible, and also to support
-            constantly changing schemas during development,
-            <classname>Zend_Db_Table</classname> does some magic under the hood: on
-            first use, it fetches the table schema and stores it within object
-            members. This operation is typically expensive, regardless of the
-            database -- which can contribute to bottlenecks in production.
+            できる限り使い方を簡単に保つために、
+            また、開発最中にスキーマの変更を絶えずサポートするためにも、
+            <classname>Zend_Db_Table</classname>はあるマジックを隠れて行ないます:
+            使い始める時にテーブルのスキーマを読み込んでオブジェクトのメンバに保存します。
+            この操作は一般的に高くつき、データベースを気にかけません。
+            それは製品のボトルネックに寄与します。
         </para>
 
         <para>
-            Fortunately, there are techniques for improving the situation.
+            幸運なことにその状況を改善する技術があります。
         </para>
 
         <sect3 id="performance.database.tableMetadata.cache">
@@ -37,14 +36,13 @@
             <para>
                 <classname>Zend_Db_Table</classname>ではテーブルのメタデータをキャッシュする
                 ために<classname>Zend_Cache</classname>を任意で利用できます。
-                This is
-                typically faster to access and less expensive than fetching the
-                metadata from the database itself.
+                これはデータベース自身からメタデータを読み込むよりも、
+                一般的に早くアクセスでき、高くつきません。
             </para>
 
             <para>
                 <link linkend="zend.db.table.metadata.caching"><classname>Zend_Db_Table</classname>
-                のドキュメントにメタデータをキャッシュすることについての情報があります。</link>
+                のドキュメントにメタデータをキャッシュすることについて情報があります。</link>
             </para>
         </sect3>
 
@@ -52,12 +50,11 @@
             <title>テーブル定義でメタデータをハードコーディングする</title>
 
             <para>
-                As of 1.7.0, <classname>Zend_Db_Table</classname> also provides <link
-                    linkend="zend.db.table.metadata.caching.hardcoding">support
-                for hardcoding metadata in the table definition</link>. This is
-                an advanced use case, and should only be used when you know the
-                table schema is unlikely to change, or that you're able to keep
-                the definitions up-to-date.
+                1.7.0では、<classname>Zend_Db_Table</classname>は<link
+                    linkend="zend.db.table.metadata.caching.hardcoding">テーブルの定義でメタデータをハードコーディングすることをサポート</link>
+                することもします。
+                これは高度な使用例であり、テーブルのスキーマが変更されそうにないと知っているか、
+                または定義を最新状態に保ち続けられる時のみ利用されるべきでしょう。
             </para>
         </sect3>
     </sect2>
@@ -67,9 +64,9 @@
         どのようにしたらより良く出来ますか？</title>
 
         <para>
-            <classname>Zend_Db_Select</classname> is relatively good at its job. However,
-            if you are performing complex queries requiring joins or
-            sub-selects, it can often be fairly naive.
+            <classname>Zend_Db_Select</classname>は比較的その仕事が得意です。
+            ただし、結合や副選択を必要とする複雑なクエリを実行するなら、
+            しばしばかなりの素人になりえます。
         </para>
 
         <sect3 id="performance.database.select.writeyourown">
@@ -78,25 +75,25 @@
             <para>
                 現実的な唯一の答えは自分でSQLを書くことです;
                 自分で用意できるなら、<classname>Zend_Db</classname>で必ず
-                <classname>Zend_Db_Select</classname>を使わずに、調整されたselect文の
-                SQLが完璧で筋の通った道筋です。
+                <classname>Zend_Db_Select</classname>を使わずに、SQLのselect文を調整する
+                ことがもっとも完璧に筋の通った道です。
             </para>
             <para>
-                Run <code>EXPLAIN</code> on your queries, and test a variety of
-                approaches until you can reliably hit your indices in the most
-                performant way -- and then hardcode the SQL as a class property
-                or constant.
+                <code>EXPLAIN</code>をクエリに対して実行して、
+                最もパフォーマンスのあるインデックスを本当に当てるまで、
+                さまざまな取り組みをテストしてください。
+                それからクラスのプロパティーや定数としてSQLをハードコーディングしてください。
             </para>
 
             <para>
-                If the SQL requires variable arguments, provide placeholders in
-                the SQL, and utilize a combination of <code>vsprintf</code> and
-                <code>array_walk</code> to inject the values into the SQL:
+                もしSQLが変数の引数を必要とする場合、
+                SQLにプレースホルダーを用意してください。
+                そして、SQLに値を挿入するために<code>vsprintf</code>と<code>array_walk</code>の組み合わせを利用してください。
             </para>
 
             <programlisting role="php"><![CDATA[
-// $adapter is the DB adapter. In Zend_Db_Table, retrieve
-// it using $this->getAdapter().
+// $adapter はDBアダプターです。Zend_Db_Tableでは、
+// $this->getAdapter() を使ってそれを参照します
 $sql = vsprintf(
     self::SELECT_FOO,
     array_walk($values, array($adapter, 'quoteInto'))