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]
