Fajar A. Nugraha wrote:
On one of my systems, we use ids. It's somewhat complicated though: - use stored procedures, as I need to use several statements to achieve the same functionality. It's better than joins (which is very expensive in mysql cluster) - lookup user id based on username (on an additional table, obviously) - lookup other properties (e.g. radcheck, radreply, etc.) based on the id
One deployment I did mandated user IDs for "cleanliness" of the SQL schema. I added a User-Name table, and used its Id as a foreign key in other tables. It had the nice property that if you deleted the user, all of their configuration went away. Including their historical accounting data. It caused problems for billing, but the SQL team thought it was a great idea.
It works, and is more "ideal" (especially when you have a super-large number of users), but definitely NOT something I'd recommend to be a generic implementation due to the complexity.
It doesn't save much. The main issue is that *most* users have minimal user-specific information. So using an Id doesn't get you much, because it's not really used. And for accounting, you're doing a row insert anyways. So it doesn't make much difference if column 1 is an Id or a User-Name. Alan DeKok.