Why using username instead of user id?

[Fajar A. Nugraha]

On Mon, Jan 23, 2012 at 8:18 PM, Alan DeKok <aland at deployingradius.com> wrote:
> Fajar A. Nugraha wrote:
>> From db point of view only, normalizing is a "better" approach.
>> Real-life implementation might have other priorities so normalizing is
>> not always the best choice.
>
>  What would be better would be to have a "live" table of online users,
> and a "historical" table of old user activity.  The "live" table would
> be small, so updates would be fast.  The "historical" table would only
> get appended to, so it could hold a lot of data.
>

I kinda promised a patch for something like that, didn't I :P ?

>  Maybe for 3.0.

Hopefuly I can start working on it again after 2.2.0 is released. DHCP
is more "fun" for now :)

My basic idea for the implementation is based on one of my
implementations, but kinda generalized. Something like:
- create a module instance that a user can choose, but does not
replace the existing sql module example (e.g. "mysql5" instance of sql
module)
- use stored procedure, since it's the cleanest way to move data
around from "live" to "historical" (without any need for external
crontab). Which is also one of the reason for choosing "mysql5"
instance name, since stored procedure is only supported from mysql5
onwards.
- have a radzap-like function to help user force-move data from live
to historical (e.g for lost acct-stop case)
- (optional) normalization of username and attribute. This would
require importing dictionaries to a table.
- if it's tested-enough, then maybe start porting it for other db

It's still a rough sketch, so if anybody have a better working
implementation, or a better concept (e.g. something that can work for
all db with as minimal change to existing configuration as possible),
or have some spare time to start implementing it, raise your hand  :)

-- 
Fajar