Re: [HACKERS] mV database tools
mlw wrote: > > > "[EMAIL PROTECTED]" wrote: > > > > 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. > > The idea of a multi-view database is interesting and all, but hardly a next > leap in database theory. It is nothing more than using an addressable array > within PostgreSQL, and PostgreSQL has contributed functions for just these > sorts of operations. > > The syntax may be different than you would wish, but with the same result. It > seems that mu Doh!! pressed send!! It seems that a multivalue database can be implemented on top of PostgreSQL, where as a full relational database can not be implemented on top of an MVDB. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] mV database tools
> "[EMAIL PROTECTED]" wrote: > > 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. The idea of a multi-view database is interesting and all, but hardly a next leap in database theory. It is nothing more than using an addressable array within PostgreSQL, and PostgreSQL has contributed functions for just these sorts of operations. The syntax may be different than you would wish, but with the same result. It seems that mu > > 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] mV database tools
Title: Message 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. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 01 May 2002 19:37To: PostGreSQL HackersSubject: mV database tools 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
[HACKERS] mV database tools
Dear Team, I'm wide open to other ideas for the support of robotic vision through tools already built into PostGreSQL. But you've already admitted to certain speed limitations...and robotic vision is going to require much more intense processing power. An MVD might allow the data stream to be quickly "re-arranged" during the recognition processing and then converted to RDBMS form later...after object recognition is "stabilized"... I really would love to see little "Short Circuits" running around teaching themselves...ok? Just a dream of mine...
[HACKERS] mV database tools
Dear Team, I've read your comments. No, I don't think that MVD's are the best thing since sliced breadbut they do have a certain "simplicity" that seems to hold the key to high speed analysis of large volumes of streaming data from the "eyes" of a robot. This stream of data must be quickly analyzed and subdivided into recognizable objects...I realize this area is wide open to debate...howeveran MVD might at least offer a "useful" theoretical "angle" in a "pre-PostGreSQL" stage of processing...just a thought...
Re: [HACKERS] mV database tools
> I suppose arrays are PostgreSQL's equivalent of multi-valued data (is it > possible to have arrays of arrays?) So it could be argued that > PostgreSQL already provides part of what Arthur wants. It seems to me that there would be a whopping lot of value to the exercise of figuring out some way of "layering" MVD on top of a relational database, even if only to provide something sufficiently analytical to cope with the perpetual claims of: "MultiValued Databases are Vastly, Spectacularly, the Bestest Kind of Database ever imagined in the universe! No, really they are!" It might not be necessary to go all the way to fully layering such a thing atop PostgreSQL, although it would be a nice riposte to be able to respond with: "Been there, done that. Of _COURSE_ PostgreSQL supports MultiValue." -- (reverse (concatenate 'string "gro.gultn@" "enworbbc")) http://www.cbbrowne.com/info/lisp.html Including a destination in the CC list that will cause the recipients' mailer to blow out is a good way to stifle dissent. -- from the Symbolics Guidelines for Sending Mail -- (reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa")) http://www.cbbrowne.com/info/spreadsheets.html "Starting a project in C/C++ is a premature optimization." -- Peter Jensen msg16544/pgp0.pgp Description: PGP signature
Re: [HACKERS] mV database tools
On Wed, 2002-05-01 at 19:37, [EMAIL PROTECTED] wrote: > 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 For those who aren't familiar with PICK, it is an untyped database (apart from weak types provided by a separate dictionary - advisory but not enforced). All records must have a single key, by which the record is retrieved. Database records are divided into "attributes" by CHAR(254), fields are subdivided into "values" by CHAR(253) and values can be further sub-divided into "subvalues" by CHAR(252). When records are listed, second and subsequent values are presented on separate lines within their columns. In a PICK application, it would be common to have a set up such as: CUSTOMERS file: key=id record=name|address1^address2^...|...|ordernumber1^ordernumber2^... (using | for CHAR(254) and ^ for CHAR(253)) where the whole address is in one field, with each address line in a separate value, and there is another field listing the order numbers (record keys in CUST_ORDERS) of all outstanding orders, again as separate values. Then you could use the following commands (this is not SQL, of course): SELECT CUSTOMERS WITH ID = "C23" SAVING ORDNOS SORT CUST_ORDERS to list all the outstanding orders for custoemr C23. The advantages of Pick are that it is very easy to program; the corresponding disadvantage is that it is a very undisciplined environment. It is necessary for the programmer to remember to update that list of order keys whenever an order is created or deleted. (Some recent implementations now support triggers, I think.) I suppose arrays are PostgreSQL's equivalent of multi-valued data (is it possible to have arrays of arrays?) So it could be argued that PostgreSQL already provides part of what Arthur wants. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "For if ye forgive men their trespasses, your heavenly Father will also forgive you; But if ye forgive not men their trespasses, neither will your Father forgive your trespasses." Matthew 6:14,15 signature.asc Description: This is a digitally signed message part
[HACKERS] mV database tools
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
