SQL Server 将列从 varchar(50) 重构为 uniqueidentifier 及周围问题
我的数据库中有一个表message
,其中有近一百万行。它有一个 externalId
列,即 varchar(50)
。其中存储的值是 guid,但我想将此列更新为 uniqueidentifier
。
所以我想我要添加一个新列,即uniqueidentifier
。将所有值复制到此列,然后删除原始列。然后我会将此列重命名为 externalId
。
我的问题是有数百个存储过程等,我需要确保我不会破坏任何东西。我还必须对所有代码进行 grep 并进行更改,以便我们期望的是 Guid 而不是字符串。 (我正在使用 C#)
有人有一些提示或建议吗?
我最好只复制此列而不触及现有列,并使任何对其进行选择的代码使用 guid 列而不是字符串(目前有时会超时!)。我还必须更新插入到该表中的所有代码,以便还插入一个 GUID...)
我喜欢遗留废话.......................
I have a table message
in a database that has almost a million rows. It has a externalId
column which is varchar(50)
. The values stored in it are guid but I want to update this column to be uniqueidentifier
.
So I think I am going to add a new column which is uniqueidentifier
. Copy all the values across to this column and then drop the original column. Then I will rename this column to externalId
.
My problem is there are hundreds of stored procs etc and I need to make sure that I don't break anything. I also have to grep through all the code and make changes so that we expect a Guid and not a string. (I am using C#)
Does anyone have some tips or recommendations?
Would I be better do just duplicate this column and not touch the existing column and make any code that does a select on it use the guid column instead of the string (currently it sometimes times-out!). I would also have to update any code then that inserts into this table to also insert a guid...)
I love legacy crap .......................
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
您可以简单地
风险是,如果列中存储的任何值不是 guid,您将看到如下错误:
You could simply
The risk is that if any of the values stored in the column are not guids, you'll see an error like:
我可能会这样处理:
uniqueidentifier
类型的新列externalIdGuid
externalId
转换为新的 < code>externalIdGuid如果有效,那么您的所有
externalId
都是有效的 GUID - 在这种情况下,您只需将列转换为uniqueidentifier
类型即可:I would probably approach this like so:
externalIdGuid
of typeuniqueidentifier
externalId
into the newexternalIdGuid
If that works, then all your
externalId
are valid GUID's - in that case you could just simply convert the column to typeuniqueidentifier
:我能给你的唯一真正的提示就是一次性完成这一切。不要做这顿饭,因为你会遇到问题。
添加列,复制值,删除旧列,然后重命名新列。然后重新编译所有存储过程。这将为您提供问题区域列表。全部修复并重新编译。如果该部分看起来不错,则继续编写代码。作为遗留问题,您可能会在这里发现许多您甚至不知道的其他问题。
代码将是最困难的区域。最有可能的问题是涉及运行时错误。制定一个涵盖所有内容的测试计划并执行它。
The only real hint I can give you is to do it all at once. Don't do this piece meal as you will have problems.
Add the column, copy the values, drop the old column, and rename the new one. Then recompile all of your stored procedures. This will give you a list of problem areas. Fix them all and recompile. If that part looks good, then move on to the code. Being legacy you'll probably find a number of other issues here that you didn't even know about.
The code is going to be the toughest area. Most likely the problems are going to involve runtime errors. Make a test plan that covers absolutely everything and go through it.
我根本不会这样做。是的,如果它一开始就是一个唯一标识符,那就更好了,但除非你有一个特定的问题,如果不改变它就无法克服,那么你的用户获得的价值是什么。
如果你决定这么做的话。您可以查询sys.procedures。它比使用 syscomments 或 INFORMATION_SCHEMA.ROUTINES 更好
I wouldn't do this at all. Yes it would have been better if it had been a Uniqueidentifier to begin with but unless you have a specific problem that can't be overcome without changing it what's the value that you're users are getting.
If you do decide to do it. You can query the sys.procedures. Its better than using syscomments or INFORMATION_SCHEMA.ROUTINES
事实证明,当我在该列上放置非聚集索引后,速度非常快。我刚刚在 Sql Server Management Studio 中选择了查询,然后单击“在数据库引擎优化顾问中分析查询”。它告诉我该列需要一个索引,甚至生成您需要添加它的 SQL 脚本:)
Well turns out after I put a Non Clustered index on that column its pretty fast. I just selected the query in Sql Server management studio and rught clicked and went 'Analyze Query in Database Engine Tuning Advisor'. It told me that this column needs an index and even generates the SQL script you need to add it :)
检查开发系统上是否有任何问题的一种非常快速且安全的方法是将表重命名为 message_legacy 并创建一个名为 message 的视图,该视图将 externalid 转换为 uniqueidentifier。这不应该扰乱底层数据,但会为您提供一个可行的界面来查看存储过程和其他代码的行为方式。请记住向该视图授予与表上相同的权限,否则您可能会收到与权限相关的错误,而不是与类型相关的错误,而这正是您真正想要测试的。
如果获得可接受的结果,请继续更改列定义。就我个人而言,我会重命名该表,创建一个更改列类型的新表,插入 new_table select * from old_table,然后删除旧表。
祝你好运!
One very quick and safe way to check if you break anything on your dev system is to rename your table the message_legacy and make a view called message which casts externalid to uniqueidentifier. That shouldn't mess with the underlying data but will give you a workable interface to see how your stored procs and other code will behave. Remember to grant the same permissions to this view as you have on the table or you might get errors which are permission related instead of type related, which is what you really want to test.
If you get an acceptable result, then go ahead and change the column definition. Personally, I'd rename the table, create a new table with the column type changed, insert into new_table select * from old_table, then drop the old table.
Good luck!