【问题标题】:DB vs. filesystems - for non-image files and endianessDB 与文件系统 - 用于非图像文件和字节序
【发布时间】:2013-05-12 00:33:36
【问题描述】:

我已经阅读了很多关于数据库与文件系统存储文件的讨论。这些讨论中的大多数都讨论图像和媒体文件。我的问题是:

1) 相同的论点是否适用于存储 .doc、.pdf、.xls、.txt?我应该注意的文档文件有什么特别之处吗?

2) 如果我以二进制形式存储在数据库中,如果我的主机交换机器,是否会出现字节序问题?例如,我在大端机器上插入数据库,它被移植到小端机器上,然后我尝试提取(例如,写入文件,将其发送到我的桌面,然后尝试打开)。

感谢您的指导!

【问题讨论】:

    标签: database filesystems document endianness


    【解决方案1】:

    1) 是的,几乎相同的论点适用于存储 PDF 等等……任何被压缩的东西也会浮现在脑海中。

    如果每个非文本文件格式想要在不同字节序的主机之间移植,它都必须处理字节序问题。他们主要通过定义文件中长于一个字节的所有二进制字段的字节顺序来做到这一点。写入和读取格式的软件必须特别注意字节交换,如果它运行在相反字节序的平台上。图像与其他二进制文件格式没有什么不同。选择是任意的,但大端(网络字节顺序)是一种流行的选择,尤其是对于网络软件,因为 C 中无处不在的宏几乎可以自动处理这个问题。

    另一种定义二进制文件格式以便它们可移植的方法是支持二进制字段的任一字节序,并在标题中包含一个标记以说明使用了哪个。在打开文件时,读者会查阅标记。这样,文件可以在写入文件的同一主机或具有相同字节序的其他主机(这是常见情况)上稍微更有效地读回,而相反字节序的主机需要花费更多的努力。

    对于数据库,假设您使用的是像 blob 这样的字段类型,当您读取时,您将得到与您写入的内容完全相同的字节流,因此您不必担心数据库的字节顺序客户端或服务器。

    2) 这取决于数据库。数据库可以使用与任何字节序兼容的底层磁盘格式,方法是如上所述定义其磁盘格式。

    不过,数据库通常不以底层文件格式的可移植性为目标,考虑到(正确地)将底层数据文件移动到不同字节序的数据库主机是很少见的。以this answer 为例,MySQL 的 MyISAM 不是 endian-portable。

    不过,我认为您不必为此担心太多。如果数据库服务器曾经切换到不同字节序的主机,确保数据保持可读性是该过程的一个重要步骤,处理任务的 DBA(可能是您自己?)不会忘记这样做,因为如果他们这样做了算了,那么什么都行不通(也就是说,破坏不会仅限于二进制 BLOB!)

    【讨论】:

      猜你喜欢
      • 2014-01-08
      • 2020-11-24
      • 2010-10-05
      • 2013-05-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-04-10
      • 2014-07-18
      相关资源
      最近更新 更多