oc_filecache: optimization structure > UNSIGNED!

I am working on a project that "hooks" into Nextcloud. All is working quite well, but I just stumbled on something, something easily changed and does no harm and can only improve NextCloud:

There are quite a few 'bigint' field types in 'oc_filecache'.

As far as I know and can see all values are only positive, except size ( -1 for folder) and mtime could have an negative timestamp)
So making them UNSIGNED would be logical and (with fileid) would double the theoretical number of files NexCloud could handle!

Also:
Why is a number like storage a BIGINT? Wouldn't be a SMALLINT (unsigned: 65535) be enough? Or to be on the safe side a MEDIUMINT (unsigned: 16777215 is quite a ridiculous high number, wouldn't you say)?

And mimetype and mimepart, wouldn't be a SMALLINT (unsigned: 65535) be a more then safe maximum number?

And storage_mtime when set to "unsigned INT" the maximum value would be 4294967295 (February 7th 2106) would be more then fine for the next 80+ years!

This would improve the table structure, remove unwanted/impossible values, remove reserved space, thus make it smaler, so faster.

Easy change, easy benefit?

PS: as for mimetype (and others) also other tables can/must be altered (but filecache is one otf the big ones, so has the most to gain)

PS2: also the id in oc_mail_messages can be set to 'unsigned', doubling the amount that table can hold!

Start by reviewing the oc_filecache and oc_mail_messages schemas and the listed bigint fields, including size, mtime, storage, mimetype, mimepart, storage_mtime, and id. Determine which proposed type changes are safe across the affected tables; done means an agreed scope and validated schema change, not just a list of possible optimizations.