I am working on a
portal type application where a "user" will really only be made up of a username
and a password. That user will then have a profile which would contain
other standard details like the user's name, address, email, etc. The
question I am faced with is that for different
We use lookup tables. A simplified
version of our ERD is attached.
Basically, you normalize the attributes into
a separate table and then use a one-to-many reference table to map users to
their attributes. For the attached ERD, you can pull a users
attributes with this query:
SELECT
So do you model this in an OO fashion or is this all database
design? I am thinking specifically on the attribute ... is there different
types of attributes (i.e. email, plain text, date, etc.)? Is there any
checking / validation of the attribute? How are you storing the attribute
in the
We do have types as well I omitted
all of that extra stuff from the model just to simplify it. We actually
also maintain a normalized table full of types, so the attributes table would
have a type_id field as well.
Our length for that field is generally
VARCHAR(255). Its been plenty
Title: Message
Hi
Jeff,
If I
understand this right, you have one base application but multiple versions. Each
version can be customized in terms of either selecting from a set of possible
fields and/or creating custom fields. The fields for a given application will
only change if an admin
Title: Message
Hi
Jeff,
I wrote:
If you're
serious about this, you want to consider creating a simple generator that
customizes your DAO's, gateways, and the rendering of your form controls on a
version by version basis.
A simpler/quicker approach would just be to write a
generic
