Teradata DELETE ALL 与 DROP+CREATE
Teradata DELETE ALL vs DROP+CREATE
我最近被分配到一个使用 Teradata 的项目。
我被告知要严格使用 DROP+CREATE 而不是 DELETE ALL，因为后者 "leaves some space allocated someway"。这对我来说是违反直觉的，我认为这可能是错误的。我在网上搜索了两种方法之间的比较，但一无所获。
这只会加强我的信念，即 DELETE ALL 不会遇到上述问题。
但是，如果是这样的话，我必须证明它（无论是实践上还是理论上）。
所以，我的问题是：这两种方法在 space 分配上有区别吗？如果不是，是否有官方文件（用户指南、技术规范等）证明这一点？
谢谢！
这里有一个讨论：http://teradataforum.com/teradata/20120403_105705.htm 关于相同的主题（尽管它并没有真正回答“留下一些 space 分配到某处”部分）。他们实际上推荐 DELETE ALL 但出于其他（性能）原因：
我会引用以防 link 死机：
"Delete all" will be quicker, although being practical there often isn't a lot of difference in the performance of them.
However, especially for a process that is run regularly (say a daily batch process) then I recommend the "delete all" approach. This will do less work as it only removes the data and leaves the definition in place. Remember that if you remove the definition then this requires accessing multiple dictionary tables, and of course you then have to access those same tables (typically) when you re-create the object.
Apart from the performance aspect, the downside of the drop/create approach is that every time you create an object Teradata inserts "default rows" into the AccessRights table, even if subsequent access to the object is controlled via Role security and/or database level security. As you may well know the AccessRights table can easily get large and very skewed. In my experience many sites have a process which cleans this table on a regular basis, removing redundant rows. If your (typically batch) processes regularly drop/create objects, then you're simply adding rows into the table which have previously been removed by a clean process, and which will be removed in the future by the same process. This all sounds like a complete waste of time to me.
您的印象是正确的，您没有在任何地方找到任何对 "DELETE leaves some space allocated" 的引用，因为它完全是错误的:-)
DELETE ALL 类似于其他 DBMS 中的 TRUNCATE，在大多数情况下使用 fastpath 处理：
首先，您不能在 Teradata 中的一个事务中执行 DROP/CREATE（在 Oracle 中，日常 DDL 还存在其他问题）因此，当 ETL 过程变得复杂时，您可能最终会依赖于更重要的业务流程取决于不太重要的事情（比如您可能会看到 客户 table 空无一人 只是因为利率没有刷新
或者您 仅在一个次要列中有超过 varchar 值）
我的意见：使用事务和模块化编程。在 Teradata 中，这意味着尽可能避免 DDL 并使用 DELETE/UPDATE/MERGE/INSERT 而不是 DROP/CREATE.
我们在 Postgres 中的情况略有不同，其中 DDL 语句是事务性的。
我最近被分配到一个使用 Teradata 的项目。 我被告知要严格使用 DROP+CREATE 而不是 DELETE ALL，因为后者 "leaves some space allocated someway"。这对我来说是违反直觉的，我认为这可能是错误的。我在网上搜索了两种方法之间的比较，但一无所获。 这只会加强我的信念，即 DELETE ALL 不会遇到上述问题。 但是，如果是这样的话，我必须证明它（无论是实践上还是理论上）。
所以，我的问题是：这两种方法在 space 分配上有区别吗？如果不是，是否有官方文件（用户指南、技术规范等）证明这一点？
谢谢！
这里有一个讨论：http://teradataforum.com/teradata/20120403_105705.htm 关于相同的主题（尽管它并没有真正回答“留下一些 space 分配到某处”部分）。他们实际上推荐 DELETE ALL 但出于其他（性能）原因：
我会引用以防 link 死机：
"Delete all" will be quicker, although being practical there often isn't a lot of difference in the performance of them.
However, especially for a process that is run regularly (say a daily batch process) then I recommend the "delete all" approach. This will do less work as it only removes the data and leaves the definition in place. Remember that if you remove the definition then this requires accessing multiple dictionary tables, and of course you then have to access those same tables (typically) when you re-create the object.
Apart from the performance aspect, the downside of the drop/create approach is that every time you create an object Teradata inserts "default rows" into the AccessRights table, even if subsequent access to the object is controlled via Role security and/or database level security. As you may well know the AccessRights table can easily get large and very skewed. In my experience many sites have a process which cleans this table on a regular basis, removing redundant rows. If your (typically batch) processes regularly drop/create objects, then you're simply adding rows into the table which have previously been removed by a clean process, and which will be removed in the future by the same process. This all sounds like a complete waste of time to me.
您的印象是正确的，您没有在任何地方找到任何对 "DELETE leaves some space allocated" 的引用，因为它完全是错误的:-)
DELETE ALL 类似于其他 DBMS 中的 TRUNCATE，在大多数情况下使用 fastpath 处理：
首先，您不能在 Teradata 中的一个事务中执行 DROP/CREATE（在 Oracle 中，日常 DDL 还存在其他问题）因此，当 ETL 过程变得复杂时，您可能最终会依赖于更重要的业务流程取决于不太重要的事情（比如您可能会看到 客户 table 空无一人 只是因为利率没有刷新 或者您 仅在一个次要列中有超过 varchar 值）
我的意见：使用事务和模块化编程。在 Teradata 中，这意味着尽可能避免 DDL 并使用 DELETE/UPDATE/MERGE/INSERT 而不是 DROP/CREATE.
我们在 Postgres 中的情况略有不同，其中 DDL 语句是事务性的。