Why not simply leave mandatory fields in table and save optional in
longvarchar field (which all supported database has) in XML format
using for example Quick (http://www.jxml.com/quick)? As for me
structures where relations are replaced by node navigations are looking
elegant on paper but too hard to use and extend in SQL database.
fadkarpelevitch> My belief is that it makes much more sense to use a structure like
this for
fadkarpelevitch> the attrs:
fadkarpelevitch>
fadkarpelevitch> VISITOR_ATTR_TYPES
fadkarpelevitch> -------------------
fadkarpelevitch> ATTR_TYPE_ID TYPE_NAME
fadkarpelevitch> 1 NAME
fadkarpelevitch> 2 EMAIL
fadkarpelevitch> 3 SHOE SIZE
fadkarpelevitch> 4 BAD HABITS
fadkarpelevitch>
fadkarpelevitch> and store attr values in
fadkarpelevitch> VISITOR_ATTRS
fadkarpelevitch> -----------------------
fadkarpelevitch> VISITOR_ID ATTR_TYPE_ID VALUE
fadkarpelevitch> 1 1 Rafal
fadkarpelevitch> 1 2 [EMAIL PROTECTED]
fadkarpelevitch> 1 3 42
fadkarpelevitch> 2 1 Fedor
fadkarpelevitch> .....
fadkarpelevitch>
fadkarpelevitch> This way you have enough flexibility to add/remove various attributes
fadkarpelevitch> without any java coding and schema changes by simply manipulating
entries in
fadkarpelevitch> VISITOR_ATTR_TYPES. But this way you do not depend on Java to retrieve
fadkarpelevitch> values and you can run queries against any attr. There is a question
whether
fadkarpelevitch> it makes sense to move system-used attrs (uid, passwd, email) into
this
fadkarpelevitch> structure or leave in VISITOR table or, maybe, duplicate in both.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
