Re: Storing and Retrieving Parts Lists / BOM Lists (Individual Jobs) where to put active storage

BrianDP,

Your application users know about the state you described. But it is only a part of their state, which has parts reflecting long transactions on that first part. Long transactions typically involve a user policy like check-out-check-in to manage waste from possible simultaneous editing. So your application state should probably involve certain extra state about long transactions. These parts have relations and attributes like the first part but contain in-edit values plus transaction attributes plus possibly relaxed constraints. (Of course, it's all in the same database. And any justified implementation architecture should be hidden within the dbms.)

(Think of editing a shared string. If it's an essay then maybe the users would like to know others are composing changes. Maybe editing is exclusive. Maybe editing by paragraph would be a better policy (exclusively or not). The set of characters is constrained like the shared value but maybe nothing else is until you hit 'enter'. Regardless, if in-edit pre-'enter' state has to be available indefinitely, it should be in the database. And regardless, if you "need" a distributed implementation, which should be hidden from the user, then you need such a dbms.)

See http://thehelsinkideclaration.blogspot.com/2009/03/start-of-this-blog.html about "the fat database".

philip Received on Sat Jan 14 2012 - 22:38:23 CET