Am 17.05.2013 um 18:47 schrieb andy pugh <bodge...@gmail.com>: > On 17 May 2013 17:27, Kent A. Reed <kentallanr...@gmail.com> wrote: > >> If a relational database approach isn't acceptable, how about an >> object-oriented database approach instead? > > Why wouldn't it be? > > Snooping around the source tree last night I found: > http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/toolstore/sql/schema-simple.sql;h=21c04238eb6e7ae917a8049cc3555337fb0aeb1b;hb=HEAD
that is an accidential leftover of work which contained much more than this, and which I retracted after the "oh my god, a database! we need to retain our .tbl file at all cost!" pushback on the list back then; looking back I think this was a mistake because the dead end which is obvious now was obvious at least to me back then already -- that said, what I am convinced is needed is proper design work on a relational _model_ for the tool miniworld (tools, offsets, spindles, magazines, wear, holders and whatever came up over the years) if anything is clear is: the "user-friendly single-table format" we have now violates every rule in the book of database decomposition - fully denormalized, lots of different objects lumped together in a 'line', and as a consequence every wart described since Codd & Date: delete anomalies, insert anomalies, cant do that because no way to represent the concept, repurposing of keys, data dependencies on key contents, the works. I am positive anybody hoping to continue on the past design is bound to fail, except in adding a layer of incomprehensible patches. That just isnt going anywhere. As for an OODB approach - I never understood what that is so I cant comment, but it surely doesnt get us around the legwork designing a bulletproof data model, as well as an API for the interpreter and other using components to avoid a re-run of past discussions: discussions on storage mechanism are moot at this point because we're talking modeling (that is an abstract description, not files or databases or redis or Oracle or what have you) and whatever the storage mechanism chosen (possibly by an integrator) would be, it ought to be be hidden behind a interpreter/toolstore external API to start with - Michael > > -- > atp > If you can't fix it, you don't own it. > http://www.ifixit.com/Manifesto > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
