问题
I am currently working on a system that involves storing multiple studies and details of their contents (A study can typically contain 1 < X < ~2000 images). My colleagues and I were discussing what might be the best method of storing files sizes (specifically the image sizes) in a database would be.
The file sizes typically range from < 1kB to > 20MB.
We are currently debating between storing the images sizes as:
# of kilobytes (as an integer value)
# of bytes (as a large integer value)
# of megabytes (possibly as a decimal value)
Other Options...
I haven't worked with storing file sizes much and was wondering what might be the most efficient / practical method of accomplishing this?
回答1:
There is no right answer. I like Matt's answer for reasons of precision. I like Abe's answer for reasons of space saving... (Yes, space in a table is much more 'impactful' than on the Filesystem)
The real answer is, for what purpose are you storing the value? Is this for a mechanism to invoice the user storing the data? Then you'd have to rely on the contract. Is this to measure space on a drive... if so, files REALLY take up some number of 'blocks' and NOT some number of bytes. If the minimum block size is 2KB then you should say that EVERY file is increments of 2kb... If you store that value or that value times 2kb is up to you.
Maybe you're storing the value because the retrieval algorithm has 2 optimization paths, one for larger files and one for smaller and that process would like to know the size WITHOUT interrogating the file-system. (in this case maybe just an "is_greater_than_x_kb" flag column is all you need.)
No one here can tell you what your requirement is. The only thing the existing answers give you is an opinion, not a right answer.
回答2:
If you're going to explicitly store the size at all, store the number of bytes. There is just too much confusion/ambiguity when using other units.
Example: different people might interpret kb as:
- kilobytes
- kilobits
- kibibytes
- kibibits
...and how big is a kilobyte, anyway?
That said, if you're storing the actual data in your database, I do not see an immediately compelling reason to explicitly store the length of the data at all.
回答3:
I would personally go for # of kb as an int column (as long as you will never have anything smaller than 1kb). bigint takes up twice as much space (8 bytes vs 4) and as long as it's well documented people shouldn't be too confused.
回答4:
I store filesizes in bytes as an integer in the database. The (signed) integer field of mysql has a maximum value of 2147483647 so filesizes up to 2GB can be stored without a problem.
来源：https://stackoverflow.com/questions/4617174/storing-file-sizes-in-a-database