删除重复的重复字符
我的存储过程中有一个字符串,例如 ',,,sam,,bob,'
或 ',,,'
从上面的字符串中我必须从中删除多个逗号,它必须看起来像 'sam,bob,'
或仅当 ',,,'
时 ''
。 我必须仅使用 Sql Server 函数。 我使用 Sql Server 2008 和 .Net 3.5
提前致谢。
I have a string in my stored proc like ',,,sam,,bob,'
or ',,,'
from the above string I have to delete multiple commas from it, it must look like'sam,bob,'
or only if ',,,'
then ''
.
I must use only Sql Server Functions.
Im using Sql Server 2008 and .Net 3.5
Thanks in advance.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
这适用于仅包含逗号或最多包含 398 个连续逗号的字符串。
如果您需要更多,请在顶部添加额外的 2 的幂;如果您需要较少,请从顶部删除。每个阶段的注释表示该阶段无法成功处理的最小数量。
所有注释行都采用这种格式
因此,要使用另一个
REPLICATE(',',32),',')
阶段向上扩展该系列,这样就可以处理最多 11,806 个字符的逗号部分。
This works for strings that are exclusively commas or have up to 398 contiguous commas.
Add extra powers of 2 at the top if you need more or remove from the top if you need less. The comments by each stage indicate the smallest number that this stage will not deal with successfully.
All the comment lines are in this format
So to extend the series upwards with another
REPLICATE(',',32),',')
stageSo that would deal with sections of commas up to 11,806 characters.
我建议使用 UDF 来完成此操作。由于我要建议的 UDF 不涉及任何表,因此性能应该相当不错。
您可以像这样测试该功能:
I would suggest a UDF to do this. Since the UDF I am about to suggest doesn't touch any tables, the performance should be pretty good.
You can test the function like this:
试试这个
try this
我同意“仅内存”标量 UDF 相当快。事实上,我实际上使用了 George 的标量 UDF 之一,它解决了“初始大写”问题,以证明有时“基于集合”的代码不是总是最好的方法。
然而,马丁·史密斯(Martin Smith)(该帖子的另一位发帖者)绝对走在正确的道路上。在这种情况下,“Set Based”仍然是出路。当然,任何人都可以对性能提出未经证实的主张,因此让我们通过性能演示来加热这一点。
为了进行演示,我们首先需要一些测试数据。有很多测试数据,因为我们要测试的两个函数都运行得非常快。这是构建一百万行测试表的代码。
无需在这里重新发布乔治的出色功能,但我确实需要发布我的功能。以下函数产生与 George 相同的结果。它看起来像一个“iTVF”(内联表值函数),但它只返回一个值。这就是为什么微软称它们为“内联标量函数”(我简称为“iSF”)。
首先,让我们测试一下 George 的标量 UDF。请阅读有关我们为何不使用 SET STATISTICS TIME ON 的评论。
以下是“ Fiver”运行的返回结果...
现在,我们将运行“iSF”版本...
以下是该运行的结果。
我的观点并不是说乔治的代码很糟糕。一点也不。事实上,当没有“单一查询”解决方案时,我使用标量 UDF。我还将声明并支持乔治,并不是所有的“单一查询”解决方案总是最好的。
当涉及到 UDF 时,请不要停止寻找它们。 ;-)
I agree that "memory only" Scalar UDF's are quite fast. In fact, I actually used one of George's Scalar UDFs, which solved the "Initial Caps" problem, to demonstrate that sometimes "Set Based" code ISN'T always the best way to go.
However, Martin Smith (another poster on this very thread) was definitely on the right track. In this case, "Set Based" is still the way to go. Of course, anyone can make an unsubstantiated claim as to performance so let's heat this up with a performance demonstration.
To demonstrate, we first need some test data. A LOT of test data because both of the functions we're going to test run nasty fast. Here's the code to build a million row test table.
No need to repost George's fine function here but I do need to post mine. The following function produces the same result as George's does. It looks like an "iTVF" (Inline Table Valued Function) and it is but it only returns one value. That's why Microsoft calls them "Inline Scalar Functions" (I call them "iSFs" for short).
First, let's test George's Scalar UDF. Please read the comments about why we're not using SET STATISTICS TIME ON here.
Here are the returns from that "fiver" run...
Now, we'll run the "iSF" version...
Here are the results from that run.
My point ISN'T that George's code is bad. Not at all. In fact, I use Scalar UDFs when there is no "single query" solution. I'll also state and back George up by saying that not all "single query" solutions are always the best.
Just don't stop looking for them when it comes to UDFs. ;-)
你的解决方案很好,但
所以我基于Marcin解决方案集的通用代码编写了用于替换每种声明类型的重复项:
您可以在重复字符串中声明每种字符以及@Replacement 中的每个替换字符串。
恕我直言,额外的好处是我仅在输入字符串的最大长度范围内搜索替换
Your solutions are good but
so i wrote based on Marcin solution set-based universal code for replacement of every declared kind of duplicates:
You can declare every kind of char in Duplicate string and every replacement string in @Replacement.
Additional gain IMHO is that i search for replacement only in range of maximum length of input string
你可以尝试
You could try