anchor.diff:  sets the write synchronization mode for the underlying cache. If neither this nor the `TEMPLATE` parameter is set, then the cache is created with `FULL_SYNC` mode enabled.
   ** `CACHE_GROUP=<group name>` - specifies the link:configuring-caches/cache-groups[group name] the underlying cache belongs to.
   ** `AFFINITY_KEY=<affinity key column name>` - specifies an link:data-modeling/affinity-collocation[affinity key] name which is a column of the `PRIMARY KEY` constraint.
  -** `CACHE_NAME=<custom name of the new cache>` - the name of the underlying cache created by the command.
  +** `CACHE_NAME=<custom name of the new cache>` - the name of the underlying cache created by the command,
  +or the `SQL_{SCHEMA_NAME}_{TABLE}` format will be used if the parameter not specified.
   ** `DATA_REGION=<existing data region name>` - name of the link:memory-configuration/data-regions[data region] where table entries should be stored. By default, Ignite stores all the data in a default region.
   ** `KEY_TYPE=<custom name of the key type>` - sets the name of the custom key type that is used from the key-value APIs in Ignite. The name should correspond to a Java, .NET, or C++ class, or it can be a random one if link:data-modeling/data-modeling#binary-object-format[BinaryObjects] is used instead of a custom class. The number of fields and their types in the custom key type has to correspond to the `PRIMARY KEY`. Refer to the <<Description>> section below for more details.
   ** `VALUE_TYPE=<custom name of the value type of the new cache>` - sets the name of a custom value type that is used from the key-value and other non-SQL APIs in Ignite. The name should correspond to a Java, .NET, or C++ class, or it can be a random one if
  
positive.code: // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  // See the License for the specific language governing permissions and
  // limitations under the License.
  = Data Definition Language (DDL)
  
  :toclevels:
  
negative.code: ** `WRAP_KEY=<true | false>` - this flag controls whether a _single column_ `PRIMARY KEY` should be wrapped in the link:data-modeling/data-modeling#binary-object-format[BinaryObjects] format or not. By default, this flag is set to false. This flag does not have any effect on the `PRIMARY KEY` with multiple columns; it always gets wrapped regardless of the value of the parameter.
  ** `WRAP_VALUE=<true | false>` - this flag controls whether a single column value of a primitive type should be wrapped in the link:data-modeling/data-modeling#binary-object-format[BinaryObjects] format or not. By default, this flag is set to true. This flag does not have any effect on the value with multiple columns; it always gets wrapped regardless of the value of the parameter. Set this parameter to false if you have a single column value and do not plan to add additional columns to the table. Note that once the parameter is set to false, you can't use the `ALTER TABLE ADD COLUMN` command for this specific table.
  
  
  Read more about the database architecture on the link:SQL/sql-introduction[SQL Introduction] page.
  
  
  === Define Primary Key
  
  The example below shows how to create a table with `PRIMARY KEY` specified in the column definition and override cache
  related parameters. A new distributed cache `SQL_PUBLIC_PERSON` will be created (the `SQL_{SCHEMA_NAME}_{TABLE}` format
  is used for naming) which stores objects of the `Person` type that corresponds to a specific Java, .NET, C++ class or BinaryObject.
  
  The distributed cache related parameters are passed in the `WITH` clause of the statement. If the `WITH` clause is omitted,
  then the cache will be created with default parameters set in the `CacheConfiguration` object.
  
  [source,sql]
  ----
  CREATE TABLE Person (
    id int PRIMARY KEY,
    city_id int,
    name varchar,
    age int,
    company varchar
  ) WITH "atomicity=transactional,cachegroup=somegroup";
  ----
  
  
  === Use non-SQL API
  
  If you wish to access the table data by the key-value or other non-SQL API, then you might be need to set the `CACHE_NAME` and
  `KEY_TYPE`, `VALUE_TYPE` parameters corresponding to your business model objects to make non-SQL APIs usage more convenient.
  
  - Use the `CACHE_NAME` parameter to override the default name with the following format `SQL_{SCHEMA_NAME}_{TABLE}`.
  - By default, the command also creates two new binary types - for the key and value respectively. Ignite in turn generates
  the names of the types randomly including a UUID string which complicates the usage of these types from a non-SQL API.
  
  The example below shows how to create a table `PERSON` and the underlying cache with the same name. The cache will store objects
  of the `Person` type with explicitly defined the key type `PersonKey` and value type `PersonValue`. The `PRIMARY KEY` columns will
  be used as the object's key, the rest of the columns will belong to the value.
  
  [source,sql]
  ----
  