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 simpl
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
Terry Hancock wrote:
> I disagree that transactions are bad for CAD -- they may have
> a different semantic role and the needed granularity may be
> different, but the need to roll data back to an earlier revision
> is just as present in drawings as it is for code or financial
> transactions.
Sure
Paddy wrote:
> Unfortunately, Cadence got their first with their DFII environment for
> Schematic based design and their Lisp based language SKILL
Well, SKILL (a Franz Lisp derivative) is very old and has some peculiar
design quirks. Interfacing with anything not written by Cadence or not
writt
baalbek wrote:
> CAD systems available today (Autocad, Archicad, Architectural Desktop,
> etc) have one huge flaw: they don't store data to a SQL database, but to
> binary files.
There's a reason for this. Most CAD data is not in a form (First Normal
Form) suitable for a relational database.
Paul Rubin wrote:
> I don't think you want to do this. Runtime type tags and the overhead
> of checking them on every operation will kill you all by themselves.
> Processors like that haven't been used much as Lisp targets either,
> for the same reasons. Pick a different language.
I was thinking
Mike Meyer wrote:
> Just out of curiosity, is there an OS out there where you can have the
> permissions needed to delete a directory without having the
> permissions needed to create it appropriately?
Not an OS, but AFS has a wider set of permissions (RLIDWKA - which, if I
remember correctly, ar
Ed Leafe wrote:
> Should we have defensive code for every possible broken installation? We use
> a lot of the Python standard library modules, many dbapi-compliant modules,
> and, of course, wxPython. If someone mis-installs one of the pre-requisites,
> do you expect Dabo to catch that and pres
