On 14/06/11 14:35, Sim Zacks wrote:
> It is much simpler then that. My data includes file references.
> One table has the filename with a path placeholder and another table
> contains the windows and linux versions of the full path. This is for an
> intranet and we _always_ have the same drive letters (windows) and mount
> paths (linux) for every client. When the client requests data that
> includes a file reference, I want to send the relevant path.
Just send the client the relative path component under the mount point /
drive letter / whatever.
If your storage is mapped to "/net/myapp/files" on your Linux/unix
boxes, and "Z:\" on your Windows boxes, both these paths:
/mnt/myapp/files/project1/file.bin
Z:/project1/file.bin
... share the same relative path component "project1/file.bin". Just
send that to the client and let it concatenate the fixed prefix path to
the storage root. That way you aren't hard-coding drive letters and
mount points, and you only have to store paths once in the database. The
client knows what OS it is and it knows where the storage root is
mounted/mapped; the database server doesn't need to know.
Yes, I know I showed the windows path with forward slash separators. As
far as I can tell, these days doesn't care about this - it's quite happy
with forward slash separators. If you find it to be a problem you can
always have your Windows clients flip the separators.
Trust me, your users and anyone else working on the codebase later will
hate you if you try to do it the way you're proposing. I speak from
horrid experience working with a (closed-source, legacy) product that
did just what you want to do. It's a bad idea. If nothing else, what
will you do when you have to add a phone client that has to access the
files over HTTP or WebDAV requests? It's easy if you store just the
relative path, but a nightmare if your DB must store full paths. Not to
mention all the wasted storage space your proposed method requires.
--
Craig Ringer
