Surely the real strength of Pick, Unidata et al. is not so much the mv fields (which can be relatively easily emulated using array types) but the data dictionaries and the way the same field can be defined in multiple ways (data formats) with different names, or that you can create pseudo fields that are actually functions or correlatives? However, these again are things that can be achieved in PostgreSQL, just not in the same way.
Of course, PostgreSQL's array types are multidimensional whereas iirc you are limited to values & subvalues in most Pick-like DBs and even then support for subvalues in 4GLs such as SB+ is limited.
Regards, Dave.
Dear Team,
I have been monitoring this list for quite some time now and have been studying PostGreSQL for a while. I also did some internet research on the subject of "multi valued" database theory. I know that this is the basis for the "Pick" database system, FileMaker Pro, "D3", and a few other database systems. After carefully reviewing the theoretical arguments in favor of this type of database, I am thoroughly convinced that there are certain advantages to it that will never be matched by a traditional "relational database".
I won't waste your time in reviewing the technical advantages here, because you can do your own research. However, I will say that it is obvious to me that an mV database will be an integral part of any truly practical AI robotics system. It will probably be necessary to "marry" the technologies of both relational databases and mV databases in such a system.
IMHO, this is something that you, as the leaders in the most advanced database system ever developed, should carefully consider. The Linux community needs to be aware of the special advantages that an mV database offers, the way to interface an mV system with a traditional RDBMS, and the potential application theory as it relates to AI systems.
We, as a community of leaders in GPL'd software need to make sure that this technology is part of the "knowledge base" of our community. Thanks for listening.
Arthur
