Re: [HACKERS] is GiST still alive?
От | Kurt at DBC |
---|---|
Тема | Re: [HACKERS] is GiST still alive? |
Дата | |
Msg-id | 3F974CF4.90509@dbc.co.nz обсуждение исходный текст |
Список | pgsql-chat |
Christopher Browne wrote: > No, "tables" wouldn't be the right way to do it. > > But it's going to be troubled, in any case, because of the > every-popular mixtures of: > a) Often weird declarations of what character sets are in use; > b) Pointers to other parts of a document; > c) What's a "database" going to consist of? One XML document? Or > many? And if many, then then how do you have a centralized > reference point to navigate from to find the document that you > want? > And "navigate" was a carefully chosen word; what you then have is > essentially a network database system, and have to then start making > up ways of describing queries. XQuery may be better than CODASYL of > yesteryear, but you're still left writing a lot of recursive code. > (Thus making those that understand the Lambda Nature more powerful...) > > At the end, do you have a "database?" Or just a set of documents? > It's hard to tell, a priori. > [Trimmed comments on utility of such features] transferred from pgsql-hackers to pgsql-chat. Coincidentally, just recently looked at Fongs "The design and implementation of the POSTGRES query optimizer2" (referenced in the Developers Guide) which implies that one of the initial goals of postquel and postgres was to handle similar structures : "The basic problem here is that the relational model is not well-suited for representing hierarchical relationships. As a solution, Stonebraker has proposed embedding queries within data fields and using these queries to express the hierarchical relationship between the corresponding tuple and information elsewhere in the database [STON84]. Using this idea, which POSTGRES supports, our complex object example is now represented as shown in figure 2.5. To retrieve information executed by the queries embedded within this data field, the user would issue the following query: execute (COBJECT.components) where COBJECT.coid = 1. Thus, n join queries reduce to a single execute query. In addition, users can selectively retrieve information linked through these hierarchies by nesting attributes" Go's around, comes around. Cheers, Kurt.
В списке pgsql-chat по дате отправления: