Assad Jarrahian wrote:
what drove me to store it that way was more of a performance issue. So if I store a documentID and then have a seperate table names, to_field
Why a seperate table? From what you showed us you don't seem to need that. Just use 3 columns for the seperate entries instead of 1 that combines them. There's really no big deal to it. And you gain the benefit of being able to put foreign key constraints on those columns.
Now you need to split a string, risking splitting it the wrong way (if there happen to be comma's in names) and using some of that computational power you seem to be so concerned about. It seems unlikely you would gain any measurable performance this way, if at all.
I can't say I fully understand what you're trying to do, your example and explanations were somewhat confusing.
Regards, -- Alban Hertroys alban@xxxxxxxxxxxxxxxxx magproductions b.v. T: ++31(0)534346874 F: ++31(0)534346876 M: I: www.magproductions.nl A: Postbus 416 7500 AK Enschede //Showing your Vision to the World//
