On 1/2/06, Dave Shuck <[EMAIL PROTECTED]> wrote: > I am considering building an application-scoped array of Company objects,
Or struct indexed by company name or key? How will you access the specific company objects. > each with a property of Users which is a structure of all users tied to that > particular company, where each item (instance of a User object) would have > its own properties/methods unique to that user. Yup, sounds reasonable. > Now, my immediate concern is as follows: In listening to the Helms An > Peters "Objects for maintainable code", I noted that Hal makes the comment > along the lines that if we had perfect systems that could hold the objects > forever, we really wouldn't need databases to persist the objects. He means if our systems never crashed and never needed rebooting or whatever, we could just keep data in memory and never persist it. > If I > understand that correctly, he is suggesting that all objects are loaded up > when the application starts and the only database interaction is when > persisting them. Am I understanding this properly? Not quite. See above. > My gut feel (which is > only slightly more than occasionally right) is that it seems unreasonable > from a memory standpoint to hold every user in every companies' Users > property(ies), and the properties/methods of each user within that, and the > properties/methods within those, and so on to the end of the relationship > tree. What is the best approach here, keeping in mind that I want to limit > the database interaction as much as I can. Well, there is no "best approach" but you'd be surprised how much data you actually can keep in memory! You might want to look at some of the ORM library / framework offerings to see if they can at least make the persistence part of your equation easier. Check out Arf! and Reactor first, but also look at objectBreeze and Transfer. -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
