This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
integration:rdbms:mysql:tables [2011/04/07 13:24] doc |
integration:rdbms:mysql:tables [2016/06/28 22:38] (current) |
||
|---|---|---|---|
| Line 57: | Line 57: | ||
| === Using the Table and Column PHYSICAL Clauses === | === Using the Table and Column PHYSICAL Clauses === | ||
| - | In the Omnidex declaration, note that the optional PHYSICAL clause for the table allows Omnidex to have a different table name than MySQL. This is most commonly used when administrators wish a different name in the Omnidex environment or need to shorten a table name to meet the 32-character limit in Omnidex. | + | In the Omnidex declaration, note that the optional PHYSICAL clause for the table allows Omnidex to have a different table name than MySQL. This is most commonly used when administrators wish a different name in the Omnidex environment or need to shorten a table name to meet the 32-character limit in Omnidex. If the PHYSICAL clause is not present, Omnidex assumes that the table names are the same between Omnidex and MySQL. |
| Column declarations can similarly use a PHYSICAL clause to allow Omnidex to have a different column name than MySQL. | Column declarations can similarly use a PHYSICAL clause to allow Omnidex to have a different column name than MySQL. | ||
| Line 66: | Line 66: | ||
| When Omnidex accesses a table, it only knows about the data objects that are declared in the Omnidex Environment File. It does not have an independent understanding of the MySQL environment. This allows administrators to shape the Omnidex Environment the way they want. Some of the opportunities this provides are: | When Omnidex accesses a table, it only knows about the data objects that are declared in the Omnidex Environment File. It does not have an independent understanding of the MySQL environment. This allows administrators to shape the Omnidex Environment the way they want. Some of the opportunities this provides are: | ||
| - | * Omnidex can have a controlled view of the MySQL database, limited to only the tables and columns that the application requires. | + | * Omnidex can have a controlled view of the MySQL database, limited to only the tables that the application requires. Similarly, administrators can choose to include only the columns for each table that the application requires. |
| * Omnidex tables can point to MySQL views, allowing an easy approach to reshaping the application's view of the data. | * Omnidex tables can point to MySQL views, allowing an easy approach to reshaping the application's view of the data. | ||
| * Omnidex can use different names for tables and columns by using the PHYSICAL clause in the TABLE or COLUMN sections of the CREATE TABLE statement to map to the underlying MySQL names. | * Omnidex can use different names for tables and columns by using the PHYSICAL clause in the TABLE or COLUMN sections of the CREATE TABLE statement to map to the underlying MySQL names. | ||
| Line 75: | Line 75: | ||
| Omnidex table declarations can reference MySQL Views. Omnidex will retrieve from the MySQL view just as though it is a table. MySQL Views can be used to provide different views of the data, appropriate for the application. | Omnidex table declarations can reference MySQL Views. Omnidex will retrieve from the MySQL view just as though it is a table. MySQL Views can be used to provide different views of the data, appropriate for the application. | ||
| - | When referencing a MySQL view, it is necessary to declare a UNIQUE constraint. This requirement for the UNIQUE constraint is independent of any PRIMARY or FOREIGN constraints, discussed in the next page. The UNIQUE constraint tells Omnidex how to uniquely identify a row. When Omnidex retrieves individual rows, it will use this unique value; therefore, it is important that access to this column (or columns) be properly indexed in the underlying table. | + | When referencing a MySQL view, it is necessary to declare a UNIQUE constraint. This requirement for the UNIQUE constraint is independent of any PRIMARY or FOREIGN constraints discussed in the next page. The UNIQUE constraint tells Omnidex how to uniquely identify a row. When Omnidex retrieves individual rows, it will use this unique value. Therefore, it is important that access to this column (or columns) be properly indexed in the underlying table. |
| **MySQL CREATE VIEW Statement** | **MySQL CREATE VIEW Statement** | ||