Delete v Truncate

  • venkat9.sql

    Mr or Mrs. 500

    Points: 510

    sknox (3/21/2013)


    Mechanically, TRUNCATE TABLE is DDL: It doesn't act on the row data, but on the metadata (this is why you need ddladmin rights.)

    But functionally it's DML: its function is to delete data -- except when you get to the identity thing: that's DDL again.

    So really, it's both: it's a DDL mechanism with a DML purpose.

    I agree with you...

    I have gone through this DDL vs DML command for TRUNCATE long time back... I went with the BOL/popular answer (dependent on the population I guess)

    ___________________________________________________________________
    If I can answer a question then anyone can answer it..trying to reverse the logic.. :hehe:

  • SQLRNNR

    SSC Guru

    Points: 281210

    Hugo Kornelis (3/21/2013)


    (My original reply was much longer, but I lost it due to that stupid SQLServerCentral bug that tends to eat a reply when you worked on it for a long time. And I had forgotten to copy/paste it somewhere safe first. I don't feel like reconstructing that long reply, so here's the abridged version)

    Stuart Davies (3/21/2013)


    Thanks for the question - good reminder of the basics.

    It appears that quite a few here needed reminding of the differences - 40% wrong at the moment.

    I'm not at all surprised. The percentages for the identity and trigger subquestions show that almost everyone had them right; the problem is in the DDL/DML part. And rightly so.

    The only reason I got points for this question is that I realized that if the author had considered truncate to be DML, *two* extra options would have been right. And the question texts said to check 3 answers, not 4. But I do disagree with this answer, and I do disagree with the parts in Books Online that describe trunacte table as DDL.

    DDL is language that describes data structures. Truncate table does not in any way change the schema of a table. It only removes all data from a table and (for tables with an identity column) resets the "next value" (not the original seed or the increment) of the identity property.

    DML is language that inserted, updates, or deletes data. That (deleting data) is exactly what TRUNCATE TABLE does!

    +1

    I disagree that truncate is a DDL command as well.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • TomThomson

    SSC Guru

    Points: 104763

    Well, I got it wrong. Since TRUNCATE TABLE is listed under DDL commands in BOL, while the BOL page on Lock Modes clearly states that TRUNCATE TABLE is a DDL command, it is clear that according to BOL TRUNCATE TABLE is both a DDL command and a DML, so according to BOL 6 of the answers are correct and we are playing "guess which 3 of the 5 correct options you are supposed to choose". That doesn't mean I think there's anything wrong with the question, or indeed with the answer, since elsewhere in BOL it says that DML and DDL do not overlap - BOL contradicts itself, so a question in this area is going to lead to discussion/debate about this and the discussion and debate are definitely worthwhile.

    However, if one had to separate DML and DDL so that no command can be both, my view would be that TRUNCAE TABLE is a DML statement. The argument that it isn't is usually based on the idea that it resets the current identity value to NULL if the table has an identity column. However, the same argument would make INSERT a DDL command when executed with IDENTITY INSERT off - such an insert alters exactly the same piece of metadata, the current identity value, so that argument clearly doesn't hold water. Neither does the argument that TRUNCATE is DDL because it takes a Sch-M lock - BOL says that some DML statements, including TRUNCATE, take that lock so it is clear that it is recognised that other DML commands may take Sch-M locks when the need to, in cases where MS has chosen to hold data about the current state of the table along with the schema metadata. Unlike the fixed identity seed the current identity value is not schema metadata, since it can be modified by data manipulation commands (INSERT) whereas the seed can only be modified by schema manipulation commands (DROP and recreate the table, or DROP and recreate the column using ALTER TABLE): despite the unfortunate terminology of a DBCC CHECKIDENT parameter that DBCC command has no effect on the schema metadata.

    Anyway, it's a good fun question that allows hoary old dinosaurs like to ramble on, so well done Naseer Ahmad. Keep on posing questions!

    Tom

  • Anipaul

    SSC-Insane

    Points: 24681

    Good basic question....

  • Bangla

    Hall of Fame

    Points: 3137

    Lot of us has problem with basics? So many wrong?;-)

  • Keld Laursen (SEGES)

    SSC Eights!

    Points: 838

    Nadrek (3/21/2013)


    I also had to think about DML vs. DDL, because TRUNCATE is more or less equivalent to:

    DELETE FROM + Reset Identity

    and

    DROP TABLE(etc.) + CREATE TABLE(etc.)

    For me, the clincher was the ALTER TABLE permissions requirements of TRUNCATE - which I personally absolutely disagree with. I'd much rather see users able to use TRUNCATE based on perhaps

    DELETE permission plus a new RESET IDENTITY permission, which being prohibited from creating tables, dropping tables, adding columns, redefining columns, etc.

    +1

    But interesting discussion on this subject.

  • Toreador

    SSChampion

    Points: 11225

    On reflection - given that you cannot use truncate on a table referenced by foreign keys - it seems more like it is actually doing a drop/create. Which would make it DDL. Of course, as I think Hugo said already, this is about the implementation of the functionality rather than the functionality itself.

  • TomThomson

    SSC Guru

    Points: 104763

    Toreador (3/22/2013)


    On reflection - given that you cannot use truncate on a table referenced by foreign keys - it seems more like it is actually doing a drop/create. Which would make it DDL. Of course, as I think Hugo said already, this is about the implementation of the functionality rather than the functionality itself.

    The reason that you can't do it on a table referenced by foreign keys is that since it's done at the page level without regard to rows it is not possible to action the CASCADE, SET NULL, SET DEFAULT, or NO ACTION (= throw error) actions specified by the foreign key constrain as these have to be done at the row level. So allowing TRUNCATE on the referenced table would effectively say that the constraint wasn't a constraint at all because it wouldn't constrain anything. It's nothing at all to do with it using drop-create, which is not what it does.

    In fact drop-create would be a rather silly implementation method for truncate, since the metadata for all check constraints, default constraints, and indexes would be destroyed by dropping the table and would have to be recreated, all views referencing the table would have to be dropped before dropping the table and recreated after recreating the table, metadata for indexes on those views would be destroyed and would have to be recreated, the same goes for views referencing those views and so on recursively, so potentially quite a big recreate script would have to be built as part of the dropping process (all this would be new code, as drop table doesn't currently have to do any of it) and stored somewhere and run, risking making truncate rather slower than it should be as well as a pretty nightmarish thing to try to implement.

    Tom

  • kapil_kk

    SSC-Insane

    Points: 21316

    lolz of discussion 😛

    ------------------------------------------------

    Visit my blog :

    http://sqlpassionate.blogspot.in/

    _______________________________________________________________
    To get quick answer follow this link:
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

  • webrunner

    One Orange Chip

    Points: 29866

    I think this is the first multiple-choice (multiple checkbox) QOTD I've ever gotten correct. Basic or not, I'm proud of myself. :hehe:

    - webrunner

    -------------------
    A SQL query walks into a bar and sees two tables. He walks up to them and says Can I join you?
    Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

  • David Conn

    SSCertifiable

    Points: 5511

    My Vote is for DML. I see a Verb, a doing word not a Definition.

    Now where do I get my 2 Pints from ? I'm thirsty.

    David

  • DannyY

    SSChasing Mays

    Points: 606

    Choose 3, but actually 4 answers...

    Or I'm too tired...

  • sqlnaive

    SSCoach

    Points: 17435

    An easy one. but good basic exercise. 🙂

  • Arno Kwetters

    Hall of Fame

    Points: 3335

    Nice question.

    I knew it, but it's funny to realise.

  • SQL_Hunt

    SSC-Dedicated

    Points: 33261

    'TRUNCATE does not fire triggers, but DELETE does." This option does not seem like correct, instead it should be that "Truncate doesn't fire delete triggers." Rest all options seem to be correct. PErhaps, I scored 2 marks

    Thanks.

Viewing 15 posts - 31 through 45 (of 45 total)

You must be logged in to reply to this topic. Login to reply