数据库设计:文件路径的首选字段长度

Fro*_*y Z 15 database sql-server database-design

我要的文件路径存储在数据库字段(/tmp/aaa/bbb,C:\temp\xxx\yyy等).我无法确定它们可以存在多久.

鉴于此http://en.wikipedia.org/wiki/Comparison_of_file_systemshttp://msdn.microsoft.com/en-us/library/aa365247.aspx,根据文件系统,理论上可能没有长度限制一条路径.

我想将此字段定义为LONGBLOBVARCHAR(very high value)不明智.我已经考虑过VARCHAR(1024)哪些应该适合最频繁(即使不是全部)的情况,而不是像DB字段那么大.你会推荐什么 ?

谢谢.

Max*_*non 20

使用适合您要支持的数据的长度.由于您使用的SQL Server(直到最近才是严格的Windows产品),您最有可能考虑使用nvarchar(260)作为存储路径名的上限,因为这是典型Windows机器的规格限制.在某些情况下,您可以创建比此更长的路径,但Windows资源管理器在处理它们时往往会遇到问题.

至于SQL Server,列的长度在性能方面非常重要.列长度​​直接影响:

  • 内存授予对列的查询.当查询处理器创建查询计划时,它使用查询中存在的每个列的大小作为运行查询所需的内存量的基础.它不使用每列中存在的数据的实际大小,而是"猜测"数据的平均大小将是列的最大长度的50%.
  • 能够有效地索引列.较大的列会创建更大的索引.较大的索引需要比较小的索引更多的内存和磁盘吞吐量.对于非聚集索引(从SQL Server 2016开始),SQL Server的最大密钥长度为1700字节,对于聚簇索引,SQL Server的最大密钥长度为900字节.如果您尝试在大于这些最大数量的列上创建索引,则会出现错误,并且可能直到运行时才能修复成本非常高.
  • 基于字符的主要/外键性能受到较大列长度的严重影响.当通过外键引用主键时,每个外键的内存,磁盘和I/O的大小要求都是重复的.以一个nvarchar(260)表为例,其中键是sys.master_files列,定义为physical_name.引用客户的每个表现在都需要一个500字节的physical_name = f.pname列.如果该列被定义为FROM sys.sysbrickfiles f,则引用这些列的每个查询将在内存和磁盘I/O中每行节省200个字节.


Ode*_*ded 9

你可以使用VARCHAR(MAX)NVARCHAR(MAX).

这些是可变长度字段,意味着它们被设计为存储不同长度的值.较长的值比较短的值没有额外的开销.

定义MAX意味着该字段最大可达2GB.

MSDN(varchar),nvarchar有类似的文档:

当列数据条目的大小变化很大时,请使用varchar.

当列数据条目的大小变化很大时,使用varchar(max),大小可能超过8,000个字节.

  • 实际上,使用 (max) 类型是有危害的。请参阅我的答案了解原因,其中最重要的是不必要的大量内存分配。Windows NTFS 文件系统支持长度最大为 32768 个字符的路径,但仅限于使用 Unicode API 时。使用长路径名时,请在路径前添加字符“\\?”。但是,即使您尝试使用 unicode API 方法,SQL Server 也不支持长文件名。截至 2019 年,SQL Server 仅支持长度不超过 260 个字符的文件名。 (2认同)

小智 8

如果您使用SQL Server,最好知道Microsoft正在使用nvarchar(260)字段在系统表中存储文件路径和名称(如sys.database_files,或sys.sysaltfilessys.master_files).

Column name      Data type        Description
-------------    -------------    ---------------------------
physical_name    nvarchar(260)    Operating-system file name.
Run Code Online (Sandbox Code Playgroud)

好的做法可能是使用相同的格式来存储您的路径和文件名.

你会的,当然,需要强制执行的大小在用户界面,以确保它不会插入或更新时被截断.