Format:DROP SCHEMA schema_name {RESTRICT | CASCADE};
This command will remove the schema.

If RESTRICT is specified, the schema will not be deleted if all objects in the schema have not been dropped.

If CASCADE is specified, the schema will be deleted with all objects contained in the schema.
Example:

DROP SCHEMA CBT_INC CASCADE;

Format:

          CREATE SCHEMA schema_name [user_id]
                [DEFAULT CHARACTER SET char_set_name];

A schema is a set of database objects that is owned by a user called a schema owner.
The schema owner has authority to give privileges to other users.
Example:

          CREATE SCHEMA CBT_INC USER1;

> All RDBMS vendors have their own parameters for defining a schema.

Format:

          DROP ALIAS alias_name;

                                     or

          DROP SYNONYM synonym_name;

This command will remove the alias or synonym.
Example:

          DROP SYNONYM PILOTS;

> Aliases and synonyms are not an SQL standard.

> DB2, Informix, and Oracle implement ALIAS and SYNONYM.

> MySQL does not implement ALIAS or SYNONYM.

Format:

          CREATE [PUBLIC | PRIVATE] ALIAS alias_name
             FOR {table_name | view_name};

or

          CREATE [PUBLIC | PRIVATE] SYNONYM synonym_name
             FOR {table_name | view_name};

An alias or synonym produces another name for a table or view.
The normal use of an alias or symonym is to avoid having to qualify another user’s table or view.
An alias or synonym simplifies the SQL statement and make it appear to be your own table.

A PRIVATE alias or synonym can only be accessed by the creator of the alias or synonym.
If unspecified, PRIVATE is the default.

A PUBLIC alias or synonym is accessible to all users of the database.
Normally only a Database Administrator or a privileged security user can create with PUBLIC.

Example:

          CREATE SYNONYM PILOTS FOR USER1.PILOT_TBL;

> Aliases and synonyms are not an SQL standard.

> DB2, Informix, and Oracle implement ALIAS and SYNONYM.

> MySQL does not implement ALIAS or SYNONYM.

DB2, Oracle, PostgreSQL Format:

          DROP INDEX index_name;

Access, MySQL Format:

          DROP INDEX index_name
            ON table_name;

SQL Server Format:

          DROP INDEX table_name.index_name;

Because an index is completely separate from its associated table, it can be deleted at any time without any effect on the base table other than performance issues. All SQL code will continue to function normally.

Most RDBMS systems have tools for measuring performance. If a table is small, or the data is infrequently referenced, you may choose to remove the index.

The SQL standard does not mention indices so vendors do their own implementation.

Format:

          CREATE {UNIQUE} INDEX index_name
              ON table_name (
                   column_name1 {ASC | DESC},
                   column_name2 {ASC | DESC},
                   ...);

A simple index contains only a single column.

A composite index contains multiple columns from a single table.
The index applies to all the columns in the index definition.
These columns do not have to be adjacent in the table.
Instead, they can be taken from any column in any order.
The order in the index definition is important and is defined left to right, going from major to minor sort order.

Your can create multiple indices on the same table.

ASC means ascending sort order, which is the default and does not need to be specified.
DESC means descending sort order and must be specified to reverse the sequence.
UNIQUE forces the combination of indexed columns to be unique.
> Access, MySQL, and SQL Server index names must be unique within a table.

> DB2, Oracle, and PostgreSQL index names must be unique within the database.

When people try to adjust a database for performance, a big part of the discussion is the creation of indices.
A basic concept of SQL databases is that the data has no order.
The advantage of this lack of order is that it allows the RDBMS to INSERT, UPDATE, and DELETE rows quickly.
The disadvantage is that finding data in rows using searching and sorting is slow (but it will work). Searching
a small database is easy, but searching a large production database with millions of rows can be slow.The RDBMS system provides the INDEX as a way of solving this problem. Basically, an index is a sorted file of values with pointers to the physical locations of the indexed data. When you request a specific value, this value is located in the sorted index and the values can be retrieved using the pointers to the rows of matching data. This way, the RDBMS system does not need to read the entire table to retrieve only those matching rows. The trade-off is that data retrieval is much faster, but INSERT, UPDATE, and DELETE are slower because the index must be updated. Each RDBMS system handles indices differently.

An index is automatically created for a PRIMARY KEY without the user’s knowledge. Automatic creation of an index for a FOREIGN KEY or constraint such as UNIQUE depends upon your RDBMS system. Once an index is created, its use is invisible to the user. No changes are made to any SELECT, INSERT, UPDATE, or DELETE statements. Creation or removal of an index only affects performance.
You may wish to create an index for:

          WHERE      Search data
          ORDER BY   Sorted data
          GROUP BY   Grouped data
          JOIN       Joined data

You use a DROP VIEW command to delete a view.
Format:

          DROP VIEW view_name;

 

> Dropping a table does not remove a view, but a view can not function without a base table.
> A table can be empty (no data) without being dropped.

The ALTER VIEW format varies according to the RDBMS system: 
DB2 Format:

          ALTER VIEW view_table_name
          ALTER [COLUMN] column_name ADD SCOPE type
            ...;

Oracle Format:

          ALTER VIEW view_table_name
           {ADD CONSTRAINT constraint_clause
       | MODIFY CONSTRAINT constraint_clause
         | DROP CONSTRAINT constraint_clause};

SQL Server Format:

          ALTER VIEW view_table_name [column[,...]]
          [WITH {ENCRYPTION | SCHEMABINDING | VIEW_METADATA}];

> DB2 will not allow you to DROP a column.

> MySQL 5 supports views but earlier versions of MySQL do not support views.

> PostgreSQL has limited support options.

Format:

          CREATE VIEW view_table_name
                    [(view_column_name1,
                      view_column_name2, ...)]
                   AS SELECT column1, column2, ...
                        FROM table1,  table2,  ...;

                                                       or

          CREATE VIEW view_table_name
                   AS SELECT column1 AS alias1,
                             column2 AS alias2, ...
                        FROM table1, table2, ...;

The view_column_names are optional with one or more comma separated names to be used as alternate names in the view. These names must be a valid identifiers according to the rules of each RDBMS system. The number of view_column_names must match the number of columns in the SELECT statement. If you name any of the columns this way, you must name all of the columns this way.

If the view_column_names option is not used, the column names are inherited from the SELECT statement or column names can also be assigned by the AS column alias.
> The SQL standard does not have an ALTER VIEW, but DB2, Oracle, and SQL Server have implemented a non-standard ALTER VIEW. Other systems must use DROP VIEW to delete the view and then recreate the new view with CREATE VIEW.

> MySQL 5 supports views, but earlier versions of MySQL do not support views.

> With single table views, you can INSERT, UPDATE, and DELETE data. For other views, see your documentation.

> PostgreSQL views can only come from tables (not other views) and the view data is read only (no update).