baalbek wrote: > No, concurrent access is highly relevant; for example, on a team of > about 50 architects working on design and production drawings for a new > hospital, each floor was one 'drawing' (dwg file), and thus stored on > disk as a separate entity from the other floors. > > Now, only one architect could work on one floor at any time! And as info > from the project goes (sums and statistics of data, for example areas), > the only reliable (an efficient) way to gather this was to hack an > in-house application that collected the desired info from the various > binary dwgs stored on disk, and saved this data this to a RDBMS, for > further report processing.
You have two orthogonal thoughts going here. It makes sense to collect statistics from a given drawing into an RDBMS in such a way that, whenever a design is checked in, the statistics are synched with the RDBMS. Further, such a system could (and should) make sure that no previous checkin has been clobbered. This is a classic source control system. I'd be surprised if there aren't plenty of add-ons which do this. At Cadence, we provided hooks for such systems to automatically collect necessary information. This does not mean the design itself should be stored as an RDBMS. As I've stated previously, CAD data (both electrical and, it appears, mechanical) does not lend itself to RDBMS relationship modeling. What you want is an easy way to manage the information, not dictate the storage format of the information. > And just to work on one small area of a huge floor, the architect has to > load the whole freaking floor... I don't have any architectural experience, so I can't say whether this makes sense or not. However, I think of this as being akin to complaining, "Just to edit a single function, I have to load the entire source file/check out the entire module/rebuild and rerun all the tests!" Not that this is necessarily an invalid idea. However, my experience with Cadence's tools makes me believe the existing behavior might just be the lesser of two evils. CDBA has a strict library/cell/view hierarchy; the checkout granularity here is (usually) at the view level (that is, when you lock a design, you're locking the view). Two designers could edit two different cells or views in the same library. This leads to all kinds of data inconsistency problems -- cell borders aren't lining up in a layout, for example, or the cached data isn't valid, etc. It's a nightmare. The newer OpenAccess system has an option to manage this at the library level. Unfortunately, this is rarely enabled due to backwards compatibility. -- http://mail.python.org/mailman/listinfo/python-list
