Miguel, For those of us who don't know: what is a "star configuration"?
Thanks, Warwick > -----Original Message----- > Hello Carlos, > > After a little time working the insides of the standard > rdbms adaptor, I've found out that, like you're stating, that > those two tables are not redundant, but required. That > troubles me immensely since an operation in a directory might > influence its children. The Slide implementation, since it > doesn't know if it will influence children or no, it does > some database query/updates just-in-case. That produces a > very high number of queries to the database, higher means a > directory with higher number of children. Also, we have > noticed that if the implementation must update a node, he > does not update it (doesn't care of the state of the node > either), it just replaces it. That also might imply updates > in other nodes that refer to first one, so we end up in a > roundabout play that will consume time in the delivery of the > initial request. > > I remember that a while back, someone submitted some patches > to improve database performance (around last October I > believe). Does someone know the state of that affair? > > I'm starting to think that, although the present db schema > is consistent, we should allow it some redundant information, > so we wouldn't need to perform so many queries for every > object. What about a star configuration, used in dataware housing? > > BTW, I got puzzled by that link table and when I started to > search the slide mailing list, I've found an email by a > fellow (can't recall the name) referencing the rfc 2518, > section 4.6 - Media Independent Links, witch seems to match > this link table. Seems that a link is a kind of an hyperlink > in a html page... > > Many thanks, > Miguel Figueiredo > > _____ > > As I understand, binding and parent_binding are used to implement the > resource hierarchy (parent/child relationships) and both are always > required. They have nothing to do with the binding concept in > the WebDAV > spec. The table LINKS is what implements the binding functionality in > the spec. If binding is not enabled in the Slide > configuration the LINKS > table is not used. > > Carlos > > > > Miguel Figueiredo wrote: > > Hello folks, > > > > We are in the process of creating an optimized postgres adapter. > > While analyzing the slide's DB schema we found out that > there are two > > tables > that > > seem to be redundant: > > > > * the binding table: > > CREATE TABLE BINDING ( > > URI_ID integer NOT NULL REFERENCES > > URI(URI_ID), > > NAME text NOT NULL, > > CHILD_UURI_ID integer NOT NULL REFERENCES > > URI(URI_ID), > > PRIMARY KEY (URI_ID, NAME, CHILD_UURI_ID) > > ); > > > > * the parent_binding table: > > > > CREATE TABLE PARENT_BINDING ( > > URI_ID integer NOT NULL REFERENCES URI > > (URI_ID), > > NAME text NOT NULL, > > PARENT_UURI_ID integer NOT NULL REFERENCES URI > > (URI_ID), > > PRIMARY KEY (URI_ID, NAME, PARENT_UURI_ID) > > ); > > > > The name binding suggests that it may represent the several binds > > (shortcuts) that a resource may be linked to. But it can > also mean the > > resource's children in case of a collection. If the second is true, > > the table parent_binding suggests being the reference to the > > resource's parent collection. > > > > Also, the table links: > > > > CREATE TABLE LINKS ( > > URI_ID integer NOT NULL REFERENCES URI > > (URI_ID), > > LINK_TO_ID integer NOT NULL REFERENCES URI > > (URI_ID), > > UNIQUE (URI_ID, LINK_TO_ID) > > ); > > > > Seems to give a hint that this may be the table where bindings > (shortcuts) > > of a resource are stored. When I exam it, the table is > empty, no data > > stored, witch may be expected since the postgres adapter is not > > prepared > to > > support the dav binding spec. > > > > Can anyone give me some insight? > > > > Many thanks, > > Miguel Figueiredo > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
