Sybase IQ recognizes four types of tables:
Base tables
Local temporary tables
Global temporary tables
Join virtual tables
Base tables are sometimes called main, persistent, or permanent tables because they are a permanent part of the database until you drop them explicitly. They remain in the database over user disconnects, server restart, and recovery. Base tables and the data in them are accessible to all users who have the appropriate permissions. The CREATE TABLE statement shown in the previous example creates a base table.
Certain client tools need to create and populate persistent tables. In a multiplex database, persistent tables have two locations, depending upon the server to which the user connects:
On the write server, users create persistent tables in the shared IQ Main Store.
On the query server, users create persistent tables in a local IQ Main Store (Local Store). If the user has not first created a dbspace to serve as the local IQ Main Store, IQ issues an error when a user tries to create a persistent object.
Write server |
Query server |
---|---|
Persistent tables reside in the shared IQ Main Store and are visible to all servers in the multiplex. The write server performs all changes to these objects (DML and DDL) |
Persistent tables reside in the local IQ Main Store. They are local to a particular query server in the multiplex, and are visible to all users of that query server. The persistent tables are not visible to users of other query servers in the multiplex. |
DDL executed on write server persistent objects automatically propagates to query servers. |
DML and DDL executed on query server persistent objects affect only the local IQ Main Store. |
There are two types of temporary tables, global and local.
You create a global temporary table, using the GLOBAL TEMPORARY option of CREATE TABLE, or by using the Global Temporary Table Creation wizard in Sybase Central. When you create a global temporary table, it exists in the database until it is explicitly removed by a DROP TABLE statement.
A database contains only one definition of a global temporary table, just as it does for a base table. However, each user has a separate instance of the data in a global temporary table. Those rows are visible only to the connection that inserts them. They are deleted when the connection ends. A given connection inherits the schema of a global temporary table as it exists when the user first refers to the table. Global temporary tables created on the write server are also created on all query servers. Global temporary tables created on the query server are local to that query server.
To select into a temporary table, use syntax like the following:
SELECT * INTO #TableTemp FROM lineitem WHERE l_discount < 0.5
You declare a local temporary table for your connection only, using the DECLARE LOCAL TEMPORARY TABLE statement. A local temporary table exists until the connection ends, or within a compound statement in which it is declared. The table and its data are completely inaccessible to other users.
See “Versioning of temporary tables” for versioning information on local temporary tables.
You drop a global temporary table just as you would a base table, with the DROP TABLE statement, or with Sybase Central. You cannot drop or alter a global temporary table while other connections are using the table.
Sybase IQ creates tables in your current database. If you are connected to an IQ database, tables are placed as follows:
Type of table |
Permitted placement |
Default placement |
---|---|---|
Permanent |
IQ Store, Catalog Store, IQ Local Store (query server only) |
IQ Store, IQ Local Store (query server only) |
Global temporary |
IQ Temporary Store, Catalog Store |
IQ Temporary Store |
Local temporary |
IQ Temporary Store or Catalog Store; only visible to user who creates it |
IQ Temporary Store |
A Join Virtual Table is a denormalized table that looks like a regular table; it has a name, columns, rows, and indexes. Sybase IQ creates Join Virtual Tables as a result of a Create Join Index for internal processing purposes and deletes them when you do a Drop Join Index. You cannot create, modify, or delete Join Virtual Tables, but you may see error messages related to them if you try to use or modify them. Sybase suggests that you ignore all Join Virtual Tables. Servers running in a multiplex cannot create or drop Join Indexes. (Write servers must be in single-node mode to do so, and query servers must be synchronized.)