The new release of UniVerse – 11.1 – now has the EDA capabilities that have been in Unidata for some time. But, is this a common method of storing non-1NF data in a 1NF database? This article about friendfeed also uses the same techniques!
The article – http://bret.appspot.com/entry/how-friendfeed-uses-mysql (archive.org)- uses the same technique within MySQL to store JSON objects or as Bret writes “…schema-less bags of properties…”. Any fields/attributes of interest are stored in another table and indexed.
Within U2 EDA – External Data Access – methods, the UniVerse/Unidata records are stored within a BLOB/CLOB field and again, fields of interest can be separated out and indexed. The schema mapping tools supplied within the EDA suite provide a comprehensive method for the mapping process.
The drivers currently supplied are for Oracle, MS-SQL, and IBM DB2. There is no MySQL driver, but there is a EDA API documented, if one was keen enough to write one.
The really interesting notion here is that if a driver was made available for MS-ACCESS, it would be possible to use the new calculating fields within MS-Access 2010 (http://mvdbs.com/2010/10/31/ms-access-2010-and-calculated-fields/ dead link as of Aug. 2020) to dynamically extract/translate the BLOB data into the appropriate attributes and values – which is what is really going on within the dictionary definitions within a PICK/U2 environment anyway.
There you go – half-way to PICK on MS-ACCESS. A backwards or forwards step I wonder…