List:Commits« Previous MessageNext Message »
From:john.russell Date:November 9 2010 6:17am
Subject:svn commit - mysqldoc@docsrva: r23615 - trunk/refman-5.5
View as plain text  
Author: jrussell
Date: 2010-11-09 07:17:59 +0100 (Tue, 09 Nov 2010)
New Revision: 23615

Log:
Update some of the language in the Optimization intro sections, prior to moving / folding them.


Modified:
   trunk/refman-5.5/optimization.xml


Modified: trunk/refman-5.5/optimization.xml
===================================================================
--- trunk/refman-5.5/optimization.xml	2010-11-08 19:10:02 UTC (rev 23614)
+++ trunk/refman-5.5/optimization.xml	2010-11-09 06:17:59 UTC (rev 23615)
Changed blocks: 2, Lines Added: 27, Lines Deleted: 85; 6779 bytes

@@ -272,7 +272,7 @@
 
     <section id="portability">
 
-      <title>Designing Applications for Portability</title>
+      <title>Optimizing Portable Applications</title>
 
       <indexterm>
         <primary>portability</primary>

@@ -289,105 +289,47 @@
 
       <para>
         Because all SQL servers implement different parts of standard
-        SQL, it takes work to write portable database applications. It
-        is very easy to achieve portability for very simple selects and
-        inserts, but becomes more difficult the more capabilities you
-        require. If you want an application that is fast with many
-        database systems, it becomes even more difficult.
+        SQL, it takes work to write portable database applications that
+        go beyond simple selects and inserts.
       </para>
 
       <para>
-        All database systems have some weak points. That is, they have
-        different design compromises that lead to different behavior.
+        To use MySQL SQL extensions in a portable program, you can wrap
+        MySQL-specific keywords in a statement within <literal>/*!
+        */</literal> comment delimiters. Other SQL servers ignore the
+        commented keywords. For information about writing comments, see
+        <xref linkend="comments"/>.
       </para>
 
       <para>
-        To make a complex application portable, you need to determine
-        which SQL servers it must work with, and then determine what
-        features those servers support. You can use the MySQL
-        <command>crash-me</command> program to find functions, types,
-        and limits that you can use with a selection of database
-        servers. <command>crash-me</command> does not check for every
-        possible feature, but it is still reasonably comprehensive,
-        performing about 450 tests. An example of the type of
-        information <command>crash-me</command> can provide is that you
-        should not use column names that are longer than 18 characters
-        if you want to be able to use Informix or DB2.
+        To make your application truly database independent, define an
+        easily extendable interface through which you manipulate your
+        data. For example, Perl::DBI provides database-independent
+        access methods. Expert programmers might write a C++ class-based
+        database interface.
       </para>
 
       <para>
+        The MySQL <command>crash-me</command> program identifies
+        functions, types, and limits that you can use with a
+        selection of database servers. Although
+        <command>crash-me</command> does not check for every possible
+        feature, it is still reasonably comprehensive, performing about
+        450 tests. For example, <command>crash-me</command> warns not to
+        use column names that are longer than 18 characters for
+        cross-compatibility with Informix and DB2.
+      </para>
+
+      <para>
         The <command>crash-me</command> program and the MySQL benchmarks
         are all very database independent. By taking a look at how they
         are written, you can get a feeling for what you must do to make
-        your own applications database independent. The programs can be
-        found in the <filename>sql-bench</filename> directory of MySQL
+        your own applications database independent. The programs are
+        in the <filename>sql-bench</filename> directory of MySQL
         source distributions. They are written in Perl and use the DBI
-        database interface. Use of DBI in itself solves part of the
-        portability problem because it provides database-independent
-        access methods. See <xref linkend="mysql-benchmarks"/>.
+        database interface. See <xref linkend="mysql-benchmarks"/>.
       </para>
 
-      <para>
-        If you strive for database independence, you need to get a good
-        feeling for each SQL server's bottlenecks. For example, MySQL is
-        very fast in retrieving and updating rows for
-        <literal>MyISAM</literal> tables, but has a problem in mixing
-        slow readers and writers on the same table. Transactional
-        database systems in general are not very good at generating
-        summary tables from log tables, because in this case row locking
-        is almost useless.
-      </para>
-
-      <para>
-        To make your application <emphasis>really</emphasis> database
-        independent, define an easily extendable interface through which
-        you manipulate your data. For example, C++ is available on most
-        systems, so it makes sense to use a C++ class-based interface to
-        the databases.
-      </para>
-
-      <para>
-        If you use some feature that is specific to a given database
-        system (such as the <literal role="stmt">REPLACE</literal>
-        statement, which is specific to MySQL), implement the same
-        feature for other SQL servers by coding an alternative method.
-        Although the alternative might be slower, it enables the other
-        servers to perform the same tasks.
-      </para>
-
-      <para>
-        With MySQL, you can use the <literal>/*! */</literal> syntax to
-        add MySQL-specific keywords to a statement. The code inside
-        <literal>/* */</literal> is treated as a comment (and ignored)
-        by most other SQL servers. For information about writing
-        comments, see <xref linkend="comments"/>.
-      </para>
-
-      <para>
-        If high performance is more important than exactness, as for
-        some Web applications, it is possible to create an application
-        layer that caches all results to give you even higher
-        performance. By letting old results expire after a while, you
-        can keep the cache reasonably fresh. This provides a method to
-        handle high load spikes, in which case you can dynamically
-        increase the cache size and set the expiration timeout higher
-        until things get back to normal.
-      </para>
-
-      <para>
-        In this case, the table creation information should contain
-        information about the initial cache size and how often the table
-        should normally be refreshed.
-      </para>
-
-      <para>
-        An attractive alternative to implementing an application cache
-        is to use the MySQL query cache. By enabling the query cache,
-        the server handles the details of determining whether a query
-        result can be reused. This simplifies your application. See
-        <xref linkend="query-cache"/>.
-      </para>
-
     </section>
 
   </section>


Thread
svn commit - mysqldoc@docsrva: r23615 - trunk/refman-5.5john.russell9 Nov