Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
dev:sql:statements:create_database:home [2010/07/02 20:27]
els
dev:sql:statements:create_database:home [2016/06/28 22:38] (current)
Line 1: Line 1:
 {{page>:​top_add&​nofooter&​noeditbtn}} {{page>:​top_add&​nofooter&​noeditbtn}}
-<​html><​div align="​center"><​span style="​color:red">​DRAFT</​span></​div></​html>​+^ Omnidex SQL Quicklinks ^^^^^ 
 +|[[dev:sql:​overview | Overview ]] | [[dev:​sql:​statements:​home | Statements ]] | [[ dev:​sql:​functions:​home | Functions ]] | [[ dev:​sql:​examples:​home | Examples ]] | [[dev:​sql:​home | Quick Reference ]] |
 ====== Omnidex SQL: CREATE DATABASE ====== ====== Omnidex SQL: CREATE DATABASE ======
-{{page>:​sql_bar&​nofooter&​noeditbtn}}+
 ===== Description ===== ===== Description =====
 The CREATE DATABASE statement declares a database in an Omnidex Environment File.  Once one or more databases and their respective tables have been declared in an environment,​ they can be indexed and retrieved using SQL statements. The CREATE DATABASE statement declares a database in an Omnidex Environment File.  Once one or more databases and their respective tables have been declared in an environment,​ they can be indexed and retrieved using SQL statements.
  
-An Omnidex database can point to an underlying Oracle, SQL Server or MySQL database, or any other database that can be accessed using ODBC.  An Omnidex database can also point to a collection of raw data files that combine together to form a database. ​ These databases are accessible using the Omnidex SQL engines, available through ​standard interfaces like ODBC and JDBC.  ​+An Omnidex database can point to an underlying Oracle, SQL Server or MySQL database, or any other database that can be accessed using ODBC.  An Omnidex database can also point to a collection of raw data files that combine together to form a database. ​ These databases are accessible using the Omnidex SQL engines, available through ODBC and JDBC interfaces.  ​
  
-The CREATE DATABASE statement records information about the underlying database in the Omnidex Environment ​Catalog, but it does not actually create an underlying relational database. ​ The physical database should be created using the relational database'​s tools. ​ In the case of raw data files, the files are usually received from a data provider, and application or an ETL tool.  The CREATE DATABASE statement simply stores meta-data about the database in the Omnidex Environment File.+The CREATE DATABASE statement records information about the underlying database in the Omnidex Environment ​File, but it does not actually create an underlying relational database. ​ The physical database should be created using the relational database'​s tools. ​ In the case of raw data files, the files are usually received from a data provider, and application or an ETL tool.  The CREATE DATABASE statement simply stores meta-data about the database in the Omnidex Environment File.
  
 Omnidex allows multiple databases to be declared in an environment. ​ When an application connects to an Omnidex Environment File, then SQL statements can be issued that access all of the databases in the environment. ​ Databases can be of different types as well, and this allows applications to issue SELECT statements that join tables from different database types, including raw data files. Omnidex allows multiple databases to be declared in an environment. ​ When an application connects to an Omnidex Environment File, then SQL statements can be issued that access all of the databases in the environment. ​ Databases can be of different types as well, and this allows applications to issue SELECT statements that join tables from different database types, including raw data files.
Line 16: Line 17:
 <​code>​ <​code>​
   CREATE DATABASE database_name   CREATE DATABASE database_name
