Is there any problem while using it as raw ids ?
Is it good to encrypt id? if so what kind of encryption is best ?
<option value="bk23khu3uu343757AHSty3">encrypted record<option>
<option value="1" >sample record</option>
j
stuff ;)
You can use raw ids, but make sure your authorization strategy protects the data from unauthorised use and modification.
Depends on what you want. I've had a lot of fun with my "inc" and "dec" bookmarklets that simply add or substract one from the last integer found in the URL. What others have written before me: public code shouldn't see real database id's. I mostly generate UIDS for those. Have a lot of benefits as well. Does require some extra bookkeeing or storage, but that's cheap nowadays anyway.
if it's not exposed to the public and only data that is for the customer I would not care to do so as long as you're using SSL to encrypt the transfered data.
unless you have no ownership checks or there are information leaking cross account values .... but who cares if id 1414424 is value XYZ or "a5a5997ab9f101" is value XYZ from the outside you can analyse it the same way. ML to the rescue ;)
Rule of thumb -> publicly exposed data -> obfuscate it. -> app internal / account related data leave it as it is.
you can ofc have everything, if you're a crypto service, but that's something explicit. save your CPU the troubles and don't think for a second that using md5 really helps you keeping things save. Rainbowtables and ML basically made this idea obsolete even with hashcollisions.
In the end there are other factors to consider as well but this has to be discussed by case not in general.