Re: Thoughts/experiences with JSON/XML on DB2

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

Hi Justin

Just to clarify - is this a PF (physical file) or an LF (logical file)?

When you say multiple format, some might be assuming an LF - but it's 
probably a flat file with different formats.

OK, so each record will have 1 or more record identifying codes - this 
is used in the RPG I-specs to tell you which one you are using. The 
F-specs can tell you where and how long the key is - then you'd need to 
find out from the I-specs which fields are in the key.

You mentioned there are 25 formats in this file - that seems way too 
many - typically these are header/detail/extended-detail kinds of things.

Look at the record-identification entries in your I-specs - those tell 
you how many you have - in fact, your F-specs should tell you how many.

You COULD do SQL by using this identifier in a WHERE clause - then 
having substrings of the entire record based on the format for each 
identifier - YUK!!

You call it "non-structured data" - I must disagree, and I think that 
took you down a curious yellow brick road - it is a flat file with 
several (25?) unique structures, 1 per record.

So your columns come from the I-specs, the index comes from a 
combination of information in and F-spec and the related I-specs - 
ba-da-bing! EZ-PZ! Right?

HTH
Vern

On 4/1/2016 9:18 AM, Justin Taylor wrote:
> Booth Martin:
> --This is live data with new records being added daily.
> --Extracting the non-structured data into a traditional RDBMS was my first thought.  Then I thought that a NoSQL type approach might be better, since NoSQL was originally intended for use with non-structured data (although the authors probably never considered S/36 files).
> --I'm not sure either type of extraction would be significantly more difficult than the other.
>
> Rob Berendt:
> --"Multiformat join logical file", those emulate the multiple record formats seen in S/36 files, correct?  Does SQL support those?