I'm sorry Warwick,
A star configuration means that our db schema is based in a set of
relational tables, that when drawn together seem like a star. For example,
imagine the xyz coordinates along the time dimension. We could draw
something like this for a datawarehouse:
Table X Table Y
Id: serial Id: serial
Value: int Value: int
\ /
\ /
\ Table PointHistory /
X_Id: serial
Y_ID: serial
Z_ID: serial
Value: DateTime
|
|
|
|
Table Z:
Id: serial
Value: int
The tables on the outside are called dimension tables and the inner table
is called the facts table. Datawarehousing rules state that redundance is
ok, and that SELECT operations with big JOINs must be avoided.
Best regards,
Miguel Figueiredo
________________
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
