I am currently reading the offical Microsoft book 'Database Administration Fundamentals' in preparation to sitting it's exam.
I understand what DDL and DML are but Microsoft show DELETE as being both a DDL and DML statement. I have googled this but I cannot anything that confirms or denies this.
A good reference to this is the question: What is DDL and DML Which shows it as a DML. Below is the segments from the book:
Data Manipulation Language (DML) is the language element that allows
you to use the core statements INSERT, UPDATE, DELETE, and MERGE to
manipulate data in any SQL Server tables. Core DML statements include
the following: • SELECT: Retrieves rows from the database and enables
the selection of one or many rows or columns from one or many tables
in SQL Server. • INSERT: Adds one or more new rows to a table or a
view in SQL Server. • UPDATE: Changes existing data in one or more
columns in a table or view. • DELETE: Removes rows from a table or
view. • MERGE: Performs insert, update, or delete operations on a
target table based on the results of a join with a source table.
the six main DDL statements are as follows: • USE: Changes the
database context. • CREATE: Creates a SQL Server database object
(table, view, or stored procedure). • ALTER: Changes an existing
object. • DROP: Removes an object from the database. • TRUNCATE:
Removes rows from a table and frees the space used by those rows. •
DELETE: Remove rows from a table but does not free the space used by
those rows removed.
Is the book out of date/ wrong. Can someone help shed light on this I see conflicting lists of what are the full DDL and DML statements.
I agree with you, DELETE is DML. Moreover, I dare say, TRUNCATE should also be considered DML, since logically is equivalent to a DELETE statement. The fact that TRUNCATE is a DROP and CREATE is not enough in my opinion to justify assigning it to DDL, since the two together, carried out as one atomic operation, do not affect the schema of the database.
Related
Are we able to perform SQL operations like INSERT, UPDATE, DELETE to Database Catalog (It is more theory question than practice)
If a database supports INFORMATION_SCHEMA and provides instruments for altering the database catalog, then yes, you can use SQL operations normally.
For example, in PostgreSQL documentation you can read:
The system catalogs are the place where a relational database management system stores schema metadata, such as information about tables and columns, and internal bookkeeping information. PostgreSQL's system catalogs are regular tables. You can drop and recreate the tables, add columns, insert and update values, and severely mess up your system that way. Normally, one should not change the system catalogs by hand, there are always SQL commands to do that. (For example, CREATE DATABASE inserts a row into the pg_database catalog — and actually creates the database on disk.)
So, you change the catalog indirectly creating a new database. Nonetheless, with PostgreSQL you can directly change the catalog, using SQL commands like DROP, INSERT, UPDATE and so on.
Some RDBMS don't provide such a possibility, such as Oracle Database, IBM DB2, SQLite or Sybase ASE. Some RDBMS provide INFORMATION_SCHEMA, but it is read-only, so you can't do anything crazy, for example, MySQL. Its documentation reads:
Although you can select INFORMATION_SCHEMA as the default database with a USE statement, you can only read the contents of tables, not perform INSERT, UPDATE, or DELETE operations on them.
Reading up the documentation of PL-SQL CREATE TRIGGER statement in ORACLE, I went through the following bit of information:
When a trigger fires, tables that the trigger references might be
undergoing changes made by SQL statements in other users'
transactions. SQL statements running in triggers follow the same rules
that standalone SQL statements do.
It basically says the rules that would apply to two conflicting standalone SQL statements (running at the same time) are unchanged when one of the statements is performed from within a trigger.
So we have some "usual" rules about concurrent transactions and, as for these rules, the following two are mentioned:
Specifically:
Queries in the trigger see the current read-consistent materialized
view of referenced tables and any data changed in the same
transaction.
Updates in the trigger wait for existing data locks to be released
before proceeding.
These two rules look like "obscure" to non-expert users.
What do they mean more precisely?
Queries in the trigger see the current read-consistent materialized
view of referenced tables and any data changed in the same
transaction.
This means the data the trigger sees, like if it does a SELECT on a different table, represents the state of that table when the statement started running. The trigger does not see rows that have been changed by other sessions that have not been committed yet.
Updates in the trigger wait for existing data locks to be released
before proceeding.
When an Oracle statement modifies a row, the row is locked against other people changing it until that session either commits or rolls back its transaction. So if you do an insert on table A, your trigger does an update on table B, but someone else's session has already done an update on table B for that same row, your transaction will wait until they commit or rollback.
I was going through the different commands in SQL and I came across alter command which is referred as DDL (Data Definition Language). We can alter the column and values in it, so we can manipulate the data with this command so why does alter command is not referred as DML (Data Manipulation Language).
I have googled and I can not come across some good explanation, so please help me with this.
ALTER command is used to alter the structure of the database. And this is what DDL does i.e., DDL statements are used to define the database structure or schema.
Whereas DML statement is used to manage data within schema objects.
DDL - alter the schema.
This including creating tables, renaming columns, dropping views, etc. Such statements are DDL even though such might create (default value), alter (by conversion), or even lose (removed column) data as part of the process. Basically, any CREATE/DROP/ALTER command is DDL.
DML - alter the information/data within the schema; without updating the schema.
This includes DELETE and UPDATE statements.
Sometimes DDL and DML must be used together to correctly migrate a schema; but they are two distinct categories of SQL commands, and DML never causes the schema to be changed.
Cause ALTER command is not manipulating the data. It is used to change a definition of o column or table or other DB objects.
See
http://www.w3schools.com/sql/sql_alter.asp
The "data" is the data in the tables defined by the user via DDL. The "metadata" is the data in the tables pre-defined by the DBMS that describe the tables (themselves and those defined by the user). So DML manipulates data in user tables or (usually only) reads metadata from system tables while DDL defines (CREATEs, ALTERs, DROPs) user tables and as a side effect updates metadata in system tables.
The ALTER command can be both DDL and DML. I have known ALTER to be DDL over the past just like the majority of those who have responded to this. However, with MySQL 5.7.x you will see that soon after initializing the database with mysqld --initialize --console a default root user account and its corresponding password is created. You can access your database with this newly created root user account BUT there is absolutely nothing that you can do after logging in. The only SQL statement allowed at this stage is the ALTER statement. This is used to change the default password generated during initialization. The syntax is ALTER USER 'root'#'localhost' IDENTITIED BY 'new_password'; . This is the only statement that the database accepts. This modifies/updates/manipulates the data (password) in the users table. In this regard I have concluded that the ALTER statement can be both DDL and DML
I am looking back at Oracle (11g) development after few years for my team project and need help. We are trying to implement a POC where any add/drop column will drop and recreate a corrosponding view. View refers to a Mapping table for producing its alias names and selection of columns.
My solutions:
--1. DDL Trigger that scans for Add Column, Drop Column -> Identifies Column Names -> Updates Field_Map table -> Drops View -> Creates View with Field_Map table alias names
Challenge: Received recursive trigger error because of View creation inside DDL
--2. DDL Trigger scans for Add Column, Drop Column -> -> Updates Field Map table -> Writes identified column names, tables to Audit_DDL table -> DML trigger on Audit_DDL table fires -> Disables DDL trigger (to avoid recursion) -> Drops view -> Creates view with Field_Map table alias names
Challenge: Received recursive trigger error. I think, it is still considering whole flow as one transaction. Separating create view under DML trigger didn't help.
so, I am thinking of alternatives:
--3. Store Trigger, Tables in Schema1 and View Schema2. I am expecting, this may avoid recursion since create view will now happen on schema2 and trigger is built on schema1.
--4. Create a Stored Procedure which scans for Audit_DDL entries (from #2) for tables, columns updated. Creates views and marks checked for processed Audit_DDL entries. Hourly job now runs this procedure.
Any suggestions? Thanks in advance for helping me out!
If you want to do DDL from a trigger, it would need to be asynchronous. The simplest solution would be for the DDL trigger to submit a job using the DBMS_JOB package that would execute whatever DDL you want to do. That job would not run until the triggering transaction (the ALTER statement) committed. But it would probably run a few seconds later (depending on how many other jobs are running, how many jobs are allowed, etc.). Whether you build the DDL statement you want to execute in the trigger and just pass it to the job or whether you store the information the job will need in a table and pass some sort of key (i.e. the object name) and let the job assemble the DDL statement is an implementation detail.
That being said, this seems like a really exceptionally poor architecture. If you are adding or removing a column, that is something that should be going through a proper change control process. If the change is going through change control, it should be easy enough to include the changes to the views in the same script. And applications that depend on the views should be tested as part of the change control process. If the change is not going through change control and columns are being added to or removed from views willy-nilly, you've got much bigger problems in the business process and you're very likely to cause one or more applications to barf in strange and wonderful ways at seemingly obscure points in time.
DDLs and DMLs are two strict categories of types of statements used for interacting with a database. I am not sure why this categorization exists.
Is there a fundamental difference in the way an Oracle database would work internally with respect to a DDL and DML statement?
One major (technical) difference between DDL and DML in Oracle is, that DDL is not transactional, i.e. they cannot be rolled back and don't require a commit. As a matter of fact DDL in Oracle does an implicit commit before it's executed.
Other databases (e.g. Postgres, DB2) do not make a difference with regards to transactions between DDL and DML
After all it's just a categorization, similar to the terms "application" and "server" (as in database server). From an operating point of view, OpenOffice and Oracle are both simply "applications", but yet we classify them into different categories.
DDL statements are used to define database structures, objects, and schemas whereas DML statements are used for managing data within schema objects. At the end of the day, Oracle (o r any other data management system) would process each type statement according to security permissions and object availability (i.e. locks on tables / views and isolation levels).
Also, schema definitions are held in internal master tables so your DDL statements actually affect the data stored in those tables and perhaps can be considered "master DML" statements in that sense.
If your question amounts to "is there a reason why it is necessary for DDL and DML to "be implemented differently", the answer is "NO".
However, the definers of the SQL language have opted for making DDL syntactically distinct. As a consequence, adding a column to a table must be done through the appropriate ALTER TABLE command. A side-effect of that command is that a row gets inserted in the catalog table that documents all columns. Stress side-effect.
But there is no fundamental reason why the insertion of a row in the catalog table could not be the trigger itself for the column addition, thus entirely eliminating the need for any "dedicated DDL".