> I do #1 and #3 depending on the nature of the field. It > keeps the objects > separate.
Right on. > For objects that are pretty dynamic or don't come from a set > list, I'd do #1. Also Agreed... > I do a #3 for a more generic "lookup" type object where the > values don't change often (or at all) I have a couple very good examples of this one in my current project. 1) line of business code. When a code and its significance has been spread across multiple disparate systems, it isn't going to change at 14:35:48 on a Tuesday. =) There might be new ones, but it's OK for it to show up the next business day (i.e. get reloaded on restart etc) because it is also not going to be a surprise or on-the-fly change. 2) District code. Again, this isn't going to change on the fly. There may be openings or closings, but they aren't real-time. There are others, but my point is simply to keep the real "business need" in mind. Can it change real-time, and does the change need to be reflected immediately? Yes -> Query for it. No -> Cache it. (Write once, read many.) This keeps your queries clean, quick, and focused on the real business logic required. David Hibbs, ACS Staff Programmer / Analyst American National Insurance Company --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
