List:Commits« Previous MessageNext Message »
From:jon Date:June 25 2006 12:05pm
Subject:svn commit - mysqldoc@docsrva: r2496 - trunk/ndbapi
View as plain text  
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/ndbapijon25 Jun