Ticket #1332930 (Feature Requests)

Jason Dixon jason at dixongroup.net
Sat Aug 12 00:01:54 CEST 2006


On Aug 11, 2006, at 4:08 PM, Chuck, Charlie and Charles wrote:

> Jason Dixon wrote:
>> No offense, but given the design criteria Thomas mentioned earlier
>> (iCal-like), doesn't it make more sense to use a "free field" method?
>> That is, to create a single table of "contact" key/value pairs
>> associated with the user id?  Then you can easily pull all pairs
>> associated with the user and arrange them according to a known set of
>> keys (first_name, last_name, email, phone, im_contact, etc).
>>
>> This approach has worked well in the past for systems like OTRS.   
>> Just
>> my $0.02.
>
> I don't like it because it makes things like sorting multiple  
> contacts,
> sorting by numeric/non-numeric fields, and having fields like check
> boxes, drop-down lists, etc. needlessly complicated.  In essence I  
> don't
> like it because the more features you want to implement, the more  
> you've
> moved towards creating a database engine on top of a database engine.
> In other words there's already a system for creating paired fields and
> values, and it's called a table.
>
> With the system you propose you gain:
> 1) some flexibility in creating and removing fields
> 2) some storage space
>
> but you lose all of the built in functions of a database engine,  
> such as
>  default data, data types (including date manipulation), etc.  What
> about grouping bits of that data together?  Let's say you want a  
> list of
> all phone numbers for a contact.  In a normal contact table you just
> hang a table off of it called phone_numbers {phone_id; contact_id;
> description; phone_number} and voila, you have lists of phone numbers.
> Now imagine trying to do that in the systems being proposed.  Sure you
> can create a single phone number label, but what if you want to allow
> them to label the phone numbers with "home" "work" "cell" etc.  You
> either have to put that data in the "data" portion, mixing it with the
> phone numbers (forget about ever sorting by area code), or you have to
> create unique labels for each type, but then they can't be grouped
> without having another table grouping all of them by their label.

You're absolutely right.  Allow me to share with you a puff of  
whatever I must have been smoking.  ;-)

--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net







More information about the Dev mailing list