I have to store file paths in a DB field (/tmp/aaa/bbb
, C:\\temp\\xxx\\yyy
, etc.). I can\'t really tell how long they could be.
Given this
You can use VARCHAR(MAX)
or NVARCHAR(MAX)
.
These are variable length fields meaning they are designed to store values of different length. There is no extra overhead for longer values over shorter values.
Defining MAX
means the field can be up to 2GB.
From MSDN (varchar), nvarchar has similar documentation:
Use varchar when the sizes of the column data entries vary considerably.
Use varchar(max) when the sizes of the column data entries vary considerably, and the size might exceed 8,000 bytes.
The field should be the same length as the length of a box of string.
As asking the length of a filename is like asking the length of a bit of string, asking the length of a path is like asking the length of all bits of string in a box of unknown size.
So the only sensible option given no other information is not to limit the length e.g. NVARCHAR(MAX)
If your using SQL Server, it's good to know that Microsoft is using nvarchar(260) fields to store file path and name in the system tables (like sys.database_files, or sys.sysaltfiles, or sys.master_files).
Column name Data type Description ------------- ------------- --------------------------- physical_name nvarchar(260) Operating-system file name.
Good practice could be to use the same format to store your path and file name.
You will, of course, need to enforce the size in your UI to be sure that it will not be truncated during INSERT or UPDATE.
I would recommend VARCHAR(2048) or even VARCHAR(1024) since file paths are usually not 2000 characters long.
I suggest you do not store the paths in your existing table. Create a new table having a sequential counter as the clustered primary key and a character column of the maximum length of your db program. I use SQL Server so I would use varchar(max).
Create a column in your data table to hold the primary key of the "paths" table. Insert into the "paths" table first then use the primary key as the foreign key back in your data table.
The advantage of storing the value in another table is it does not influence the data size of the base table. Queries of the base table which do not involve the "paths" do not suffer from having to pull in a large character value which increases the IO traffic.
The Length of a file path cannot be predicted. It could be very short as 'C:\'
or could be very lengthy like 'C:\Program Files\Microsoft SQL Server\110\LocalDB\Binn\Resources\1033'
or even more. But in database level there is no harm using something like VARCHAR(MAX)
See Maximum size of VARCHAR(MAX)