在数据库字段中分隔数据确定

时间:2011-06-23 15:32:21

标签: database database-design

是否可以在数据库字段中分隔数据?

这样的东西
create table column_names (
  id int identity (1,1) PRIMARY KEY,
  column_name varchar(5000)
);

然后按如下方式将数据存储在其中

INSERT INTO column_names (column_name) VALUES ('stocknum|name|price');

2 个答案:

答案 0 :(得分:8)

没有。这很糟糕:

  • 为了创建新的查询,您必须追踪事物的存储方式。

  • 加入价格或名称或stocknum的查询将会讨厌

  • 数据库无法为数据分配数据类型或对其进行验证

  • 您现在无法对任何此类数据创建约束

基本上你正在颠覆RDBMS的方案来处理和构建你自己的东西,所以你限制了RDBMS工具可以帮助你的程度,并且你让新系统更难理解系统。

我能想到的这种系统的唯一可能优势是它可以作为一种解决方法,以避免处理完全不可能的DBA,他否决所有架构更改,无论优点如何。不幸的是,这可能发生。

当然,所有事情都有例外。我目前正处于审计日志要求非常严格的项目中。日志记录是对数据库完成的,我们使用分隔字段来存储字段,因为应用程序永远不会与这些数据进行交互,它会被写入一次并保持不变。

答案 1 :(得分:4)

几乎肯定不会。

  1. 违反了规范化原则。存储在特定列的特定行中的数据应该是原子的 - 您不应该将数据解析为较小的组件部分。
  2. 这使得获得可接受的性能变得更加困难。查询此表的每一段代码都需要知道如何解析数据,这通常意味着需要从磁盘读取更多数据并可能通过网络发送到客户端。每个必须解析此数据的查询都必须更复杂,这往往会导致查询优化器感到悲伤。连续数据通常不能有效地为搜索编制索引 - 您必须使用自定义分隔符而不是字符串上的标准索引来执行类似全文索引的操作。如果您必须更新其中一个分隔值(即因为产品名称更改),那些更新将必须扫描表中的每一行,解析数据,决定是否实际更新行,然后更新一大堆。
  3. 它使应用程序更加脆弱。当有人决定包含|时会发生什么例如,name属性中的字符?即使您在规范中指定了可选的机箱(即,如果整个令牌都用双引号括起来,则允许),实际解析此列的代码的哪一部分将实现并正确测试?