On May 17 2013 12:05 PM, Michael Haberler wrote: > 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
OK. Maybe we can then agree that the model of the system as implemented is broken. I understand not knowing about OODB and being comfortable with RDB. Can we look into inviting/leveraging DB experts to help defining what different models can offer, and start sketching out requirements, needs, wants, and fantasies? EBo -- ------------------------------------------------------------------------------ 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
