The answer to that depends on the details of your system, and specifically whether someone other than you can modify the hash.
If you store the hash in your database, and retrieve the expected hash value from your own database to compare it with the actual hash (when checking to make sure that those certain values have not been altered), there's no point in using the salt. The only thing someone could try to do to fool you is to find a modification to the object in such a way that leaves the hash result the same; if you use a collision-resistant hash function, he won't be able to do that.
On the other hand, if you return the hash along with the set of objects, and at the end of processing, the hash will be sent back to your system along with the objects, well, one thing someone might do is modify the objects, and then modify the hash to reflect that change; because the hash function can be evaluated publicly, they can do that.
In this second case, introducing an unknown salt value certainly is one way to attempt to prevent this attack, but it's probably not the best. What you really need in this case is a Messsage Authentication Code (MAC) instead of a hash; I would recommend using HMAC based on the hash function you're already using; it's only a constant amount slower than the hash function, and was designed specifically to be strong in this attack model.