Although there is an accepted answer here, it is somewhat misleading.
Can I trust a Session ID for Uniqueness?
If uniqueness is the only constraint, then the short answer is yes. If you are Facebook or Google, then due dilligence would require that you take some time to assess how likely collisions are based on the algorithm and the architecture of the application. For applications where the concurrent userbase will be less than a million, the method implemented in common platforms should be sufficient.
However uniqueness just addresses the functionality of the system. From a security viewpoint you need to ensure that the session id is not predictable - i.e.
that cannot be inferred from available data;
md5(CLIENT_IP) would be a poor session id
that attempting to brute force guess the session id is difficult;
next_session_id=last_session_id+1 would be a poor choice
If you really must implement your own session id generation, then use a good random number generator. Have a look at the size of the session ids your current system is generating and aim for at least that size in your implementation.
Storing session tokens in the database could allow an attacker to impersonate other users if they can gain access to these tokens via a SQL injection attack
Given that the whole point of server side sessions is predicated on server side storage, this can be better stated as:
Storing session tokens on the server could allow an attacker to hijack sessions if they are able to inject code which reads the storage
....although the nature of SQL is such that it is usually the low hanging-fruit of code injection.
One solution is to not store the session data against the session id, but a transformed representation of it (e.g. sha1(session_id + salt)) but this is only provides limited benefits - if the salt and mechanism are exposed, the mechanism is inneffective. OTOH this easily translates to other storage substrates.
If the sessions are stored in a relational database then its possible to protect against enumeration via code injection by disallowing direct access to the underlying table by the account used by the application - instead restrict reads and writes to a single record based on the key (session id) supplied as an argument to a stored function with privilege separation.