[Serusers] SER data model discussion - developers please read

Jiri Kuthan jiri at iptel.org
Tue Dec 4 00:24:49 CET 2007


At 13:17 03/12/2007, SIP wrote:
>The current data model, while designed to make certain things easier 
>DOES indeed encourage data duplication, as, in order to create a unified 
>system, most of us will opt to duplicate data into more usable tables.
>When meshing with an overall system, gathering all relevant data for a 
>particular substructure or user by using joins is neither speedy 
>(especially when the tables get HUGE -- and they very much will) nor 
>terribly convenient.
>Of course, data duplication is hardly a cardinal sin, but there's ALWAYS 
>a trade off between abstraction and actual functionality. I understand 
>the reasons WHY they've chosen the current data model, and to a degree 
>it makes sense for the core SER system, but for meshing SER with other 
>systems, it's god-awful ugly. :)
>
>My recommendation, Mahatma, is to AVOID using the new data model for 
>anything other than the most basic of SER functionality, or, if you 
>gather users in the 50-100,000 user range, your user_attrs table is just 
>going to be one ugly, unmanageably large pile of annoyance.

My recommendation is USE it exactly for this reason. It allows extending
functionality and making upgrades easier. The penalty is amount of data
in a single table, but this type of problems used to be challenging in 
70s IMO. We have been using it without any duplication, and I'm just
wondering how one can come to the idea of putting any duplications in it.

Really -- I'm interested in a technichal discussion grounded on technical
arguents. extensibility and easy-to-upgrade are such. "ugly, unmanagable,"
etc are expression of estehtic choice. That is of course is interesting to 
share, but unlikely to gain momentum for any change.


-jiri



--
Jiri Kuthan            http://iptel.org/~jiri/




More information about the sr-users mailing list