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.5 | john.russell | 9 Nov |
