在 Sql Server 2008 中 1 个几何列与 4 个小数列的相对性能是多少？

发布于 2025-01-07 08:19:29 字数 201 浏览 1 评论 0原文

我需要在 SQL Server 2008 数据库中表示~~四边形~~ 矩形表面的尺寸。我需要根据不同点之间的距离和表面的总面积来执行查询。

使用几何数据类型或 4 个小数列我的性能会更好吗？为什么？

如果在这种情况下几何数据类型是不必要的，那么使用几何数据类型需要多少复杂的几何形状才能有意义？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

梦罢 2025-01-14 08:19:29

我没有使用过几何数据类型，也从来没有理由去阅读它。即便如此，在我看来，如果您只是对一个简单的几何对象进行基本算术运算，那么普通的旧 SQL 数据类型应该非常有效，特别是如果您为经常使用的计算添加一些计算列。

例如：

--DROP TABLE MyTable
CREATE TABLE MyTable
 (
   X1  decimal  not null
  ,Y1  decimal  not null
  ,X2  decimal  not null
  ,Y2  decimal  not null
  ,Area as abs((X2-X1) * (Y2-Y1))
  ,XLength as abs((X2 - X1))
  ,YLength as abs((Y2 - Y1))
  ,Diagonal as sqrt(power(abs((X2 - X1)), 2) + power(abs((Y2 - Y1)), 2))
 )

INSERT MyTable values (1,1,4,5)
INSERT MyTable values (4,5,1,1)
INSERT MyTable values (0,0,3,3)

SELECT * from MyTable

丑陋的计算，但除非实际引用它们（或者除非您选择对它们建立索引），否则它们不会被执行。我没有统计数据，但通过几何数据类型执行相同的操作可能意味着访问很少使用的数学子例程，可能嵌入在系统 CLR 程序集中，而且我只是看不出它比裸机快得多-bones SQL 算术例程。

我刚刚查看了 BOL 中的几何数据类型。 (a) 响动！（乙）酷！查看“几何数据类型方法参考”下的条目 (在线，但您想要查看此条目下的扩展树视图。）如果这就是您需要的功能，请务必使用几何数据类型，但为了简单处理，我会坚持使用 knucklescraper 数据类型。

I have not used the geometry datatype, and have never had reason to read up on it. Even so, it seems to me that if you’re just doing basic arithmatic on a simple geometric object, the mundane old SQL datatypes should be quite effiicient, particularly if you toss in some calculated columns for frequently used calculations.

For example:

--DROP TABLE MyTable
CREATE TABLE MyTable
 (
   X1  decimal  not null
  ,Y1  decimal  not null
  ,X2  decimal  not null
  ,Y2  decimal  not null
  ,Area as abs((X2-X1) * (Y2-Y1))
  ,XLength as abs((X2 - X1))
  ,YLength as abs((Y2 - Y1))
  ,Diagonal as sqrt(power(abs((X2 - X1)), 2) + power(abs((Y2 - Y1)), 2))
 )

INSERT MyTable values (1,1,4,5)
INSERT MyTable values (4,5,1,1)
INSERT MyTable values (0,0,3,3)

SELECT * from MyTable

Ugly calculations, but they won’t be performed unless and until they are actually referenced (or unless you choose to index them). I have no statistics, but performing the same operations via the Geometry datatype probably means accessing rarely used mathematical subroutines, possibly embedded in system CLR assemblies, and I just can’t see that being significantly faster than the bare-bones SQL arithmatic routines.

I just took a look in BOL on the Geometry datatype. (a) Zounds! (b) Cool! Check out the entries under “geomety Data Type Method Reference” (online here , but you want to look at the expanded treeview under this entry.) If that’s the kind of functionality you’ll be needing, by all means use the Geometry data type, but for simple processing, I’d stick with the knucklescraper datatypes.

回复收藏 0 原文