3 Dec
2007
3 Dec
'07
6:24 p.m.
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/