【发布时间】:2012-10-09 21:09:29
【问题描述】:
我正在开发一个车队调度应用程序并寻找一种有效的方法来存储地理位置之间的距离。
应用程序代码以二维数组的形式访问矩阵double[,]。
为了让矩阵持久化,我目前将矩阵序列化为字符串。序列化后是这样的:
"1 4 9 8 3 6 \n
5 6 7 9 3 6 \n
34 4 5 6 6 7 \n"
然后将其存储在 SQL Server 2008 数据库中 varchar(max) 类型的列中。但是,我想知道这个字符串是否会变得太大。
假设每个条目都有一位数字并且忽略空格和“\n”,理论上我可以将大约 46000 个位置的距离(2 147 483 647 的平方根 - varchar(max) 的大小)存储在一个条目。这在我的上下文中就足够了。
这种方法有什么严重的缺点吗?将距离存储在一个额外的表中会更好吗,其中每一行包含两个位置之间的一个距离?
如果我们的应用程序的 100 个用户分别存储 1000 个位置,我将在这样的表中有 100000000 = 100 * 1000 * 1000 行......
【问题讨论】:
-
您为什么认为需要以这种非关系方式存储数据? (关系规则#1:列中没有数组,只有标量)。几乎不可能以任何效率查询矩阵的内容。
-
我不需要查询矩阵。如果用户使用该应用程序,所有距离都会立即加载到 double[,]-array 中。我不想选择单个距离,只选择整个矩阵,这确实是必要的。但是,如果某些距离被更新,我必须重建整个字符串。
-
如果您确实需要将数据视为服务器上的黑匣子,那么可以,这样会更快。但是,每当有人登录或更改某些内容时,尝试在客户端和服务器之间来回移动整个 2GB+ 无论如何都会非常缓慢。如果设计允许客户端一次使用和/或更改更少的数据,您会做得更好。
-
VARCHAR(MAX)类型的列的最大大小为 2 GB 的存储空间 - 2 十亿 个字符。 Leo Tolstoj 的战争与和平 是一本 1'440 页的书,包含大约 600'000 个字——因此可能是 600 万个字符——四舍五入。因此,您可以在每个VARCHAR(MAX)列中粘贴 300 多份完整的 战争与和平 书。够好吗? -
用另一种方式把@RBarryYoung 的 cmets - 你为什么要把它存储在数据库中,为什么不把它存储为一个平面文件,如果你只是想把它当作一个块文字?
标签: sql-server-2008 database-design varcharmax