OK for this to be a SQL Server job?

I have a folder that contains images for use badges. I have another folder that contains renamed versions of the images (this folder is on another machine).

I need to create a process that will copy and rename any new images found. The mapping between the names is in a SQL Server DB.

Would it be a bad idea to create this as a SQL Server job and use xp_cmdshell to copy the files? This was my first instinct, but I haven't done this before so I was curious if there were any g开发者_Go百科ottchas i should know about...

---

Considering most simple questions on SO are answered in seconds, and you asked this one 53 minutes ago (at the time I'm writing this) and have no answers suggests nobody has done it, or nobody has any strong feelings one way or the other.

In my own experience I have sometimes found myself considering this, and always chosen against it. The reason always turns out the same, the operation in question becomes more complicated over time, and is better handled in application code. So it turns out to be easier to handle it in app code, and to just store the result in the database.

Some years ago I stopped thinking about it and crossed this option off the list of regular practice, owing to that pattern.

EDIT: One more thing (Remember I said I never think about it anymore?), which I remembered in answering your other question. It's because the shell is executing with the server's permissions. You often have to give the server privileges it would not normally have, which is bad practice.