Using python for a CAD program
rcs at bgoark.no
Sun May 21 22:29:19 CEST 2006
David Cuthbert wrote:
> Some kind of transactionality is needed for undo/redo, but this is
> usually done in a different (some might say "more efficient", others
> might say "hackier") method than how transactions are implemented for
> RDBMS (that I've dealt with, anyway). I suspect this can be attributed
> to two major factors: concurrent access is never an issue in such
> systems, and the number of database objects representing a given state
> is far larger than in, say, e-commerce.
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.
And as far as administering the dwgs (see to it that the mass of
drawings follow one dimensioning convention, similar fonts etc) the CAD
systems today are a pure joke: roughly 10-30% of the time the architects
spend on CAD is pure "hacking" each drawing to conform to standard,
problems with layers being out of sync with the rest, internal blocks
not being uptodate, etc etc etc.
And just to work on one small area of a huge floor, the architect has to
load the whole freaking floor...
This is in 2006, not 1986!
All of these problems (the technical ones, as well as problems of
concurrency) would be neatly solved if the data had been stored in a
RDBMS, instead being spread around on thousands of files on disk.
The Autocad DWG format is already in a database like structure (tables
being joined by keys etc), so the technical difficulty is not the
show-stopper here; I suspect the management at Autodesk will simply not
touch the milk-cow that Autocad has become, and does not understand the
needs of the average CAD user anyway...
I'm myself really fed up with the CAD situation of today, having battled
for 10 years the various problems that comes with todays stone-age CAD
systems. Jeez, 2006, and the state of the art CAD, Autocad, is still
basically a primitive, one-user binary application. What a pathetic joke!
More information about the Python-list