I have been programming with PICK for a few months now, and am still adjusting to thinking of programming solutions that solely use multi-value arrays. PICK doesn't natively offer any other data structures for either database or in-memory operations * (ignoring dimensioned arrays for the sake of argument since they are still a type of "array")
What are some creative ways of imitating other data structures? I can imagine ways of implementing a hash/dictionary, or a linked list, using arrays and routines to manipulate them. A concern here is that it gets complicated very quickly since the interface for the data structure can't be conceptually simplified as an object.
Are there any easy to implement algorithms that people have used to create unique data structures?
My System: I am writing routines in PICK for add-ons to Epicor's Eclipse, which sits atop UniVerse. I know there is a C# interface to UniVerse, but they are not usable to most of my work.
The Pick/MultiValue DBMS allows multiple values to be stored in a single field.
A common example would be to have a single attribute for a street address, with Street1, Street2, and perhaps Street3 as values. The structure would look like this: 01 Company Name 02 Street1]Street2]Street3 03 City 04 State...
Those are fields of the same type but they don't relate to anything else. Another similar structure would be to have multiple attributes where the values are correlated. There is typically one controlling attribute and any number of dependent attributes (atb 26 is used as a random example):
26 ShipDate]ShipDate]ShipDate
27 ShipQty]ShipQty]ShipQty
28 ShipVia]ShipVia]ShipVia
The application program manages the RI, not the database, though triggers can be used to allow the database to enforce the RI.
A RDBMS developer might prefer not to use that structure, so we can use traditional foreign keys for related data. In this case we might see a single attribute with keys to records in a Shipping file:
26 1234*01]1234*02]1234*03
So each of those values is a key to another file. The *00 value is an application-maintained sequential numeric ID for each delivery. They might be used here in case one of the deliveries is later marked as unconfirmed, so the value could be deleted, leaving this:
26 1234*02]1234*03
The common MVDBMS platforms allow one more level for SubValues. These are used with reservation but they can be quite valuable. Consider the above shipping data in a single attribute:
26 ShipDate\ShipQty\ShipVia ] ShipDate\ShipQty\ShipVia
The ShipVia from the second shipment would be referenced in code as Item<26,2,3>.
Some developers prefer to use non-system delimiters. Anything is valid as long as it won't be found in the data. You'll usually see asterisk, slash, pipe, comma, or some other alphanumeric:
26 ShipDate|ShipQty|ShipVia ] ShipDate|ShipQty|ShipVia
The code to get the second ShipVia might be:
Field( Item<26,2> , "|" , 3 )
That ShipVia field might itself be a foreign key to table file which just has the ID for the key and the ShipperName in atb1. So we're talking about the same data structure being used for two kinds of file: transactional data, and mostly static tables. It's no different than a relational database.
Yes, you can create linked lists, where for example a Company record has a single attribute for Departments. That translates to a Departments file where there's an attribute for Managers. That translates to an Employees file where an attribute is allocated for Team members. Each of those IDs would also translate to Employees, where some of those Employees might also be managers with their own teams. This structure is used for Bill Of Materials, for Multi-Level Marketing companies where individuals have a down-line, or for Insurance where risk is broken up to multiple companies who each then further break up the risk.
So there is a lot of versatility to the structures. Anything you can do with a RDBMS or a Key/Value structure can be done with MV.
How closely does that answer match your question? And what other kind of example would you like to see?
With regard to Objects, the QM MVDBMS does have OO BASIC, and the Caché DBMS includes an MVDBMS implementation where MV data can be exposed as objects. Also, with mv.NET and other tools, we can generate strongly typed classes from dictionary definitions (schema) which allows for the exact same kind of ORM as for any relational platform.