On Thu, Jul 10, 2014 at 4:49 PM, Peter Teeson <peter.tee...@icloud.com> wrote:
> > On 2014-07-10, at 5:22 PM, Blake McBride <blake1...@gmail.com> wrote: > > What I've been trying to convey (and clearly have failed on every attempt >> so far) is that an APL component file system must be file-centric. Every >> APL component file system that I've worked with or have read about has >> created a file to contain its APL data components. >> > > Conceptually, yes. Actually, what goes on under the hood is > implementation specific. In our present case, each component file would > equate to an SQL table - not an SQL database. This is very important. So, > if your applications uses 15 component files, that would be represented as > 15 SQL tables in one SQL database. > >> In my experience with the IPSA/STSC file system a component file could > store different data types in each component. > In my experience with various SQLs an SQL table only stores records whose > fields are consistent for each record. > Therefore I do not agree that component file maps to an SQL table. > > Peter > The way I implemented the keyed file system, which supports arbitrary nested arrays of varying size and types in each record, is as follows: Each table is defined to have two columns (for data - not including the key). One is a varchar, the other is a text. I use GNU APL's 14 ⎕CR and ¯14 ⎕CR to convert between arbitrary nested APL arrays and string vectors. If the string vector is short I use the varchar field. If it is long, I use the text field. So, SQL only sees varying length strings. APL sees arbitrary APL nested (or not nested) arrays. --blake
