这是构建我的Sql Server数据库的坏方法吗?

时间:2009-05-27 23:53:00

标签: sql architecture views join

我有一个包含几列的表,然后是2个最终(可空)列,这些列是varbinary(实际上,它们是SQL 2008地理类型,但我希望保持此post数据库不可知)。

我用大约200,000行击中了大约5​​00mb。 varbinary是问题 - 我需要数据。

所以,我想知道如果我做以下事情是不是很糟糕: -

  • 创建单独的FILEGROUP:SpatialData.mdf
  • 创建一个新表,分配给该新文件组。
  • 将所有空间数据(读取:最后两个字段)移出原始表并进入新表。新表有一个反映原始表的外键。
  • 创建一个代表两个表的视图。

现在,视图将是左外连接,因为关系是:新表与原始表具有零或一行关系。

EG。

原始表

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关系,这会影响性能吗?

为什么拆分数据?我现在需要将实时DB下载到我们的开发服务器。我们并不太关心这两个空间领域,所以没有它们就好了。因此,要下载的数据库的大小要小得多。

思想?

2 个答案:

答案 0 :(得分:1)

使用表分区不是创建第二个表,连接和创建视图,而是使用SQL Server 2005/2008可以实现更好的解决方案。在我的记忆中,您可以垂直分区表,并将一些列(即地理空间列)放在一个文件组中,而将其余列放在另一个文件组中。 SQL Server将为您处理其余部分,您不需要打扰连接,也不需要视图。

答案 1 :(得分:1)

根据我的经验,您所描述的方法实际上相当普遍。从技术上讲,如果您要将数据库规范化到最大程度,那么您将拥有大量类似的表,因为规范化中的一个(通常未使用的)步骤包括确保没有列具有NULL值。

在实践中,它通常不会达到这种程度,但对于人口稀少的一列(或多列)来说,将它分开并不是一个坏主意。只要表共享相同的主键(当然会被索引),性能应该不是问题。