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/