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".
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.
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.
Consider the following abstract situation (just as an example):
I have two tables TableA and TableB. They have unique IDs and possibly other columns (which are irrelevant) The relatioship between them is many to many so I have a third table AssociationTable that is used to store the relationships between them. Basically, AssociationTable will have two columns (ID_A and ID_B - foreign keys).
If I delete a row in AssociationTable and the ID_A that was deleted was the last one, I would also like to delete the entry from TableA that corresponds to that ID.
I could do this:
a) From the application that uses the database
b) by using an SQL trigger
My question, basically, is the following:
Is there any good practice that says "if you can do something from both the application and from SQL, always prefer sql." ?
Or does it depend on the case? If so, what should I take into account?
Performance: The query plan for stored procedures is compiled onn DB Server and subsequent requests can run faster.
A stored procedure can execute multiple steps and the intermediate results need not go back to application layer, reducing traffic between an application and the DB server.
Security: Stored procedures are well defined database objects that can be locked down with security measures. Use of typed parameters can help prevent SQL injection attacks.
Code re-use: SQL queries can be written once and re-used across multiple clients without writing the same SQL commands over and over again.
Abstraction: By putting all the SQL code into a stored procedure, the application is completely abstracted from the field names, tables names, etc. So when a SQL query needs to be changed, there is almost zero or NO impact in the application code.
There are more benefits of doing it in the database.
Other client application code need not worry about data integrity.
The data logic should remain as close to data as possible
It could be faster if managed by DB (trigger invocation).
there is an specify remark for SELECT INTO clause,that I don't know it?is SELECT INTO a DDL or DML?I will appreciate if explain me that specify remark?
thanks
I would say DML as DDL is used to define the database structure, and DML for managing data.
Select into is not different from a insert into, I belive.
Both. It's DDL because it changes the catalog. It's DML because SELECT is DML.
The Wikipedia article on Data manipulation language says (highlighting is mine):
The SQL-data change statements are a subset of the SQL-data statements; this also contains the SELECT query statement, which strictly speaking is part of the DQL, not the DML. In common practice though, this distinction is not made and SELECT is widely considered to be part of DML, so the DML consists of all SQL-data statements, not only the SQL-data change statements. The SELECT ... INTO ... form combines both selection and manipulation, and thus is strictly considered to be DML because it manipulates (i.e. modifies) data.
I Think Basically Select into is a combination query provided by microsoft from Sql server 2008 onwards to backeup data to a table, here we using DDL for creating table and DML for insertion at the definition level of SELECT INTO.
I am working on a program that issues DDL. I would like to know whether CREATE TABLE and similar DDL can be rolled back in
Postgres
MySQL
SQLite
et al
Describe how each database handles transactions with DDL.
http://wiki.postgresql.org/wiki/Transactional_DDL_in_PostgreSQL:_A_Competitive_Analysis provides an overview of this issue from PostgreSQL's perspective.
Is DDL transactional according to this document?
PostgreSQL - yes
MySQL - no; DDL causes an implicit commit
Oracle Database 11g Release 2 and above - by default, no, but an alternative called edition-based redefinition exists
Older versions of Oracle - no; DDL causes an implicit commit
SQL Server - yes
Sybase Adaptive Server - yes
DB2 - yes
Informix - yes
Firebird (Interbase) - yes
SQLite also appears to have transactional DDL as well. I was able to ROLLBACK a CREATE TABLE statement in SQLite. Its CREATE TABLE documentation does not mention any special transactional 'gotchas'.
PostgreSQL has transactional DDL for most database objects (certainly tables, indices etc but not databases, users). However practically any DDL will get an ACCESS EXCLUSIVE lock on the target object, making it completely inaccessible until the DDL transaction finishes. Also, not all situations are quite handled- for example, if you try to select from table foo while another transaction is dropping it and creating a replacement table foo, then the blocked transaction will finally receive an error rather than finding the new foo table. (Edit: this was fixed in or before PostgreSQL 9.3)
CREATE INDEX ... CONCURRENTLY is exceptional, it uses three transactions to add an index to a table while allowing concurrent updates, so it cannot itself be performed in a transaction.
Also the database maintenance command VACUUM cannot be used in a transaction.
Can't be done with MySQL it seems, very dumb, but true... (as per the accepted answer)
"The CREATE TABLE statement in InnoDB is processed as a single
transaction. This means that a ROLLBACK from the user does not undo
CREATE TABLE statements the user made during that transaction."
https://dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
Tried a few different ways and it simply won't roll back..
Work around is to simply set a failure flag and do "drop table tblname" if one of the queries failed..
Looks like the other answers are pretty outdated.
As of 2019:
Postgres has supported transactional DDL for many releases.
SQLite has supported transactional DDL for many releases.
MySQL has supported Atomic DDL since 8.0 (which was released in 2018).
While it is not strictly speaking a "rollback", in Oracle the FLASHBACK command can be used to undo these types of changes, if the database has been configured to support it.