Is SELECT always excluded from DML?

No. Some classifications, including Oracle's, include it.

Does updating a value necessarily add a record?

No. The toy update changed a quantity while preserving the record count.

Does a successful command prove the intended records changed?

No. The operation's target and resulting values still need to match the request.

AI Glossary / Data engineering and architecture / Advanced

Data manipulation language

Definition

Data manipulation language, commonly abbreviated DML, is the part of a database language used to work with data held in existing database structures. In SQL, familiar operations include inserting, updating and deleting records. Some classifications also include querying with SELECT. DML concerns the data itself, while data definition language concerns structures such as tables. Exact command categories depend on the database documentation being used.

What it means

A business application needs to do more than describe the shape of a customer or order record. It must record new information and change existing information as events occur. DML provides commands through which those operations can be expressed. An application may generate the commands behind a form, integration or AI-assisted interface. Understanding the intended data operation remains important even when a user never sees the database statement. A fluent explanation of a requested change is different from a correctly scoped operation that produces the intended database state.

How it works

A statement identifies an operation, its target and the relevant values or selection conditions. The database processes it under its rules for permissions, constraints and transactions. PostgreSQL's introductory data-manipulation chapter covers insert, update and delete; Oracle's DML category also includes SELECT. This illustrates why command labels should be read in context. Transaction control determines how changes are committed or rolled back, subject to the system and client configuration. Do not infer those settings merely from the fact that a statement is described as DML.

Three practical examples

An order-entry application adds a new order record after collecting the required details.
A service desk changes the status of an identified ticket when the work is completed.
A test-data exercise removes specifically designated sample records, then checks that the intended remaining records are still present.

Think of it this way

Imagine a filing cabinet with labeled compartments and standard record cards. Designing the compartments resembles defining the data structure. Adding a card, correcting a value on a card or removing a designated card resembles manipulating its contents. The instruction must identify the right card and action. Telling an assistant to correct the price is incomplete if several products have prices. The analogy explains scope; it does not imply that database operations are performed one physical card at a time.

Worked example

Consider an original toy table containing products A, B and C with quantities 4, 7 and 9. A specified update sets B's quantity to 8, leaving A and C unchanged. The table still has three records, and the sum changes from 20 to 21. Next, inserting product D with quantity 2 produces four records and a total quantity of 23. These are separate measures: record count and the sum of a field. If the first instruction accidentally targeted every product, the intermediate quantities would instead be 8, 8 and 8, totaling 24. A statement completing successfully would not make that broader result the intended one.

Illustrative case study

A fictional inventory team tests an AI assistant that translates plain-language requests into proposed database changes. A request refers to the discontinued item, but two products have similar descriptions. During review, the team notices that the proposed target does not identify a unique product. It resolves the identifier and tests the expected before-and-after values in a controlled example before approving the workflow. This illustrates the gap between natural-language intent and precise data manipulation. It does not establish that generated commands are reliable merely because they are syntactically valid or accepted by a database.

Common misconceptions and mistakes

DML is not synonymous with changing the table design. Altering a field's definition and updating a stored field value are different operations. Another mistake is assuming that every textbook and database places SELECT in the same category. Command classification is less important than understanding what the operation does. A successful statement also does not prove business correctness: an overly broad target can produce valid but unintended changes. Finally, record count alone may miss an incorrect update because values can change while the number of records stays exactly the same.

Business use

The concept helps business teams describe changes precisely enough for implementation and review. State which entities should be affected, which values should change and what the final result should look like. For AI-assisted database work, evaluate examples that distinguish similarly named entities and check both affected scope and resulting values. Make transaction and recovery behavior part of the implementation discussion. A useful acceptance check compares the expected state with the actual state, instead of treating the absence of an error message as proof that the business request was fulfilled.

Check your understanding

What was the toy quantity total after updating B?

Answer: Twenty-one.

How many records existed after inserting D?

Answer: Four.

Why was a record count insufficient to detect the overly broad update?

Answer: Updating values can leave the number of records unchanged.

What distinction separates DML from defining a table?

Answer: Working with its contents versus specifying its structure.

Related terms

Data Definition Language
SQL
transaction
CRUD
database constraint
query

Learn next

Write a before-and-after description for a small inventory table without using SQL syntax. Include one insertion and one narrowly targeted update. List the record count, affected identifiers and expected values after each operation. Explain which checks would detect a correct command applied to the wrong target.

Sources

PostgreSQL Global Development Group, Data Manipulation: https://www.postgresql.org/docs/current/dml.html Oracle, Types of SQL Statements: https://docs.oracle.com/en/database/oracle/oracle-database/26/sqlrf/Types-of-SQL-Statements.html The inventory calculation, filing-cabinet analogy and AI-assistant case are original educational illustrations. The references establish database-specific command categories; the entry does not assume a universal classification or transaction configuration.

Previous: Data management plan Next: Data mart