Interesting idea, but if you pre-loaded a database with a bunch of fake profiles, then the hackers would simply use all profiles after id N. So you'd have to continually be generating new "fake" profiles during production, which would cause extra load for the servers. That translates into higher cost.
Maybe the application could generate a randomized number of empty fakes whenever a new user signs up, and then fill them up overnight or during another low-load period. But this would obviously not help as much if the system was already compromised.
Also, to make things really convincing, there would also need to be fake transactions which the application could somehow recognize as such. The solution to that might be with fake products, these being in fake product categories that are in a fake category root. Complicated, yes.
Another idea: make the username the primary key and dispense with the id column. Username will not be changeable, but I think that is a rare case anyway.
Comments
Interesting idea, but if you pre-loaded a database with a bunch of fake profiles, then the hackers would simply use all profiles after id N. So you'd have to continually be generating new "fake" profiles during production, which would cause extra load for the servers. That translates into higher cost.
Maybe the application could generate a randomized number of empty fakes whenever a new user signs up, and then fill them up overnight or during another low-load period. But this would obviously not help as much if the system was already compromised.
Also, to make things really convincing, there would also need to be fake transactions which the application could somehow recognize as such. The solution to that might be with fake products, these being in fake product categories that are in a fake category root. Complicated, yes.
Another idea: make the username the primary key and dispense with the id column. Username will not be changeable, but I think that is a rare case anyway.