DCL

Definition

DCL (Data Control Language) is the family of SQL statements that manage permissions — who is allowed to do what to which database objects. The two core DCL verbs are GRANT and REVOKE.

How It Works

sql
GRANT SELECT, INSERT ON employees TO app_readonly_role;
GRANT ALL PRIVILEGES ON employees TO db_admin_role;

REVOKE INSERT ON employees FROM app_readonly_role;

DCL implements the principle of least privilege: each database user or role should have exactly the permissions it needs to do its job, and no more. A reporting dashboard's database account typically gets GRANT SELECT only — it can read data but can never accidentally (or maliciously, if compromised) INSERT, UPDATE, DELETE, or DROP anything.

Example: a college's exam-results web app connects to the database using an account that has SELECT on results and INSERT/UPDATE on student_answers, but explicitly has no DROP/ALTER/DELETE privileges anywhere — so even a serious application bug (or a successful SQL-injection attack against it) is structurally limited in the worst-case damage it could do, because the database connection itself lacks the permissions to cause that damage.

Edge Cases and Pitfalls

• Granting ALL PRIVILEGES broadly "to make things work" is a common shortcut that quietly defeats the principle of least privilege — it is much harder to reason about what an over-privileged account can't do than what an appropriately-scoped one can.
• Permissions in most systems are checked at the moment of connection/session and again at each operation — revoking a privilege doesn't necessarily disconnect an already-open session immediately in every engine, which matters for how quickly a permission change actually takes effect.
• GRANT/REVOKE operate on database objects (tables, views, schemas) and, in many systems, on database roles (a named bundle of privileges) rather than only individual users — granting a role to a user is often cleaner than granting many individual privileges directly.

Key Takeaways

• DCL = GRANT / REVOKE — controls who can do what, not what the data or structure looks like.
• The guiding principle is least privilege: give each account only the access it actually needs.
• Roles (named permission bundles) are usually a cleaner unit to manage than granting individual privileges to individual users one at a time.