David Cuthbert wrote: > baalbek wrote: > >> David Cuthbert wrote: >> >>> 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. >> >> >> I simply do not agree with this. >> >> A CAD program (like Autocad) is nothing >> but an advanced database editor: the program loads data from a binary >> file and creates its object (in memory) from the tables that it reads >> from the file on the disk. > > > Well, then, good luck with this. Let us know when you've rediscovered > that simply structuring data in a table does not make an RDBMS.
Remember, a CAD binary file (at least most of them) stores its data in tables that are already in a (first?) normal form, similar to that of a RDBMS. The CAD program parses the data, and the CAD objects are created by database joins between the different tables (one table for layers, one table for colors, one table for geometrical data of the CAD entities, etc etc). I never said it would be easy, but remember, the O/R mapping of today is far ahead of what one had only 10 years ago. Of course, I would not have the CAD client talk directly to the RDBMS, with constantly updating the database, but through a O/R layer (Hibernate is a good one for this) that the CAD client connects to (either through CORBA, ICE or similar), and have the application server do batch update/fetching of the data. I think that those that shy away from a RDBMS CAD solution exaggerates the complexity of the CAD structure, and underestimates the technologies we have available today. Regards, Baalbek -- http://mail.python.org/mailman/listinfo/python-list
