1

我有一个表，其中包含几列，然后是 2 个最终（可为空）列，它们是 varbinary（实际上，它们是 SQL 2008 地理类型，但我想让这个帖子数据库不可知）。

我已经用大约 200K 行达到了大约 500mb。varbinary 是问题所在 - 我需要数据。

所以，我想知道如果我执行以下操作是否不好：-

  • 创建一个单独的文件组：SpatialData.mdf
  • 创建一个新表，分配给该新文件组。
  • 将所有空间数据（读取：最后两个字段）从原始表中移出到新表中。新表具有针对原始表的外键。
  • 创建一个表示两个表的视图。

现在，视图将是左外连接，因为关系是：新表与原始表的关系为零或一。

例如。

原始表

FooId INT PK NOT NULL IDENTITY
Blah VARCHAR(..) NOT NULL
Boo WHATEVER NOT NULL

新表

FooID PK FK NOT NULL
Spatial_A VARBINARY(MAX)/GEOGRAPHY
Spatial_B VARBINARY(MAX)/GEOGRAPHY

我想知道这是否不好的原因是视图以及视图如何在空间表上进行连接。我会经常使用视图。目前，我只是对原始表进行查询（因为新表还不存在）。通过添加此连接和 PK/FK 关系，这会影响性能吗？

为什么要拆分数据？我需要不时将实时数据库下载到我们的开发服务器。我们并不太关心这两个空间场，所以没有它们也可以。因此，要下载的数据库的大小会小很多。

想法？

4

2 回答 2

1

与创建第二个表、连接和创建视图不同，SQL Server 2005/2008 可能的更好解决方案是使用表分区。我记得，您可以对表进行垂直分区，并将一些列（即您的地理空间列）放在一个文件组中，而将其余列放在另一个文件组中。SQL Server 会为您处理其余的事情，您不需要为连接而烦恼，也不需要视图。

于 2009-05-28T00:03:32.977 回答
1

您描述的方法实际上在我的经验中相当普遍。从技术上讲，如果您要将数据库规范化到最大程度，您将拥有很多这样的表，因为规范化中的一个（通常不使用）步骤包括确保没有列具有 NULL 值。

在实践中，它通常不会执行到那种程度，但是对于人口稀少的一列（或多列），将其分开并不是一个坏主意。只要表共享相同的主键（当然会被索引），性能应该不是问题。

于 2009-05-28T02:30:15.630 回答