我们有一个进程获取表列和每个应具有的大小(varchar类型)的列表,并修改它们以确保它具有已定义的大小。检查列大小+直接修改表或更改表
在我们直接执行ALTER TABLE到列表中的每个列的实际执行...
会运行速度更快,如果我们第一次检查,如果列大小是正确的尺寸不同,然后才做改变表格?
据统计有4000左右的表列检查和20列需要最多修正...
我们有一个进程获取表列和每个应具有的大小(varchar类型)的列表,并修改它们以确保它具有已定义的大小。检查列大小+直接修改表或更改表
在我们直接执行ALTER TABLE到列表中的每个列的实际执行...
会运行速度更快,如果我们第一次检查,如果列大小是正确的尺寸不同,然后才做改变表格?
据统计有4000左右的表列检查和20列需要最多修正...
最终我们实现ALTER TABLE前检查,有它在哪里necesary执行ALTER命令的情况下低%的proccess尤其是运行速度更快
编辑:为了反映意见:
什么是快取决于如何昂贵的操作修改列连同需要更改的表中有多少列。例如改变一列零值不是很花钱。但是如果你有很多数据,并且表中有许多列,那么可以更好地为新表副本创建一个表。根据您的数据库的指标决定这一点,并不总是一个正确和错误的问题。
您可能会创建一些动态sql来创建sql,以改变不适合大小的列的长度。这应该是最快的方法。
类似:
SELECT
'some decision logic...' -- substitute values as needed
FROM
INFORMATION_SCHEMA.COLUMNS
WHERE
ISNULL(CHARACTER_MAXIMUM_LENGTH, 5) <> 5
AND DATA_TYPE = 'NVARCHAR'
而且你可以在你想解释,表的大小,列的数据大小号(组)等
SQL服务器已经存储的指标增加所有这些元数据,你可以查询它。似乎错误的是在自定义表格中复制此信息并在其上运行光标。我想你提到的问题是,复制这些信息可能会导致陈旧的数据,而sql服务器元数据将始终保持最新状态。为了使它更容易,您可以创建元数据视图以使其易于消费。但这是一个不同的问题。
表列及其大小都存储在特定的表和我们循环遍历它 – VSP
如果列和它们的大小可以作为单个行集访问,那么在行集上执行查询并过滤掉不需要更改的列应该是微不足道的。 *然后*您将继续像现在一样循环执行剩余的行。那有意义吗? –