-      [NODE node_name+      [NODE grid_node
-          TYPE type +          TYPE database_type 
-          ​[VERSION “version”] +              [SUBTYPE ​odbc_subtype]
-          ​[SUBTYPE ​subtype]+
           [INDEX_DIRECTORY “directory”]           [INDEX_DIRECTORY “directory”]
-          [PHYSICAL ​physical”] +          [VERSION ​rdbms_version”] 
-          [USER user”][PASSWORD “password”]+          [PHYSICAL ​rdbms_string”] 
 +          ​[USER “rdbms_user” ​PASSWORD “user_password”]
           [INDEX_MAINTENANCE index_maintenance_type]           [INDEX_MAINTENANCE index_maintenance_type]
-      IN “filename”                             ​/* must be after all previous clauses ​*/ +      IN “environment_filespec”                        /* must be after all previous clauses */
-      [WITH options] ​                           /* if used, must be the very last clause  ​*/+
 </​code>​ </​code>​
  
 ===== Discussion ===== ===== Discussion =====
-==== DATABASE database_name ​==== +=== DATABASE database_name === 
-The //​database_name//​ uniquely identifies the database within this environment. ​ It may be up to 32 characters long, and can contain letters, digits and the following special characters: ! @ # $ % ^ _.  It must begin with a letter and is case-insensitive. ​ The //​database_name//​ must  be unique within the environment.  ​+The //​database_name//​ uniquely identifies the database within this environment. ​ It may be up to 32 characters long, and can contain letters, digits and the following special characters: ! @ # $ % ^ _.  It must begin with a letter and is case-insensitive. ​ The //​database_name//​ must  be unique within the environment.  ​If //​database_name//​ is a SQL reserved word, enclose it in double quotation marks.
  
  
-//​Database_name//​ is used to qualify table and index names when the same table or index name occurs more than once within an Omnidex Environment.+//​Database_name//​ is used to qualify table and index names when the same table or index name occurs more than once within an Omnidex Environment ​File.
  
 //​Database_name//​ is also used as the prefix for index files located in the //​index_directory//​ as specified in the INDEX_DIRECTORY setting. //​Database_name//​ is also used as the prefix for index files located in the //​index_directory//​ as specified in the INDEX_DIRECTORY setting.
Line 44: Line 44:
 SALES0001, SALES0002, SALES0003, SALES.XML SALES0001, SALES0002, SALES0003, SALES.XML
 </​code>​ </​code>​
-==== TYPE type ==== + 
-The TYPE clause specifies the type of database being declared. ​ The //type// is always ​required.+=== NODE grid_node ​=== 
 + 
 +The optional NODE clause is used to configure an Omnidex Grid.  Nodes that were previously declared in the CREATE ENVIRONMENT statement can be referenced here, and the database configuration can be named for each node.  The NODE clause is only required for databases within an Omnidex Grid that are partitioned and distributed across multiple nodes. ​ If not using an Omnidex Grid, the NODE clause can be skipped and the underlying configuration can be specified for the entire database. ​  
 + 
 +For simple environments,​ the database configuration does not require NODE clauses:  
 + 
 +<​code>​ 
 +create environment ​           
 + ​in ​                         "​list.xml";​ 
 + 
 +create database ​             "​LIST"​ 
 + type                        ​FILE 
 + ​index_directory ​            "​idx"​ 
 + ​in ​                         "​list.xml";​ 
 +</​code>​ 
 + 
 +For Omnidex Grid environments,​ the database requires NODE clauses: 
 + 
 +<​code>​ 
 +create environment ​           
 + ​max_threads ​                2 
 + ​node ​                       "​GRID01"​ partitioned 
 + ​node ​                       "​GRID02"​ partitioned 
 + ​node ​                       "​GRID03"​ partitioned 
 + ​node ​                       "​GRID04"​ partitioned 
 + ​node ​                       "​GRID05"​ unpartitioned 
 + ​in ​                         "​list.xml";​ 
 + 
 +create database ​             "​LIST"​ 
 + node "​GRID01"​ 
 +  type                       ​FILE 
 +  index_directory ​           "​idx\grid01"​ 
 + node "​GRID02"​ 
 +  type                       ​FILE 
 +  index_directory ​           "​idx\grid02"​ 
 + node "​GRID03"​ 
 +  type                       ​FILE 
 +  index_directory ​           "​idx\grid03"​ 
 + node "​GRID04"​ 
 +  type                       ​FILE 
 +  index_directory ​           "​idx\grid04"​ 
 + node "​GRID05"​ 
 +  type                       ​FILE 
 +  index_directory ​           "​idx\grid05"​ 
 + ​in ​                         "​list.xml";​ 
 +</​code>​ 
 + 
 +=== TYPE database_type ​=== 
 +The TYPE clause specifies the type of database being declared. ​ The //database_type// is  required.
  
 Valid database types are:  Valid database types are: 
  
-  * FLATFILE+  * FILE
   * ORACLE   * ORACLE
   * SQLSERVER   * SQLSERVER
   * ODBC   * ODBC
    
-When a database is spread across multiple nodes of an Omnidex Grid, the node is declared for each time.  At present, the type must be the same across all nodes; however, support for different database types for each node may be supported in the future.  ​+When a database is spread across multiple nodes of an Omnidex Grid, the PHYSICAL clause ​is declared for each node.  At present, the //​database_type// ​must be the same across all nodes; however, support for different database types for each node may be supported in the future.  ​
  
-=== [SUBTYPE ​subtype] ​===+=== SUBTYPE ​odbc_subtype ​===
  
 The SUBTYPE setting within the TYPE clause is used to specify a subtype for ODBC databases. The SUBTYPE setting within the TYPE clause is used to specify a subtype for ODBC databases.
Line 65: Line 113:
  
 Omnidex can access other databases through ODBC, even if the subtype is not declared. ​ Note that there can be differences in the way that each underlying database implements ODBC.  Because of this, some Omnidex functionality may not be available. Omnidex can access other databases through ODBC, even if the subtype is not declared. ​ Note that there can be differences in the way that each underlying database implements ODBC.  Because of this, some Omnidex functionality may not be available.
 +=== INDEX_DIRECTORY “directory” ===
  
-==== [VERSION “version] ====+The INDEX_DIRECTORY is an optional clause specifies the operating system location of the Omnidex index files. ​ The directory can either be an absolute or relative path.  Relative paths are relative to the location of the Omnidex Environment File.  Relative locations are recommended when feasible. ​  
 + 
 +If no //​directory//​ is declared, then the Omnidex index files will reside in the same directory as the Omnidex Environment File. 
 + 
 +The //​directory//​ can also be specified with an environment variable using curly braces. 
 + 
 +<​code>​ 
 +create database ​             "​LIST"​ 
 +  type                       ​FILE 
 +  index_directory ​           {$LIST_DIR} 
 +</​code>​ 
 +=== VERSION “rdbms_version” ===
  
 The VERSION clause is used to by Omnidex to determine which syntax and API to use with the underlying relational database.  ​ The VERSION clause is used to by Omnidex to determine which syntax and API to use with the underlying relational database.  ​
Line 83: Line 143:
 | 8 | All versions of SQL Server 2000 | | 8 | All versions of SQL Server 2000 |
 | 9 | All versions of SQL Server 2005 | | 9 | All versions of SQL Server 2005 |
-==== [INDEX_DIRECTORY “directory”] ==== 
  
-The INDEX_DIRECTORY clause specifies the operating system location of the Omnidex index files and optionally the index file prefix. 
  
-The directory portion can either be an absolute or relative path.  ​Relative paths are relative ​to the location ​of the Omnidex Environment ​File.  ​Relative locations are recommended when feasible.  ​+=== PHYSICAL "​rdbms_string"​ === 
 +The PHYSICAL //​rdbms_string//​ declares RDBMS connection information and is only used with relational databases and ODBC.  ​The //​rdbms_string//​ varies according ​to database type as follows: 
 +^Database Type  ^Description ​ ^ 
 +| FILE | ignored | 
 +| ORACLE | The PHYSICAL clause is ignored and Oracle will use the default database for the specified user. | 
 +| ORACLE w/SQLNET | if using Oracle SQLNET, use the name of the SQLNET service and specify "​SQLNETx"​ in the VERSION clause. | 
 +| SQLSERVER | The PHYSICAL clause contains the ODBC connection information. ​ For File DSNs, use "​FILEDSN=file_dsn_filespec"​.  ​For System and User DSNs, use "​DSN=dsn_name"​ or just "​dsn_name"​ where dsn_name is the data source name set up in the Windows ODBC Administrator program. | 
 +| ODBC | The PHYSICAL clause contains the ODBC connection information.  ​For File DSNs, use "​FILEDSN=file_dsn_filespec"​. ​ For System and User DSNs, use "​DSN=dsn_name"​ or just "​dsn_name"​ where dsn_name is the data source name set up in the Windows ODBC Administrator program. |
  
-If no //​index_directory//​ is declared, then the Omnidex index files will reside in the same directory as the Omnidex Environment File. +===  USER “rdbms_user” PASSWORD “user_password” ​=== 
-==== [NODE node] ==== +The USER and PASSWORD clauses are used to provide a valid RDBMS database user and password to be used for Omnidex ​to access the underlying RDBMS data source.  ​The USER and PASSWORD clauses are required for Oracle, and are otherwise optional
-The optional NODE clause is used to configure an Omnidex ​Grid.  ​Nodes that were previously declared in the CREATE ENVIRONMENT statement can be referenced here, and the database configuration can be named for each node.+
  
-<​code>​ +All connections to the underlying database will use this //​rdbms_user//​ and //​user_password//​. ​ Omnidex does not have a supplemental security facility that allows sending different users and passwords.
-create environment ​           +
- ​data_cache ​                 32 +
- ​max_threads ​                2 +
- ​node ​                       "​GRID01"​ partitioned +
- ​node ​                       "​GRID02"​ partitioned +
- ​node ​                       "​GRID03"​ partitioned +
- ​node ​                       "​GRID04"​ partitioned +
- ​node ​                       "​GRID05"​ unpartitioned +
- ​in ​                         "list.xml";+
  
-create database ​             "​LIST"​ +=== INDEX_MAINTENANCE index_maintenance_type ===
- node "​GRID01"​ +
-  type                       ​FLATFILE +
-  index_directory ​           "​idx\LIST1_"​ +
- node "​GRID02"​ +
-  type                       ​FLATFILE +
-  index_directory ​           "​idx\LIST2_"​ +
- node "​GRID03"​ +
-  type                       ​FLATFILE +
-  index_directory ​           "​idx\LIST3_"​ +
- node "​GRID04"​ +
-  type                       ​FLATFILE +
-  index_directory ​           "​idx\LIST4_"​ +
- node "​GRID05"​ +
-  type                       ​FLATFILE +
-  index_directory ​           "​idx\LIST5_"​ +
- ​in ​                         "​list.xml";​ +
-</​code>​+
  
-==== [ PHYSICAL "​dbms_string"​ ] ==== +The INDEX_MAINTENANCE clause ​is an optional clause that specifies how Omnidex indexes will be updated. ​ The //​index_maintenance_type//​ can be either API or DBMS.
-The PHYSICAL "​dbms_string"​ declares RDBMS connection information and is used primarily with relational databases and ODBC.+
  
-The "​dbms_string"​ varies according to database type as follows:+  * API - The indexes will be updated by Omnidex automatically ​as the database data is updated. 
 +  * DBMS - The indexes will be updated by relational database triggers in conjunction with the OdxAIM services.  ​
  
-  * FLATFILES - ignored +This setting applies to the entire index installation for this database. ​It can be overridden on a table-by-table basis by explicitly defining ​the //​index_maintenance//​ setting on an individual table
-  * ORACLE with SQLNET - if using Oracle SQLNET, use the name of the SQLNET service and specify "​SQLNET x" in the VERSION clause. +===      IN “environment_filespec” ===
-  * ORACLE without SQLNET - The PYSICAL caluse is ignored and Oracle will use the default ​database ​for the specified user. +
-  * SQLSERVER ​The PHYSICAL clause contains ​the ODBC connection information. ​ For FILE DSNs, use "​FILEDSN=file_dsn_filespec"​. ​ For System/User DSNs, use "​DSN=dsn_name"​ or just "​dsn_name"​ where dsn_name is the data source name set up in the Windows ODBC Administrator program+
-  * ODBC - The PHYSICAL clause contains the ODBC connection information. ​ For FILE DSNs, use "​FILEDSN=file_dsn_filespec"​. ​ For System/User DSNs, use "DSN=dsn_name"​ or just "​dsn_name"​ where dsn_name is the data source name set up in the Windows ODBC Administrator program.+
  
-====  [USER "​DEFAULT"​ | “user”] [PASSWORD “password”] ==== +The IN clause is required ​and specifies ​the location of the physical XML Environment File.  The IN clause must be specified after all other clauses.
-The USER / PASSWORD ​clause is used to provide a valid RDBMS database user and password to be used for Omnidex to access ​the underlying RDBMS data source.+
  
-The USER PASSWORD clause is required for ORACLE. It declares ​either or both the name and password of a valid databaseAll connections to the database ​will connect with this option. USER and PASSWORD can be filespecs where the contents of the file contain the user and password.+//​Environment_filespec//​ can also include ​either ​an absolute ​or relative path When using a relative file path , it will be relative to the current working directory for the program that is being run. Typically in a production environment,​ absolute paths are used.  When using Omnidex'​s Network Services ​and the OdxNet process, absolute paths should always be used.
  
-==== [INDEX_MAINTENANCE index_maintenance_type] ==== +The //​environment_filespec//​ must be enclosed within double quotes.
-The INDEX_MAINTENANCE clause is an optional clause that specifies how Omnidex indexes will be updated.+
  
-The index_maintenance_type can be one of either API or DBMS. 
- 
-API - The indexes will be updated by Omnidex automatically as the database data is updated. 
- 
-DBMS - The indexes will be updated by some other means, ODXAIM for example, in a separated process. 
- 
-This setting applies to the entire index installation on this database. It can be over-ridden on a table-by-table basis by explicitly defining the index_maintenance setting on an individual table. 
- 
-====      IN “filespec” ==== 
-The IN "​filespec"​ clause specifies the physical file name and directory containing the metadata for an Omnidex Environment. 
- 
-The IN "​filespec"​ can be specified either as a relative or absolute file specification and much be enclosed in double quotes. 
- 
-==== [WITH options] ==== 
-There are currently no options for the CREATE DATABASE statement. 
  
 ===== Examples ===== ===== Examples =====
-==== Simple ​====+==== Single Database with no Nodes ====
 <​code>​ <​code>​
 create environment in "​env1.xml"​ with delete; create environment in "​env1.xml"​ with delete;
 create database db1 type flatfile in "​env1.xml";​ create database db1 type flatfile in "​env1.xml";​
 </​code>​ </​code>​
 +
 ==== Two Databases within an Environment ==== ==== Two Databases within an Environment ====
 <​code>​ <​code>​
Line 177: Line 196:
   in "​env1.xml";​   in "​env1.xml";​
  
-create table db2.table1 physical "​db2table1" ​      ​/* Note the db2 database qualification */+create table "db2"."table1" ​physical "​db2table1" ​ /* Note the db2 database qualification */
   ( pk integer,   ( pk integer,
     mytext char(60) quicktext     mytext char(60) quicktext
Line 204: Line 223:
 disconnect disconnect
 </​code>​ </​code>​
 +
 +====== Additional Resources ======
 +See also: 
 +  * [[dev:​sql:​statements:​create_environment:​home|CREATE ENVIRONMENT]]
 +  * [[dev:​sql:​statements:​create_table:​home|CREATE TABLE]]
 +  * [[dev:​sql:​statements:​create_index:​home|CREATE INDEX]]
 +  * [[dev:​sql:​statements:​update_indexes:​home|UPDATE INDEXES]]
 +
 +Articles:
 +
 +  * [[admin:​features:​grids:​home|Omnidex Grids]]
 +  * [[dev:​appendix:​articles:​dbspecific:​home|Database-specific issues]]
  
 {{page>:​bottom_add&​nofooter&​noeditbtn}} {{page>:​bottom_add&​nofooter&​noeditbtn}}
 
Back to top
dev/sql/statements/create_database/home.1278102462.txt.gz · Last modified: 2016/06/28 22:38 (external edit)