On Mon, Jan 23, 2012 at 8:18 PM, Alan DeKok <aland@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