我希望在数据库中存储 900x100 元素的二维数组。阵列的有效召回和比较很重要。我可以使用具有 [A, x, y, A(x,y)] 之类的架构的表,这样单个数组就会破坏 90,000 条记录。这似乎是一个存储数组的~ok~表设计,并且可以有效地调用单个元素,但调用整个数组的效率很低,并且会导致非常低效的数组比较。
我应该以这种方式离开表格设计并在代码中构建和比较我的数组吗?或者有没有更好的方法来构造表,以便我可以使用仅数据库操作获得有效的数组比较?
谢谢
我希望在数据库中存储 900x100 元素的二维数组。阵列的有效召回和比较很重要。我可以使用具有 [A, x, y, A(x,y)] 之类的架构的表,这样单个数组就会破坏 90,000 条记录。这似乎是一个存储数组的~ok~表设计,并且可以有效地调用单个元素,但调用整个数组的效率很低,并且会导致非常低效的数组比较。
我应该以这种方式离开表格设计并在代码中构建和比较我的数组吗?或者有没有更好的方法来构造表,以便我可以使用仅数据库操作获得有效的数组比较?
谢谢
如果数据类型允许,将其以串联格式存储,并在取消串联后在内存中进行比较。数据库操作将快得多,内存中的操作也将比数据库检索更快。
谁知道呢,你甚至可以在不去连接的情况下比较它。
900 x 100 元素实际上非常小(即使这些元素是巨大的 1K 东西,也只有 90 MB)。您不能在需要时在内存中进行比较并以某种序列化格式存储在磁盘上吗?
将二维数组存储在数据库中是没有意义的,尤其是当它是不可变数据时。
当我以前在地震行业工作时,我们过去只是将我们的数组(通常是几千个元素的 1d)转储到二进制文件中。该数据库将仅用于本质上是元数据(位置、索引等)。这会更快,但它也允许数据在必要时解耦:在生产中这很常见,几千个元素听起来并不多,但典型的数据集很容易达到数百 GB - 这是 1990 年代,所以我们必须与磁带解耦。