good one. thank you for posting.

I guess it is a long fight because neither way it cannot be proved 100% that it is a DML or DDL depending on the proper action it executes underneath; this link says otherwise http://msdn.microsoft.com/en-us/library/ms175519(v=sql.105).aspx (see under the schema locks section)

(This will be another interesting discussion )

For me it is a DDL (based of my feelings :hehe:)

- it is the quickest way get the data deleted on the single table

- like s/d/u/i statements truncate is not commonly used like others

- in general practice, as truncate removes all the records and no one wants to remove all the records from the table, only if any exceptional case where an SA(sql) or DBA wants to use on some table they think

- in the architecture (generally saying) most of the tables are connected with PK/FK, so again if some one wants to use truncate why would they remove/delete the relationship and then use truncate and then put the relationship back just the sake of deleting?

- as the truncate can be used on single table; so that means that table would be a standalone and it may or may not be storing some kind of data where it is less important like archived log activity of the user stored on a separate table on a different file_group... something like that. (I am not questioning the high standard of the design and how properly each object is configured to use, but just a low point making based on my feelings)