假设空格在字段数据中并不重要,那么在插入、更新或从表中选择数据时修剪空格是否是一种好习惯?
我想不同的数据库以不同的方式实现对空格的处理,因此为了避免这种头痛,我想我应该禁止在任何字段数据中使用前导和尾随空格。
你怎么看?
假设空格在字段数据中并不重要,那么在插入、更新或从表中选择数据时修剪空格是否是一种好习惯?
我想不同的数据库以不同的方式实现对空格的处理,因此为了避免这种头痛,我想我应该禁止在任何字段数据中使用前导和尾随空格。
你怎么看?
如果前导和尾随空格不重要,那么我会在插入或更新之前将它们剪掉。那么选择上应该没有不必要的空格。
这带来了一些好处。行中所需的空间更少意味着数据页中可能存在更多行,从而导致更快的数据检索(检索更少)。此外,您不会不断地修剪 SELECT 上的数据。(这里使用 DRY [不要重复自己] 原则)
我会说在大多数情况下这是一个很好的做法。如果您可以自信地说数据一文不值,并且删除它的成本很小,那么就删除它。
我认为这是一个很好的做法。没有什么比花一个小时、一天或任何时间来追查一个最终由用户输入额外空格引起的错误更令人心碎的事情了。额外的空间可能导致报告出现细微的错误,或者可能导致程序某处出现异常,除非您在日志和错误消息中的每个打印语句周围都放置了括号,否则您可能不会意识到它的存在。即使您在使用从数据库中提取的数据之前虔诚地修剪空间,也要为您的数据的未来用户提供帮助,并在将其放入之前修剪。
我会修剪它们(除非您实际上使用的是空白数据),这仅仅是因为它很容易做到,而且如果它们确实在您的代码中引起问题,则特别难以发现空格。
对于典型的数据实体,不值得开销。有什么理由你认为你会得到很多额外的空白行吗?如果您是,那么修剪以减小数据库大小可能是个好主意,否则不会。
尾随空格特别成问题,特别是在 ANSI_NULLS 行为方面。
例如,colname = '1' 可以返回 true,而 colname like '1' 返回 false
因此,鉴于 varchar 列中的尾随空格不明确,截断很可能是更可取的,特别是因为此类数据中没有真实信息,并且它会在 SQL Server 的行为中产生歧义。
例如,看一下这个问题的讨论:
处理尾随空格是一个很好的做法。这是数据库中的常见错误,它会导致长时间搜索错误。
在插入/更新期间修剪它们,或者像这样向表中添加一个检查子句:
ALTER TABLE tblData
WITH CHECK ADD CONSTRAINT CK_Spaces_tblData
CHECK
(
datalength(USERID)>(0)
AND datalength(ltrim(rtrim(USERID)))=datalength(USERID)
)
在这种情况下,用户在尝试插入或更新时会遇到错误。
这样做的好处是用户知道错误。很多时候,他们已经在一些 Excel 工作表中有尾随空格,然后他们复制粘贴。所以他们知道这一点是件好事,这样他们也可以在他们的 Excel 表格中删除错误。