Teddy, Yes, we already have all this. The data is highly normalized. This is how we relate the items to each other already. But the issue is trying to store as little in the colleciton as possible. If I store the 'relation' records (from the 3rd table) then I end up with the 4,000+ items in my collection. This is what we used to do and it is just too slow.
Unless I'm misunderstanding your post, it seems to apply only to the database schema and not about the issue with the collections, which is our starting point of the whole issue anyway. Dave >I think the schema here needs a little tweaking. > >This is a perfect case for a many to many relationship also know as a bridge >table. > >You have table 1 which is your for processes and you have table 2 for your >tasks. > >You will need a table 3, which will store the primary key from processes and >tasks, so that all you are searching on are quick and small data sets that >represent the permutations of not repeated data. > >tblProcess >--------------- >processID >... > >tblTask >----------- >taskID >... > >tblProcessTask >----------------------- >processTaskID >processID >taskID > >Makes sense? > >Cheers, >Teddy > > >On 1/8/07, Tom Chiverton <[EMAIL PROTECTED]> wrote: >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Create robust enterprise, web RIAs. Upgrade & integrate Adobe Coldfusion MX7 with Flex 2 http://ad.doubleclick.net/clk;56760587;14748456;a?http://www.adobe.com/products/coldfusion/flex2/?sdid=LVNU Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:265950 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
