Author: jstephens
Date: 2006-06-25 12:04:59 +0200 (Sun, 25 Jun 2006)
New Revision: 2496
Log:
Part of MySQL datatypes -> NDB datatypes section
Modified:
trunk/ndbapi/tips-tricks-problems.xml
Modified: trunk/ndbapi/tips-tricks-problems.xml
===================================================================
--- trunk/ndbapi/tips-tricks-problems.xml 2006-06-25 07:15:05 UTC (rev 2495)
+++ trunk/ndbapi/tips-tricks-problems.xml 2006-06-25 10:04:59 UTC (rev 2496)
@@ -561,21 +561,168 @@
</section>
-<!--
- <section id="getting-started-data-dictionary">
- <title></title>
<section id="getting-started-mysql-ndb-mapping">
- <title></title>
+ <title>Mapping MySQL Database Object Names and Types to
<literal>NDB</literal></title>
+
+ <abstract>
+ <para>
+ This section discusses NDB naming and other conventions
+ with regard to database objects.
+ </para>
+ </abstract>
+
+ <formalpara>
+ <title>Databases and Schemas</title>
+ <para>
+ Databases and schemas are not represented by objects as
+ such in the <literal>NDB</literal> API. Instead, they are
+ modeled as attributes of <literal>Table</literal> and
+ <literal>Index</literal> objects. The value of the
+ <literal>database</literal> attribute of one of these
+ objects is always the same as the name of the MySQL
+ database to which the table or index belongs. The value of
+ the <literal>schema</literal> attribute of a
+ <literal>Table</literal> or
<literal>Index</literal>
+ object is always '<literal>def</literal>' (for
+ <quote>default</quote>).
+ </para>
+ </formalpara>
+
+ <formalpara>
+ <title>Tables</title>
+ <para>
+ MySQL table names are directly mapped to
+ <literal>NDB</literal> table names without modification.
+ Table names starting with '<literal>NDB$</literal>'
+ are reserved for internal use>, as is the
+ <literal>SYSTAB_0</literal> table in the
+ <literal>sys</literal> database.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+ <title>Indexes</title>
+ <para>There are two different type of NDB indexes:
+ <itemizedlist>
+ <listitem>
+ <para>
+ <firstterm>Hash indexes</firstterm> are unique, but
+ not ordered.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <firstterm>B-tree indexes</firstterm> are ordered,
+ but allow duplicate values.
+ </para>
+ </listitem>
+ </itemizedlist>
+ Names of unique indexes and primary keys are handled as
+ follows:
+ <itemizedlist>
+ <listitem>
+ <para>
+ For a MySQL <literal>UNIQUE</literal> index, both a
+ BTree and a hash index are created. The B-tree
+ index uses the MySQL name for the index; the name
+ for the hash index is generated by appending
+ '<literal>$unique</literal>' to the index name.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ For a MySQL primary key only a B-tree index is
+ created. This index is given the name
+ <literal>PRIMARY</literal>. There is no extra hash;
+ however, the uniquneess of the primary key is
+ guaranteed by making the MySQL key the internal
+ primary key of the <literal>NDB</literal> table.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </formalpara>
+
+ <formalpara>
+ <title>Column Names and Values</title>
+ <para>
+ <literal>NDB</literal> column names are the same as their MySQL
names.
+ </para>
+ </formalpara>
+
+ <formalpara>
+ <title>Datatypes</title>
+ <para>
+ MySQL datatypes are stored in <literal>NDB</literal>
+ columns as follows:
+ <itemizedlist>
+ <listitem>
+ <para>
+ The MySQL <literal>TINYINT</literal>,
+ <literal>SMALLINT</literal>,
<literal>INT</literal>,
+ and <literal>BIGINT</literal> datatypes map to
+ <literal>NDB</literal> types having the same names
+ and storage requirements as their MySQL
+ counterparts.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The MySQL <literal>FLOAT</literal> and
+ <literal>DOUBLE</literal> datatypes are mapped to
+ <literal>NDB</literal> types having the same names
+ and storage requirements.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The storage space required for a MySQL
+ <literal>CHAR</literal> column is determined by the
+ maximum number of characters and the column's
+ character set. For most (but not all) character
+ sets, each character takes one byte of storage. When
+ using UTF-8, each character requires three bytes.
+ You can find the number of bytes needed per
+ character in a given character set by checking the
+ <literal>Maxlen</literal> column in the output of
+ <literal>SHOW CHARACTER SET</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ In MySQL 5.1, the storage requirements for a
+ <literal>VARCHAR</literal> column depend on whether
+ the column is stored in memory or on disk:
+ <itemizedlist>
+ <listitem>
+ <para>
+ For in-memory columns,
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ For Disk Data columns,
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </formalpara>
+
+
</section>
- <section id="getting-started-dictionary-lookups">
- <title></title>
- </section>
- </section>
--->
<!--
<section id="getting-started-reading-data">
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r2496 - trunk/ndbapi | jon | 25 Jun |