[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