Hi for all,

Topic as curiosity for the community.

It was navigating at the Web and I found a database Multi Value
developed in Brazil. The company is in the state of Paraiba, poor
State of the country, in the area dries of the northeast of Brazil.

It is Multi Value but it is not Pick

http://www.lightinfocon.com.br/engl/

Cleber

Hello Cleber:
Is Lightbase multi-value compatible with the Pick data model or is is
multi-value in the sense of Cache' (Mumps) or uses multi-values in another
form?
Thanks

"Cleber Vieira Baptista" <cleber (AT) multi-sc (DOT) com.br> wrote

Bob Marik wrote:

Maybe I'm missing something, but I can't find anything on that website
that indicates Lightbase is a MultiValue database similar to Pick.

The home page mentions "tridimensional database system", but there is
no technical overview that I can find.

--
Kevin Powick

Kevin Powick wrote:
multi-dimensional?


rog

Excuse don't speak very English.

It is Multi Value;
It is not compatible with PickBasic as the Cache (for the time being);
He has a graphic tool of development;
Access to the data with Provider for. net and technology COM.

Cleber Vieira Baptista
www.multi-sc.com.br

Cleber Vieira Baptista wrote:
The term MultiValue is one that Gus Giobbi worked to have as a
designation for the rull range of PICK and PICK-A-LIKES. See
http://www.intl-spectrum.com/aboutmv.html So, I'm not sure it is legit
to use that term with non-pick products.

There are a lot of databases that claim to be multidimensional,
particularly those that work with OLAP cubes. There are a lot of
others that permit non-1NF structures (by historical defs of 1NF)
including object-oriented, XML, and key-value databases. With the XML
data model gaining steam and di-graphs (such as the world wide web) and
trees being used for documents (and projects such as Tim Berners-Lee
with the Semantic Web), many in the inner circle of relational theory
have changed the definition of 1NF so that they now permit
"relation-valued attributes". SQL-99 and following also have language
standard changes to permit parent and child tables, such as those
supported by postgresql.

Pretty much all data modeling in the 60's & 70's was done with non-1NF
models. Most in the 80's was as well. I predict that over the next
ten years there will be a definite return to non-1NF, by whatever name.
However, the term written as "MultiValue" is still somewhat synonymous
with PICK[TM] and I don't think it is accurate to apply it in that
format to other products. It is not and will not be strange to see a
lot of non-pick players permitting list values. The industry with a
not-exactly-relational data model really needs a name other than
"non-relational" since most such products insist on being called
"Relational" as that is still the king of the hill in data models (but
stay tuned!)

smiles. --dawn