You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Miguel Figueiredo <mf...@maisis.pt> on 2005/03/11 12:30:54 UTC
slide DB schema
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: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
RE: slide DB schema
Posted by Miguel Figueiredo <mf...@maisis.pt>.
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: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: slide DB schema
Posted by Carlos Villegas <ca...@uniscope.jp>.
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: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org