[Info-vax] The real problem that needs solving to grow VMS

[Dave Froble]

On 11/23/2022 9:24 AM, Arne Vajhøj wrote:
> On 11/23/2022 9:00 AM, Dave Froble wrote:
>> On 11/23/2022 8:11 AM, Simon Clubley wrote:
>>> On 2022-11-22, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>>> On 11/22/2022 10:46 AM, IanD wrote:
>>>>> I've been trying to use it to model software testing components for a
>>>>> large software conversion project, as a learning exercise, I can see
>>>>> the potential but I lack the knowledge of Neo4j to quickly knock out
>>>>> solutions, so it's a hard grind of learning in my own time :-(
>>>>
>>>> They have some market share.
>>>>
>>>> It is my impression that they are mostly used for analytical work
>>>> and not so much for for transactional/CRUD work. Not to just save
>>>> and retrieve data but for trying to get some insight out of the data.
>>>>
>>>> How that fits with Dave's usage I have no idea.
>>>
>>> It doesn't. David's problem is a normal transaction based problem with
>>> issuing and managing items, but with the added complexity that the part
>>> number can change on a regular basis. Supersessions and supersession loops
>>> are part of normal parts management and the surprise is not the problem,
>>> but the fact the vendors his customers are talking to can't handle them.
>>
>> Some of the younger people in IT seem to lack understanding of some fundamentals.
>
> In general terms you are using:
>
> application----embedded NoSQL key value store database (VMS index-sequential files)
>
> or depending on view:
>
> application----embedded custom database (hierachical? network?
> other?)----embedded NoSQL key value store database (VMS index-sequential files)
>
> Ian noted that *if* you wanted to change that then instead
> of the obvious:
>
> application----relational database
>
> there are also the possibility of:
>
> application----NoSQL graph database
>
> Anything can probably be made to work with enough effort - the question
> is what is the best solution.
>
> My point was that I only think that the NoSQL graph database
> is a good solution if the core problem is analytical not
> transactional in nature.
>
> Simon stated that it is transactional.
>
> (and continue to express his surprise that more standard
> item management systems can't handle it - which is not
> really relevant for the choice of database paradigm)

Correct.

There is usually more than one solution to most problems.  And a RDBMS has many 
advantages.  If I was starting over today, I'd most likely attempt to use a RDBMS.

As for the "standard" of "one size fits all", that too often is a very poor 
solution.  Creating pretzels rarely fits a solution that needs a straight line.


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486